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 neccasary 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.