Daniel and I have been quite busy implementing Lync 2013 these days. One interesting gotcha thing we knew, but didn’t give a lot attention about the Lync 2013 client is, that it makes use of the LyncDiscover and LyncDiscoverInternal DNS records. These records were introduced with Lync 2010 Mobility and were used by the mobile clients to locate a sign-in server. Lync 2010 Clients don’t look for them, they use _sipinternaltls._tcp and _sip._tls records for auto sign-in.

With the Lync 2013 Client that changed. The new client now queries for the following DNS records in order to sign-in automatically:

1. LyncDiscoverInternal.ntsystems.it
2. LyncDiscover.ntsystems.it
3. _sipinternaltls._tcp.ntsystems.it
4. _sip._tls.ntsystems.it
5. sipinternal.ntsystems.it
6. sip.ntsystems.it
7. sipexternal.ntsystems.it

So, as you can see, even before trying to locate the SRV records, the 2013 Client tries to connect to the AutoDiscover Web Service. That works just fine, in most situations.

But… in a configuration like the following you might run into this bug get a certificate warning when signing into Lync for the first time from the internal network.

1. You have a disparate namespace (like ntsystems.local for your Lync Servers while ntsystems.it is your SIP domain) AND
2. You use internal certificates on the Front End Servers AND
3. You have Split DNS configured (ntsystems.it on the internal DNS servers) AND
4. You set LyncDiscoverInternal.ntsystems.it DNS record (for public zone on internal DNS server)

The certificate warning shows the server name to which Lync is attempting to connect, it also shows the certificate subject and you can view the certificate. You double (triple) check the certificate, subject alternate names, dates, DNS, basically everything and it seems to be just fine. Still, you continue to get the warning.

Workaround

First of all, I have to say that I do not fully understand why this happens. The way I see it, is that Lync 2013 connects to the internal Web Service (using LyncDiscoverInternal) and all certificate parameters are fine… As you are probably not going to get a certificate for ntsystems.local from a public CA I wonder what the right solution looks like…

The good news: There is a workaround for this, you can use Group Policy to configure Lync 2013 to configure the Trusted Domain List. According to TechNet, this “Lists the trusted domains that do not match the prefix of the customer SIP domain.” – nice. So, I added ntsystems.local to the Trusted Domain List that can be found in User and Computer Configuration under:

Administrative Templates/Microsoft Lync 2013/Microsoft Lync Feature Policies

You can download the admx/adml files for Office 2013 here. The Group Policy adds the domain to the either “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\15.0\Lync\TrustModelData” or “HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\15.0\Lync\TrustModelData” depending on what you choose in the Group Policy Object.

Another workaround would be to simply remove the LyncDiscoverInternal record from the internal DNS zone, which breaks mobile clients (including Lync Windows Store App) on the internal network (Wireless). Not really a solution…

Again, I don’t fully understand the problem, this is what I found during my research. If you have a better solution, please drop me a line :)

Happy New Year and have a nice weekend,
tom