Many thanks to John Gizel.
Lync 2013 now has a built-in XMPP gateway. If you look closely, there is an XMPP component running on both the Lync FE and the Lync Edge. Very easy to setup. Simply hit the box for XMPP Gateway in Topology Builder, and when you deploy the server roles, the XMPP will be installed along with everything else. Sweet!
But, how do we configure this thing? There are a variety of guides on setting up for GMail.com – Google Chat. But what if you need to federate with another entity that is running – literally – Cisco Jabber (you know that CUPC thing). There are two methods, one for doing the internal-share-the-namespace thing on 5061, and another for using XMPP across port 5269. The second method is for our scenario: the other entity is completely outside of your control.
To configure Lync 2013 to share a SIP namespace with Cisco Jabber – see this document. To be totally fair, Cisco would have you follow this document when transitioning Lync users to Jabber – but I have never seen that sacred event occur. I am sure it does, and will in the future, but the usage I have seen from this document is to get intradomain SIP namespace sharing instantiated. Microsoft has excellent documentation for getting the XMPP setup for general purposes, and prescriptive guidance for federating with Gmail.com. For this article, I am going to gloss over some of the aspects of that guidance; no need for me to re-invent (re-write?) the wheel. What I will show is how to configure the basics, and then we will take a look at how to help your business partner configure their Jabber setup.
Let’s take a look at what is involved with getting Lync 2013 XMPP configured to federate with an external SIP namespace hosted by another organization and is using Cisco Jabber. We will need Topology Builder, Lync Control Panel, maybe some PowerShell (depends on your whim), some external DNS work for your namespace, some external DNS work on your federated partner’s namespace, a little firewall configuration (on both namespaces). If this was Christmas time, we’d also want to work with the partridge in the proverbial pear tree.
Lync SetupAs hinted at above, if you do this before you deploy any servers, at this point all you need to do is complete your topology, and when you publish and deploy Lync 2013 Servers, the bootstrapper will setup the XMPP functionality. If you have a topology already deployed, and are enabling XMPP after the fact then you will need to do a bit more work. Perhaps now would be a good time to review your certificate requirements. Hopefully you planned in advance and are doing this before you deploy. This is one of the reasons I wrote the following: http://blogs.technet.com/b/nexthop/archive/2012/12/11/ten-tips-plus-one-for-implementing-lync-server.aspx. Take a look at items 1, 2, 3, and 6.
Here is my Lync 2013 Edge certificate – you can see where the SAN has an entry for just the domain name. And yes, I included AV on my certificate even though that name is not needed. You can also see that I use this certificate for my Reverse Proxy (a TMG at this point in time).
DNS ExternalWhatever you do, don’t forget to create an _xmpp-server SRV record in your external DNS. The SRV definition is this:
_xmpp-server._tcp.domain.com with a target of your access edge A record.In DNS-speak, this is seen as:
In my case: _xmpp-server._tcp.tsoorad.net which points at sip.tsoorad.net. Port requirement is 5269.
Name TTL Weight Priority Port Target _xmpp-server._tcp.domain.com 3600 0 0 5269 sip.domain.com
Firewall Requirements5269 open in both directions. Simple and sweet. But! Be sure to configure the firewall to pass 5269 to and from all possible Lync 2013 Access Edge IP addresses. To whit, if you have a DNSLB Edge, then at a minimum you will have two IP addresses that will need to be bidirectional for port 5269. If you have an HLB Edge, then the number goes to three minimum. Failure to observe this requirement may result in random behavior.
Lync Control PanelOnce you have your server deployed, the edge server deployed, your firewall configured, and all the certificates are correct, open up your Lync Control Panel and go to the Federation and External Access tab so that we can create the settings for your Jabber federation.
- Federated A Federated partner type represents a high level of trust between the Lync Server deployment and the XMPP partner. This partner type is recommended for federating with XMPP servers within the same enterprise or where there is an established business relationship. XMPP contacts in Federated partners can:
- Add Lync contacts and view their presence without express authorization from the Lync user.
- Send instant messages to Lync contacts whether or not the Lync user has added them into their contact list.
- See a Lync user’s status notes.
- Public verified A Public verified partner is a public XMPP provider that is trusted to verify the identity of its users. XMPP contacts in Public Verified networks can add Lync contacts and view their presence and send instant messages to them without express authorization from the Lync users. XMPP contacts in public verified networks never see a Lync users’ status notes. This setting is not recommended.
- Public unverified A Public unverified partner is a public XMPP provider that is not trusted to verify the identity of its users. XMPP users on Public Unverified networks cannot communicate with Lync users unless the Lync user has expressly authorized them by adding them to the contact list. XMPP users on public unverified networks never see Lync users’ status notes. This setting is recommended for any federation with public XMPP providers such as Google Talk.
Set-CsXmppGatewayConfiguration -DialbackPassphrase Tsooraddialback
Note that there is a “test” cmdlet. I recommend that you try that out before you proceed much further. A complete description and usage for the Test-CsXmppIM cmdlet is here.Get-CsXmppAllowedPartner
Setup XMPP Federated PartnerNow that our Lync 2013 XMPP is configured and published with Topology Builder, you deployed the servers (or modified them), changed your external DNS, modified your firewall, and changed your cert, have established your Jabber federated domain, and tested your setup, we can look at helping your Jabber friend with their setup. The following is based on CUPC Server 8.6.1.
First, make sure that the partner has their external DNS SRV record correct. You may want to inquire about their firewall and port 5269 at the same time. Your bottom line is that until you can do the following from your Edge server, you have no hope of success.
Likewise, your Jabber partner must be able to do the reverse. Here is how my lab looks to the world:
Under Presence, Inter-domain Federation, XMPP Settings, set to this: (ignore CUPC 7.0 support) (note: I did not configure the secret-take the default)
Then go to: Presence, Inter-domain Federation, XMPP, Policy and set as desired:
Then go to Messaging, Group Chat Server Alias Mapping and add all of the email domains your CUP server supports:
Restart all of the XCP services (but better to reboot the server if possible)
Down Here at the BottomWe have looked at how to setup Lync 2013 XMPP Gateway and how to configure a Cisco CUPC 8.6.1 to Jabber to Lync across port 5269. A few key take-aways: DNS, certificates, firewalls, and prior planning.