Office Communicator client signs into OCS in one of two ways:
1) The OCS server hostname is manually specified in Communicator, or,
2) “Automatic Sign-In” via a DNS query on the SIP domain (the domain portion of the user’s SIP address) which returns the OCS server (or pool).
This is true for clients running both inside and outside your internal network (’outside’ meaning outside the firewall, on the Internet).
The DNS records for automatic sign-in are always front-and-centre when trouble-shooting any Communicator sign-in issues, so I’ll recap the format of the DNS SRV records most commonly needed:
- _sipinternaltls._tcp.<sip domain> (Internal TLS)
- _sipinternal._tcp.<sip domain> (Internal TCP)
- _sip._tls.<sip domain> (External TLS)
- _sip._tcp.<sip domain> (External TCP *)
From a DNS sign-in perspective, Communicator does not know or care whether it is on an internal or external network – it queries for the DNS SRV records in the order listed above, and will attempt a connection on the first match (the hostname specified by the SRV record).
* Although Communicator will search for the external TCP SRV record of the format “sip._tcp.<sip domain>” external connections must use TLS (on the Edge Access).
The DNS SRV record returns a hostname representing the OCS Enterprise Pool or Standard Server. A DNS A record lookup is then performed to get an IP address to connect to.
If no records DNS SRV records are found, Office Communicator performs an explicit DNS A record lookup up in the following order (until it gets a successful match):
5. sipinternal.<sip domain>
6. sip.<sip domain>
7. sipexternal.<sip domain>
Note: In the Communicator R2 client, it appears that the format “sip.<sip domain>” (#6 above) is tried before “sipinternal.<sip domain>”, and #7 is not attempted at all.
InsideOCS has a free downloadable tool, the Automatic Sign-In Troubleshooting Tool, that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.
For more details all the automatic sign-in process and it’s requirements, see:
- Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)
- Automatic Office Communicator Sign-In (Part 2 – ensuring the correct Subject Name on the Certificate)
- Automatic Office Communicator Sign-In (Part 3 – ensuring the client trusts the issuing Certificate Authority)
Note: the manual configuration of Office Communicator clients can be automated through the Microsoft Office Communicator Group Policy.
For additional information, see the following links:
- Microsoft OCS 2007 TechNet Library – Required DNS Records for Automatic Client Sign-In
- Microsoft OCS 2007 R2 TechNet Library – Office Communicator Sign-in and Discovery
- Microsoft TechNet Office Communications Server 2007 – 3.2 Configure DNS for Your Pool
- Microsoft TechNet Article on DNS Records for an OCS Pool and How to Create Them
- Jeff Schertz – OCS 2007 – DNS Lookups with OCS Automatic Configuration
Twitter
LinkedIn
What does Lync do during the automatic sign-in process if it receives a match in DNS but is unable to connect? Will it attempt to connect to the next match in the list above?
Thanks for you reply Curtis.
I am actually using LYNC 2010 and I thought OCS 2007 would be simular.
If I create a new user in the domain A which i have installed LYNC 2010 and the login – the sip sign-in in communicator is automatically populated and user automatically signs in. No user intervention at all (I don’t need to manually enter the SIP) – I have tested on a few users and works really well – not sure how it does it but I guess the new communicator must query AD?
I setup a trust to domain B and when I login as a domain B user the sip sign-in is not automatically populated in communicator and I need to manually enter the sip login. Once logged in subsequent logins are fine.
As all the users will be on domain B (the user domain) I wanted to have the same autologin function (i.e. auto populated the users communicator login in domain b on 1st login). I am guessing that since LYNC 2010 is not installed in Domain B it is unable to query the users SIP login to automatically log them in?
I thought this also happens in OCS 2007 according to this post
http://www.proexchange.be/blogs/ocs2007r2/archive/2009/09/24/reset-sign-in-address-in-communicator-automatic-vs-manual-configuration.aspx
Thanks
ECL
I am not sure I fully understand your scenario, but OCS automatic sign-in means having the correct DNS settings so that Communicator client automatically finds the OCS Front-End server to login to. You are suggesting that the Communicator client queries AD for user’s SIP details. The users SIP details are manually entered into the Communicator client (or auto-populated by a GPO or provisioning software); it does not query AD for this information, and it not part of the automatic sign-in feature.
To my knowledge automatic sign-in should work fine if OCS is deployed in a resource forest.
Hope that helps, Curtis
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
Hi.
I have a pretty large deployment in progress. One thing I dont really understand.
I have one external srv record. _sip._tls.. This points to my server in a datacenter in Atlanta.
I also want a pool in the UK, Australia, and Singapore.
Since I only have one srv record externally for my domain, that means for an internet user, they will always start first by hitting my datacenter in Atlanta, then the director takes over and sends the traffic back to Singapore?
In Singapore, UK, Australia I will have a front end server, a director an edge server, and isa firewall and possibly a mediation server.
[...] to the Front End server so that the auto-discovery process will work properly. The specifics are summarised here. Autodiscovery will still work even without SRV records provided you have the relevant aliases [...]
[...] 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 [...]
[...] DNS Records and Office Communicator Automatic Client Sign-In [...]
[...] DNS Records and Office Communicator Automatic Client Sign-In [...]
[...] the SIP domain of the user attempting to sign-in. The SRV record must be of a particular format. See my previous blog post on what the format of the DNS record should be. The SIP domain is the right-hand-side of the [...]
[...] previous post, DNS Records and Office Communicator Automatic Client Sign-In, summarizes how Communicator uses DNS to connect to the [...]