Lync 2013 and the introduction of the lyncdiscover client bootstrapping process has introduced a new world of hurt for many Lync deployments, especially those that contain multiple SIP domains. I won’t go in to the guts of why or how this happens – Richard Brynteson and Jeff Schertz do a great job explaining this aspect. The gist of the issue is your users will see a certificate warning in either of these two scenarios:
- The lyncdiscover.<Your SIP Domain Here> query returns a web services FQDN that doesn’t end with <Your SIP Domain Here>.
- The lyncdiscover query returns a web services FQDN that ends with <Your SIP Domain Here> and succeeds, but then returns a SIP pool FQDN that doesn’t end with <Your SIP Domain Here>.
So, how to work around this? You have a few options.
Keep all FQDNs within the SIP Domain Namespace
A typical deployment will put the pool FQDN within the namespace of the Active Directory domain, but you can actually name the pool anything you’d like when adding it to Topology Builder. You avoid the prompt by creating a pool FQDN and web services FQDN that are both within the primary SIP domain namespace. So, to provide an example configuration:
- Active Directory Domain: ptown.local
- Primary SIP Domain: confusedamused.com
- Front End Pool FQDN: pool.confusedamused.com
- Internal Web Services FQDN: webservicesinternal.confusedamused.com
This option only works if you’re deploying an Enterprise Edition pool, and only resolves the warnings for your primary SIP domain. Other SIP domains serviced by this pool will still get the certificate warning. While it’s technically possible to modify the internal web services FQDN on a Standard Edition pool you can’t change the pool FQDN, so there is no point.
Configure the Trust Model Data
For those running Standard Edition pools or Enterprise Edition pools with multiple SIP domains, you’ll need to configure the TrustModelData registry key outlined in KB 2531068.
In Lync 2013 the key no longer exists by default, and the location of the registry settings have shifted slightly from the KB article. They can now be found in HKLM\Software\Microsoft\Office\15.0\Lync.
One other change to watch out for is that the client doesn’t actually read a TrustModelData key in the HKLM hive (true at least on Windows 8.) It will only read the HKCU version. In order to work around this issue you can deploy the key to the HKCU hive for all users via GPO preferences. The value specified should be a comma separated list of domains for the pool or web services FQDNs, which will typically be your Active Directory namespace.