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.
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.
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.
Next, 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.