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.



Recent content I've written for you—just for you!— to enjoy while you're here.


Quick commentary and links to other sources you'll find interesting. I promise.


Some personal background, links to related projects, and other ways to connect.

Hi there. My name is Tom Pacyk and this is my small home on the web. I love the intersection of design, technology, and communication, which is a combination that led me to a career in sales and marketing roles at places like Zoom and ServiceNow. They're a bit old now, but I also had the opportunity to publish a couple of books along the way.

Portland, Oregon is home for me, my wife Beth, and our three kids, but I'm actually a Midwestern transplant—I grew up in the Chicago suburbs and went to school at Purdue and Illinois. When I find some free time I'm probably going to concerts, rooting for the Portland Timbers, or working on my Sunshine Burn Photography project.