Connecting Lync 2013 and Cisco Jabber

UPDATE:  I have published a new article on connecting SfB and Jabber using XMPP and Cisco Express.  See that new article here:  http://tsoorad.blogspot.com/2016/10/sfb-jabber-via-xmpp-cisco-express.html


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 Setup

As 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.

If you have Lync servers deployed and the XMPP is going to be added in, the Lync 2013 documentation has some excellent guidance that I will not attempt to re-write.  You can read that guidance here. Be sure to follow all the links provided in the table as they lay out the requirements for enabling XMPP.

Certificate requirements on your Lync 2013 Edge pool will be simplified if you do all of this before you deploy.  This is because the certificate wizard will see that XMPP is desired, and will populate the certificate request with your domain name. If you have multiple SIP domains, make sure that all of them that need XMPP federation are listed on the certificate request.  For the curious, all that is needed for the XMPP piece of the certificate is the domain name:  tsoorad.net, domain.com, etc.
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).

In the Lync 2013 Topology Builder, open the properties of the your site, and then select  the check box “Enable XMPP Federation.”

From there, go to your Lync 2013 Edge Pool and edit the properties. What you want is the “Enable XMPP Federation for this Edge pool (port 5269) to be checked.

 

Next, publish the topology and either deploy the servers or update the servers. The official documentation referenced above has explicit guidance for doing either action.  You did read all that, yes?

DNS Internal

For XMPP support, the internal DNS is unchanged.  Your clients will communicate with the FE servers as normal.

DNS External

Whatever 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:

Name	TTL	Weight	Priority	Port	Target
_xmpp-server._tcp.domain.com	3600	0	0	5269	sip.domain.com

In my case:  _xmpp-server._tcp.tsoorad.net which points at sip.tsoorad.net.  Port requirement is 5269.

Firewall Requirements

5269 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 Panel

Once 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.

First, make sure that the external access policy that applies to your users at whatever level have the “Federated User Access” selected, and that the Access Edge Configuration allows “Federated user access.”

 

Now, lets add our partner’s SIP domain in so that the Lync Edge thinks it is OK to at least attempt to communicate with the other domain.

Select the “XMPP Federated Partners” tab and click on “New.”

Fill in the blanks (literally) with the information required.  What is shown here is what I know works.

Note that the “Partner Type” here reflects the following:

• 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:
  1. Add Lync contacts and view their presence without express authorization from the Lync user.
  2. Send instant messages to Lync contacts whether or not the Lync user has added them into their contact list.
  3. 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.

You will want to set this to what your organization requires.  This setting is “tiered” in the setting is most open at the “Federated” level, and most restrictive at the “Public unverified” setting.  For the unverified, your users will need to add the federated contact into their Lync contact list before expecting to be able to IM with the remote Jabber user.  This is roughly equivalent to the settings for a PIC provider verification level.

PowerShell

One of the things you are most likely to want to set, especially if you have more than one Edge server in either DNSLB or HLB, is the “DialBackPassphrase.”  This is done with the Set-CsXmppGatewayConfiguration cmdlet.  One setting fits all.  There is a default setting, but I like to set it manually to make sure it is set.  The command looks like this:

Set-CsXmppGatewayConfiguration -DialbackPassphrase Tsooraddialback

With the results looking like this:

Here is the list of XMPP related cmdlets. 

Get-CsXmppAllowedPartner
Get-CsXmppGatewayConfiguration
New-CsXmppAllowedPartner
Remove-CsXmppAllowedPartner
Set-CsXmppAllowedPartner
Set-CsXmppGatewayConfiguration
Test-CsXmppIM

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.

Setup XMPP Federated Partner

Now 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:

Go to the CUP Server and under Presence, Settings, check these boxes, especially the email one.

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 Bottom

We 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.
YMMV