Troubleshooting Lync Server 2013 Federation

The other day, I noticed that one of my contacts in Lync was showing Presence unknown. Fed1

Well, this does happen as people change jobs and go to different companies. I wondered about it, so I asked a common friend if he had heard anything. His response was that they were still there, and something must be wrong with my Federation configuration.

I was pretty sure that nothing was wrong with my Federation configuration since I could see others from other companies and was able to IM them and have conferences with them.

Basic Troubleshooting

I always start with the very basics. Has anything changed recently? What do the Event logs show?

What changed recently is that I migrated to a new Access Edge server. Initially, I discounted that as Federation was working for every other company,  so I didn’t think it was the server configuration.

Next, I opened Event Viewer and checked my Lync Server logs. I admit, I don’t always go to the Event logs early on in my troubleshooting. I have no valid reason, I just don’t do it. In this case, I did. I am also glad that I did, because this is what I found:

TLS outgoing connection failures

Over the past 12 minutes, Lync Server has experienced TLS outgoing connection failures 31 time(s). The error code of the last failure is 0x80090325(SEC_E_UNTRUSTED_ROOT) while trying to connect to the server “edge.CompanyName.com” at address [10.100.100.200:5061], and the display name in the peer certificate is “Unavailable”.

Cause: Most often a problem with the peer certificate or perhaps the host name (DNS) record used to reach the peer server. Target principal name is incorrect means that the peer certificate does not contain the name that the local server used to connect. Certificate root not trusted error means that the peer certificate was issued by a remote CA that is not trusted by the local machine.

Resolution:

Check that the address and port matches the FQDN used to connect, and that the peer certificate contains this FQDN somewhere in its subject or SAN fields. If the FQDN refers to a DNS load balanced pool then check that all addresses returned by DNS refer to a server in the same pool. For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the local machine.

When I deployed my new Access Edge server, I made sure that I added all of the major Certification Authorities to the Trusted Root Certification Authorities container. I realized that I must have missed at least one.

Digicert to the Rescue

I have always been a fan of Digicert, mostly because of how they support the MVP community, but also because they provide several great tools.

First, I opened a command prompt and ran nslookup.exe. From there, I set the type to SRV, and then put in _sipfederationtls._tcp.companyname.com, and it provided me the name of the Access Edge server on the other side, edge.companyname.com.

Fed3Next, I went to the Digicert site: https://www.digicert.com/help/ and put in the edge.companyname.com record into the tool. I scrolled down, and found the Certificate Authority that they were using for their certs on edge.companyname.com.

Yes, I did not have this particular Go Daddy Certificate Authority in my Trusted Root Certification Authorities list.

The last step was to go to https://certs.godaddy.com/repository and get the CA Cert.

Ta da! Problem fixed.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s