Between the OCS 2007 Deployment documentation, official Resource Kit, and blog/forum posts I’ve seen some discrepancies regarding the exact names (and order) of lookups performed by an Office Communicator 2.0 client when attempting to connect to an Office Communications Server when utilizing Automatic Configuration. Specifically I’ve seen reference to the automatic fall-back of looking for A records starting with sip, or instead with sipinternal, and sipexternal. Well, I discovered that it’s actually all three.
To view the behavior I purposely deleted the DNS records I previously created in my lab environment during initial OCS deployment. After removing the SRV record _sipinterntls._tcp.schertz.local and the A record sip.schertz.local I flushed the DNS cache on my XP guest and launched Office Communicator, and was immediately presented with the error message: "Cannot sign in because the server is temporarily unavailable. If the problem persists, contact your system administrator."
Although you can enable logging from within Office Communicator it is not necessary as the following Application event log entries will be created during the connection failure:
Event ID: 1
Communicator was unable to locate the login server. No DNS SRV records exist for domain schertz.local, so Communicator was unable to login.Event ID: 3
Communicator was unable to resolve the DNS hostname of the login server sipinternal.schertz.local.Event ID: 3
Communicator was unable to resolve the DNS hostname of the login server sip.schertz.local.Event ID: 3
Communicator was unable to resolve the DNS hostname of the login server sipexternal.schertz.local.
So it appears that if no SRV record is found then the fall-back is to look for standard DNS name records in the following order:
- sipinternal.domain.com
- sip.domain.com
- sipexternal.domain.com
Note: Microsoft documentation can be a little misleading in a few places as there are specific requirements on A records versus CNAME records, but this appears to refer to the name records paired with SRV records, meaning that a SRV record must always point to an A record, and not a CNAME record. but for the standard DNS fallback it appears that either a CNAME or A record will work the same.
Next I created a new DNS Alias (CNAME) record of sipinternal.schertz.local and verified my client could resolve the new record. After reopening Office Communicator and attempting to sign-in, a slightly different error message appeared: "There was a problem verifying the certificate from the server. Please contact your system administrator." A peak at the Application log showed two new events:
Event ID: 1
Communicator was unable to locate the login server. No DNS SRV records exist for domain schertz.name, so Communicator was unable to login.Event ID: 4
Communicator could not connect securely to server sipinternal.schertz.name because the certificate presented by the server did not match the expected hostname (sipinternal.schertz.name).
We can see that again the SRV lookup was tried first and failed, but the first name record lookup for sipinternal resolved to a server and a connection attempt must have been successful as the client received a certificate, but failed with a name-mismatch. Using the OCS management tool to access the Front End Server Properties on the server object we can see the currently applied certificate. Clicking Select Certificate, then highlighting the current open from the list and clicking View Certificate will let us look at the Subject Name and Subject Alternative Name fields under the Details tab.
The certificate verification error is reported because sipinternal.schertz.local is not in the certificate’s SAN field, although sip.schertz.local is. This behavior underlines the importance of including any potential sip DNS names in the OCS server certificates.
Next I created another new DNS record for sip.schertz.local, but left the malfunctioning sipinternal record in DNS. Although there was still a certificate error when using sipinternal, Office Communicator will not continue to look for other DNS records, it simply stops at the first successful resolution regardless of what happens after a connection attempt is made to the remote server. So I deleted the sipinternal record and tested sign-in again, which worked correctly utilizing the sip.schertz.local record. At this point I recreated the previous SRV record to restore the previous configuration.
Hi Jeff,
Your detailed post for DNS Lookups with the OCS Automatic Configuration is interesting and more helpful for understanding about what you did for that. I like the way you have written all these information here. i was searching for this DNS Configuration from a few days and finally i got your post and found it easy to understand the things i need.
Thanks for a very informative article!
We are migrating from OCS 2007 to Office 365 Lync. The first requirement is that the SIP logon use our public domain name rather than our .local internal AD domain. The legacy OCS server has a certificate tied to the .local address and not to our public domain. I was able to make the necessary SRV records to theoretically redirect users to the .local OCS server, but the OCS client cannot log in with the outside domain name using the legacy OCS client. Interestingly, I was able to get the Lync client to log in. To do so, I had to push out a group policy disabling server version checking and add the external domain name to the OCS server, but once I did so, the Lync client could log in as user@public-name.com and would get redirected to servername.local. In this way, the cert. was trusted.
I’m trying to avoid buying a SAN certificate for the old OCS Server for the 1 to 2 months we’d be transitioning to Lync online. Is there anything I can do to get the legacy client to work?
No, older clients were hardcoded in a way that Strict-DNS naming is required in the SRV/A record pairings.