I’ve seen this problem at a customer the other day, even though I had a solution to fix it, I do still not fully understand why it happens. So I’m going to document it here, we’ll see if that sheds more light… :)

The Problem

As the title implies, the problem is similar to this one I described earlier, it does however also affect Lync 2010 clients. Once signed-in, the Lync Client will show a certificate warning, indicating that it wants to connect to some Exchange Server but the certificate was not ok, only after double (triple) checking, the certificate really was ok.

Background

Sure enough, the problem only appears in certain environments, the one I was in used different domains for the SIP address and the users primary SMTP address. So, here goes an example:

UserPrincipalName: [email protected]
PrimarySMTPAddress: [email protected]
msRTCSIP-PrimaryUserAddress: [email protected]

When this users signs into Lync, the client will perform an Exchange Autodiscover request, in order to retrieve the Exchange Web Services Endpoint. The certificate used on the Exchange Server had the following attributes:

CN=exchange.contoso.com
DNS=exchange.contoso.com
DNS=exchange.fabrikam.com
DNS=….

Now the warning in the Lync Client says there was a problem connecting to exchange.contoso.com, even though the certificates CN was exactly the same name, that the client tired to reach. Makes sense? Not to me…

Workaround

The workaround I described in the earlier article still applies, just add the Exchange Servers domain to the clients TrustModelData registry entry.

The registry key locations change depending on the client version:

Lync 2010

HKEY_CURRENT_USER\Software\Microsoft\Communicator\TrustModelData

Lync 2013

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync

Type Reg_SZ
Value contoso.com contoso.eu

So if anyone has more information on this one, please do get in touch.

Cheers,
tom

This post has been migrated from our earlier blog based on BlogEngine.NET.