Excitement has grown around the Kloud office of late as each state waits with anticipation of a Surface Hub arriving to connect to our Skype for Business environment. The 84 inch Surface Hub destined for our Adelaide Boardroom which I nicknamed ‘Godzilla’ has had only one problem since installation, it fails to login to Skype for Business. Which makes this device go from a high end meeting room endpoint to a what I could only say is a giant tablet for games of tick tac toe, therefore this became my problem rather quickly. Everything seemed so pleasant following the initial steps from the out of box experience (OOBE). The Hub asked me questions, I responded politely with what I thought were all the right answers with a big smile on my face.
You could feel the electricity in the air.
This first date was going pretty smoothly I thought. Maybe the Hub caught wind of the nickname I was calling it around the water cooler in the office, because after our first date and the Hub launched into its standard meeting experience, an error was presented. Skype for Business would timeout and eventually say ‘login failure‘.
A quick look around the Hub’s administrative settings I could see that the account configured for mail was saying ‘synced‘ and I could verify this with a quick white board and ‘send to email‘, which arrived promptly to my inbox. Furthermore with my laptop in toe I could successfully login to a Skype for Business soft client with the Hub’s credentials. What is unique to the Hub client is that its does some extra validation on the account over other SFB clients that I’m familiar with. I’ll explain..
The device account I had for the Hub was in the ‘email@example.com‘ SIP domain, but the Active Directory (AD) FQDN of the connected servers was different. In Kloud’s circumstance I didn’t think much of this issue as our Hub was logging in over an internet connection through the Edge Server that has an access FQDN of sip.domain.com.au, which to me were the same domain. A quick login to the Edge Server logs didn’t present many results of an attempt of SIP from firstname.lastname@example.org. The Hub was using autodiscover to kick off the process of login to Lyncdiscover.domain.com.au I knew that much and must be failing. Using the Remote Connectivity Analyser (RCA) I could verify the login process for the account was successful and green ticks appeared against all lines. I thought to myself
What have I said to Godzilla to hurts its feeling so badly? That it deliberately wants to make my life hard
If you run a Skype for Business Autodiscover Web Service test on https://testconnectivity.microsoft.com the following process is attempted to the Autodiscover Web Service URL:
- Attempting to resolve the host name lyncdiscover.domain.com.au in DNS.
- Testing TCP port 443 on host lyncdiscover.domain.com.au to ensure it’s listening and open
- Testing the SSL certificate to make sure it’s valid
- Host name lyncdiscover.domain.com.au was found in the Certificate Subject Alternative Name entry
- Testing HTTPS authentication methods for URL https://lyncdiscover.domain.com.au/Autodiscover/AutodiscoverService.svc/root/user.
HTTP authentication methods successful.
- Testing HTTP content for URL https://email@example.com has token=”User”.
Found as expected token=”User” and confirmed anonymous access not allowed.
HTTP Response Headers:
Content-Type: application/vnd.microsoft.rtc.autodiscover+xml; v=1
Date: Sat, 25 Mar 2017 11:49:23 GMT
Expires: -1Elapsed Time: 127 ms.
In the above web request Lyncdiscover told the Hub that the registrar server its connecting to has a X-MS-Server-Fqdn with domain.local, which it did not automatically trust. Microsoft do state this in an article:
- Multiple DNS suffixes – When your Skype for Business infrastructure has disjointed namespaces such that one or more servers have a DNS suffix that doesn’t match the suffix of the sign-in address (SIP) for Skype for Business.
followed by examples:
You can type multiple domain names, separated by commas.
For example: lync.com, outlook.com, lync.glbdns.microsoft.com
For some reason it didn’t click with me as these are all domains used for Office 365 that are publicly accessible DNS zones. My logic was that we were connecting via edge ‘sip.domain.com.au‘ and I had a ‘firstname.lastname@example.org‘ I wouldn’t need anything added because my SIP Address = Edge FQDN domain, plus its bound to matching SAN entries in a publicly signed certificate. Kloud isn’t a hosting provider that services thousands of SIP domains like Office 365 which it cannot have in its edge certificate as Microsoft aren’t authoritative for. This is why Office 365 get customers to add CNAME’s to their endpoints and perform 80 to 443 port wizardry where possible, allowing clients to bind SSL to correct Microsoft service names.
What Microsoft are trying to say is
If your SFB SIP domain doesn’t match your Active Directory infrastructure domain name that your SFB servers are joined to, you need to add via the following
Add ‘domain.local‘ into the Hub via Settings -> This Device -> Calling
Lastly, this doesn’t matter if your logging the Hub in via the internet or internal LAN, you will get this mismatch with all domains that were created not matching the primary SIP/SMTP domain I would suggest. Additionally, if your logging your Hub in via LAN you will most probably need to bundle up some certificates as the Hub will not trust your certificate authority used for signing Front End certificates that would include domain.local SANs which Public Certificate Authorities reject.
You’ll be happy to note that Godzilla and I are now on speaking terms again. We quite regularly have catch ups via Skype with colleagues and its all smiles once again.