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… :)
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.
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:
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…
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|| |
|Lync 2013|| |
So if anyone has more information on this one, please do get in touch.
This post has been migrated from our earlier blog based on BlogEngine.NET.