Lync TrustModelData

The Issue

Recently, I had a small issue with Lync 2010 clients objecting to the certificate on the autodiscover.company.com CAS server.

The internal domain in use for SIP was company.local, and the CAS had company.com, although autodiscover.company.local was also on that cert.

Interestingly, we first looked at strict DNS naming, however, that did not appear to be the root cause. A colleague pointed out to me that he thought the TrustModelData might be doing it, so we investigated that route.

The error popped up as soon as autodiscover.company.com (the SMTP domain) was added to DNS. Here is the error :

Lync is hardcoded to act on finding Autodiscover, and it immediately attempts to connect to the advertised EWS.  In our case, the SMTP domain does not match the SIP domain (company.com v company.local).

The Fix

As it turns out, there is a registry entry in HKLM to control this behavior – by default this key is populated with a selection of Microsoft Online entries – none of which matched our company.local. We pushed the following registry change with SCCM; GPO was not an option due to XP workstations. 

This option is NOT part of Lync in-band client provisioning, and you can put the entry in either

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\TrustModelData 

OR

HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator TrustModelData

and APPEND your SMTP domain to the list.

The precedence for applying these changes is:

(1) In-band provisioning, (2) HKLM, (3) HKCU, (4) Lync option set in client. 

Because of this ordering, we decided on using HKLM for our registry change so that all users of the workstation would get the change.

YMMV.