Federated User – Presence Unknown

Here at Kloud we have just been busy updating our Skype for Business Public Certificate before it expired. Our SAN certificate provided by GoDaddy is used on our Edge Server and Reverse Proxy for all external communication to be encrypted with TLS or HTTPS.

After updating our certificate and restarting services to make the certificate take effect, we started to get some feedback from Kloudies (Kloud Employees) of federated contacts showing up with ‘Presence Unknown’ in their contacts list. These were contacts which they had previously been communicating with prior to the certificate change. The head scratcher was that it wasn’t all federated partner domains.

Here is some of the findings and troubleshooting we performed to get to the resolution of the issue.

First thing to always test is the inbuilt PowerShell cmdlets on your server itself.

Test-CsFederatedPartner -Domain contoso.com -TargetFqdn kloudedge.kloud.local

Successful domains appear with the following lines:
Target Fqdn   : kloudedge.kloud.local
Result        : Success
Latency       : 00:00:00
Error Message :
Diagnosis     :

While domains that had the issue would have the following output:
Diagnosis:
ErrorCode=1047,Source=sip.kloud.com.au,Reason=Failed to complete TLS negotiation with a federated peer server,fqdn=SIP.Contoso.COM:5061,peer-type=FederatedPartner,winsock-code=10054,ip-address=xx.xx.xx.xx,winsock-info=The peer forced closure of the connection


From the above message we could see that the peer’s (being the federated partner) Access Edge server was actively closing the connection from our server.

But why?? We haven’t done anything wrong….

This can become a hard thing to troubleshoot if you don’t have access or know the SFB administrator at the partner organisation. Lucky for us this isn’t the case for at least one of our troubled SIP domains.

Investigating the Partner Edge Server we did the following:

1. Start > Run mmc.
2. File > Add/Remove Snap-in… > Add… > Certificates (Add) > Service Account  > Skype for Business Server Access Edge (Finish) > Close > OK.
3. In the mmc, navigate to RtcSrv\Accepted Certificates > Certificates.
4. Look for the certificate named “sip.kloud.com.au”

What we found was still a copy of the certificate that had just been expired, but no new certificate with the up to date expiration. We wanted to give this Edge Server a little helping hand and investigate why it would potentially not have added the new certificate into this store. Upon copying the new sip.kloud.com.au.cer file to a location on the server and opening the certificate for viewing, we assessed the path of certificate. Bingo! The certificate path was not validated.

The server was missing the GoDaddy Intermediates that are associated with our new certificate. Upon adding the new GoDaddy intermediate certificates to the intermediate store location and restarting the Acess Edge Service to make certificate settings take effect, instant success. The new sip.kloud.com.au certificate was downloaded from our Kloud Edge Server into the Accepted Certificates store of this Edge Server whom we were talking with and presence was restored both ways.

So now we have made the assumption of knowing all the federated partners we associate with that don’t patch their Edge Server with Windows Update. I hope I’m not talking about you.

Edge Servers can easily be the servers that you forget to put in a patching cycle due to being in a DMZ restrict zone, also they are workgroup machines so they won’t take the default group policy settings from WSUS. But here is a prime example of how it could have negative impact on your company if you don’t. So the only way to fix the issue is to spread the word. I don’t have access to everyone. Until they read this blog I can’t chat with them online. The moral of the story;

Patch your Edge Server so they can have up to date certificate information or get left behind while the rest of the Skype for Business world keeps moving on