About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2013/05/08

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).
image
In the Lync 2013 Topology Builder, open the properties of the your site, and then select  the check box “Enable XMPP Federation.”
image
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.
image 
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.
image
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.”
image  image
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.”
image
Fill in the blanks (literally) with the information required.  What is shown here is what I know works.
image
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:
image
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.
image
Likewise, your Jabber partner must be able to do the reverse.  Here is how my lab looks to the world:
image
Go to the CUP Server and under Presence, Settings, check these boxes, especially the email one.
image
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)
image
Then go to: Presence, Inter-domain Federation, XMPP, Policy and set as desired:
clip_image001
Then go to Messaging, Group Chat Server Alias Mapping and add all of the email domains your CUP server supports:
image
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

11 comments:

raj said...

This is very good article... for interdomain federation.i m sure this is the best reference.
have you worked on Intradomain federation where cup and lync is using the same sip domain and placed in the same network. If yes, I need your inputs.

raj said...

Thanks a lot for posting this article. For interdomain federation, this is the best article. any reference for intradomain where lync and cisco jabber uses the same sip domain and same network

tsoorad said...

up in the front of the article I link to this url: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/integration_notes/Federation/Intradomain_Federation/Overview_chapter.html
which is the cisco domain sharing setup.

Ká ** said...

Many thanks for this post. This is, without any doubts, the best article for federation.
You helped me A LOT!

Unknown said...

Thanks for providing this excellent article. I had previously thought that Cisco Jabber (XMPP) was incompatible with Lync 2013 (SIP/SIMPLE) from a presence and chat perspective. However, your article has changed my thinking (i.e. use XMPP into Lync). Can you confirm that your approach will work for presence & chat federation between a Cisco Jabber 9.x or 10.x and Lync 2013 environment?

A tangential question is is the intra-domain stuff. Most customers that want this seem to have something like this:

jim.jabber@foo.com <-> larry.lync@foo.com

Since Jim and Larry are part of the same company, they don't want to use different domains (i.e. jim.jabber@jabber.foo.com and larry.lync@lync.foo.com). Do you have any ideas on how to solve that problem?

Thanks again!

tsoorad said...

@Jim - http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cups/8_6/english/integration_notes/Federation/Intradomain_Federation/Partitioned_Intradomain_Federation/Overview_chapter.html is the official cisco documentation for intra-domain.
Inter-domain is here: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cups/8_6/english/integration_notes/Federation/CUP_8-6_Interdomain_Federation/Planning_chapter.html

Whether or not either of those apply to more recent versions of CUCM/CUPS/Jabber is not in my personal KB.
-John

PCpolo said...

I'm curious, we currently have an external SRV DNS record setup so we can federated with others via Jabber.
Can I add a second _xmpp-server._tcp.ourdomain.com pointing to our Skype(Lync) setup and not have it affect either environment's communications?

tsoorad said...

@PCPolo, no, if you do that, your connections will become randomized. I think to get what you want you will have to setup intra-domain federation between your Jabber and Lync on the inside and let ONE of them be the connection point and refer traffic to the other system as needed.

PCpolo said...

tsoorad, thanks for the reply. I'm not sure exactly what you mean when you say, "let ONE of them be the connection point and refer traffic to the other system as needed".

Basically we're using Jabber now and I'm slowly getting people to start using Skype (Lync) instead.
Some users use Jabber to communicate with other Jabber users that are not on our Jabber system.
I would like our Skype system to be able to connect to these other Jabber users without breaking the existing Jabber federation.

Does that make sense?

tsoorad said...

@pcpolo: You cannot have the same SIP domain for both systems. One of them has to be in control of the SIP traffic. If you need them to be the same SIP domain, then bring the traffic to one or the other, then have that system pass the unknown user to the other system for resolution. Sounds like in your situation, you need to bring all SIP traffic into Jabber first, then setup intra-domain federation Jabber > Lync/SfB.

PCpolo said...

Ok thanks tsoorad

test 02 Feb

this is a test it’s only a test this should be a picture