I was recently involved in a situation where the SIP domain was different from the internal AD domain. This could be the case if your organization supports multiple SIP domains, or you have a “split-brain” DNS configuration (i.e. there is one DNS zone for the outside world such as “example.com”, and another DNS zone used only in the internal organization such as “example.corp”).
In this situation, the user SIP domain and the FQDN of the OCS server or pool will be different. To make the automatic sign-in work for Communicator in this scenario the DNS records used for automatic sign-in, and the OCS certificate on the front-end or enterprise pool needs to be tweaked. I explain these below.
DNS Records
Communicator clients find an OCS server or pool to sign into via DNS SRV records (this process is well documented – my posting DNS Records and Office Communicator Automatic Client Sign-In describes it). Normally the SRV record resolves to the FQDN of the OCS standard edition host or OCS enterprise pool name, and a DNS A record lookup then yields an IP address.
When the SIP domain does not match the internal AD domain, the primary DNS zone (which your client computers reside it) should resolve to a FQDN matching the format “sip.example.com”, and then an DNS A record should be added for “sip.example.com” that resolves to the IP address of OCS front-end. In this case “example.com” refers to your SIP domain (the host portion of the SIP URIs that are assigned to users).
For example, if my SIP domain was example.com, and TLS was the transport protocol used to connect to OCS, I would need a DNS SRV record for “_sipinternaltls._tls.example.com” that resolved to “sip.example.com”, and a DNS A record that resolved “sip.example.com” to the IP address of my OCS front-end server.
Tip: if the corresponding TCP SRV record exists, and TCP is enabled on the OCS server, the Communicator client will silently fail on the TLS connection and use the TCP transport. If you enable Communicator Event Logging you will see an event log error stating the there is a mismatch between the SIP domain, and the OCS domain.
Certificate Requirements
The significant requirement differing domain scenario to work is that the SIP domain needs to be specified in the certificate Subject Alternative Name (SAN) list in the format “sip.example.com” (i.e. “example.com” is my SIP domain). Most documentation references this requirement even if your SIP domain and AD domain are the same, so this might already be set in your environment.
In an enterprise pool, all front-ends needs this certificate. Note: the Subject Name requirements stay the same.
More information about OCS and automatic sign-in:
Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)











Twitter
LinkedIn
Hi, Great post
I have question which I hope you can help with.
Does automatic sign-in work when the OCS installation is in the resource forest?
I find the users able to login in the Accounts forest when they manually enter
their SIP:email. But I just can’t get it to auto populate the sign on the 1st
login. P.S automatic login works fine in the resource forest. I think it is
something to do with the fact that the Accounts forest does not have the users
SIP details hence the OCS client can’t query AD for the users SIP address on
login?
Any pointers will be most welcomed.
Thanks
ECL