As a consultant I do have the pleasure to be working with new customers on a regular basis. Recently I had the interesting request to make Lync 2013 talk to a Cisco Unified Presence 9.1 server. The goal for the customer was, to provide Lync users with the presence information available in the Cisco world.

Luckily the configuration was setup with multiple domains, Lync using the public (tomt.it) and Cisco Unified Presence using an internal only (tomt.local) domain.

What’s possible?

Before you get your hopes to high, here goes a quick list of what functionality will be available, once the federation is in place.

• Presence
• Contact List (users from both domains can add each other)
• IM (Peer to Peer only)

That’s it. Sure you can use Jabber to make your Cisco Desk Phone call a Lync endpoint, if you have a SIP trunk configured between the two systems, but that’s got nothing to do with the presence federation.

Basic Topology

The topology I was working with, consisted of a single Lync 2013 Standard Edition Front End Server with an associated Edge server. Lync was completely configured and operational, the SIP domain I’m going to use in this example is: @tomt.it

The Cisco Unified Presence Server was a standalone box, too. It was hooked up to a clustered CUCM installation, though that should not matter in this example. The SIP domain on the CUPS was @tomt.local

All of my test VMs are located in the 10.1.1.0/24 subnet.

CUPS configuration

There are a couple of requirements on the Cisco side of things. First let’s talk certificates.

The recommended configuration uses TLS as transport for the federation, not only is it more secure, it’s interesting enough that it’s easier to setup, too.

So we need a certificate on the Unified Presence server, to complete this step, log in to the “OS Administration” website of the CUP Server, to connect to the OS Administration website, use /cmplatform.

Once signed-in, go to Security, Certificate Management and:

1. Import the internal certification authority’s certificate to CUPS. Select the Type: “cup-trust”
2. Create a new certificate signing request (CSR). Select the Type: “cup”
3. Issue the certificate using a template that uses Server Authentication and Client Authentication as “Enhanced Key Usage”. Note: You’ll need a CA running on Windows Server Enterprise Edition for that, the default WebServer template does not include Client Authentication.
4. Import the issued certificate on the CUPS. Select the Type: “cup”

After that, my Certificate Management looked like this:

The next step is setting up the SIP Federation, this requires you to log-in to the “IM and Presence Administration” website, it can be found at /cupadmin.

Using Presence, Inter-Domain Federation, SIP Federation, Federated Domain we add the Lync Servers SIP Domain (tomt.it) as inter-domain federation:

Note: Some documentation state that you need to check the “Direct Federation” box, I found that it will work either way. If someone with CUP knowledge reads this, please do get in touch.

The next step is setting up a static route from the CUP Server to Lync. This is done using the Presence, Routing, Static Routes menu. We configure a destination pattern with an associated next hop and transport protocol, do note the notation used for the destination pattern!

Important: Select TLS as “Protocol Type” and User as the “Route Type”. 5061 is the default port on which a Lync Server will listen for TLS requests.

While we are in the “IM and Presence Administration” there are another couple of things to configure:

The Lync Servers FQDN (i.e the Common Name on the Lync Pools Certificate) must be added as TLS Peer Subject using System, Security, TLS Peer Subjects:

Then, using System, Security, Peer Auth Security Context add the newly created TLS Peer Subject:

Also make sure to check the “Disable Empty TLS Fragments” box and add the TLS_RSA_WITH_3DES_EDE_CBS_SHA cipher to selected ciphers.

Still in System, Security we need to configure ACLs. The ACLs are not traditional ACLs which allow or block IP:Port combinations, these are used to configure whether or not a communication partner has to be authenticated using MD5. Neither Lync Servers nor Lync Clients support SIP Digest authentication using MD5, so we need to make sure that they will not be prompted for authentication:

The following show my incoming and outgoing ACL entries:

The last configuration step on the CUP Server is to update the public FQDN using System, Service Parameters, Federation Routing Parameters:

Note: The documentation and help context for this parameter state that it should not be changed, although I found the Federation Routing FQDN will be used in the Record-Route Header (maddr field) and if Lync does not have a Trusted Application Pool for this FQDN, communication will fail.

Lastly we’ll have to restart some services on the CUP Server in order for the configuration changes to become active. To do this, we need to log-in to the “IM and Presence Serviceability” website, which can be found at /ccmservice.

Navigate to Tools, Control Center, Feature Services and restart SIP Proxy Service, then navigate to Tools, Control Center, Network Services and restart the XCP Router Service.

Ok, so that’s it on the Cisco side of things. Click here for the Lync Server Configuration.

Tom