‘Lync can’t connect to exchange. Your contacts list and conversations might have issues’
I came across a problem with a customer who had been instructed to change their users default SMTP addresses as part of a larger company consolidation. This change has created a problem in Lync 2013 where the Lync client can no longer access the Exchange 2013 services such as Calendar and message history.
Historically the smtp address and SIP URI were both firstname.lastname@example.org
The recent instruction requires them to add a further smtp address (contoso.com) to all user mailboxes and make this the default reply address.
So now we have a user with a default smtp address of email@example.com and a Lync sip uri of firstname.lastname@example.org.
The additional default smtp address was added in Exchange and initially everything seemed to be fine. However, they found that following the change, when new PC’s were deployed and Lync profiles configured the Exchange services didn’t work and Lync configuration information in the client showed blank entries for the EWS services (both internal and external). The client also reports an error stating that ‘Lync can’t connect to exchange. Your contacts list and conversations might have issues’
A simple temporary fix was quickly found to change the default smtp address back to email@example.com, delete the sign in info in Lync (both through client and delete the profile folder in windows user profile) – then sign into Lync. Exchange services will connect and you can then change the default SMTP address back to firstname.lastname@example.org – we don’t know if this cached info times out eventually but we had users working for 3-4 weeks before coming across the problem with PC rebuilds.
Looking for a better long term fix and investigating the problem a bit deeper, we could see that when the user signs into Lync using email@example.com, we see a dns query for autodiscover.contoso.com which pointed us in the right direction.
(1) We created a dns record so this address would resolve, the record points at the Exchange CAS
(2) Generate a certificate for the Exchange CAS server and added autodiscover.contoso.com to the SAN
(3) Bind the IIS services on Exchange to the new certificate (cert was generated on internal domain CA)
(4) Additionally we had to add the following reg key to the client PC’s
reg add HKLMSoftwarePoliciesMicrosoftOffice15.0Lync /v TrustModelData /t REG_EXPAND_SZ /d autodiscover.contoso.com /f
With these steps complete, after deleting the Lync client sign in info, signing in again, the Exchange services connected successfully.
Lync configuration (ctrl/right click lync item in sys tray) shows the EWS url’s are now populated
This has resolved the problem internally but we’ll also need to create the autodiscover.contoso.com record externally and put a public cert with both domain names in the SAN on the reverse proxy.