Avoiding Lync 2013 Certificate Prompts

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.

Capture1

Sharing is Caring   

    

Comments from the Peanut Gallery

  1. Rasheedah

    I just spent hours narrowing this down I didn’t see no documentation until you just pointed this out.

    Shame on MS
    THANK YOU SO MUCH for this!!

  2. Yax1

    TrustModelData can be pushed via GPO to hkcu\software\policies\microsoft\communicator
    This applies to lync 2013 clients too.

  3. John Weber

    thanks Tom. This will come in handy on at least the current project and probably the one after that also.

    How you doing?
    John

  4. Julian Claver

    Thanks tom you are a Life send !

Chime In