“Client is not trusted” error on Lync SDK apps and persistent chat add-ins

The conversation window extension (CWE) feature in the Lync client can be quite useful, but it can also at times be incredibly painful to debug. Often the extension panel simply won’t load your application, or the application will load but won’t work correctly. Figuring out what has gone wrong can be a frustrating guessing game if you don’t know where to look. To compound the problem, the configuration necessary to get the CWE working has changed from Lync 2010 to 2013. The CWE problem that has bitten me the most frequently is misconfigured trusted sites, and I wanted to quickly review how this works in both versions of Lync.

First, let me quickly review what I’m talking about. The CWE is the add-in panel that pops out to the right of the Lync conversation window to show a website or Silverlight application. It can be triggered by a UCMA application on the other end of the call, by a Lync SDK application, or can be set to pop up by default for all conversations. Here’s an example of what it looks like in Lync 2013:

Lync 2010 added a feature where, if you load a Silverlight application in the extension panel, you can get a reference to the conversation in which the application is hosted by calling the LyncClient.GetHostingConversation method, and manipulate the conversation, get information on it, or send information back to a UCMA application directly from your Silverlight application. Now, in Lync 2013, you can do something very similar for persistent chat rooms by creating a persistent chat add-in, which loads in an extension panel like the CWE. Again, if you load a Silverlight application, you can get a reference to the room hosting the application by calling LyncClient.GetHostingRoom.

In order for a Silverlight application to use these Lync client SDK features, it needs to be recognized as a “trusted site.” If the location where your application or your persistent chat add-in is hosted is not trusted, you will get an error in your Silverlight code that says “Client is not trusted” and the Lync SDK functionality won’t work.

In Lync 2010, you indicate that a site should be trusted by Lync by adding it to the “Trusted sites” zone in your Internet security settings. You can do this by opening up the Internet options dialog in Internet Explorer, and going to the Security tab:

Next, choose Trusted sites and click the Sites button.

In this window, you can add the domain where your application is hosted.

You can accomplish the same thing with a registry key like the following:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\example.com]
 "http"=dword:00000002

In Lync 2013, this works a bit differently. Lync now has its own special location for trusted sites in the registry. This means that you can’t just go into Internet Options and add the domain there; you need to use a registry key. The format for the registry key looks like this:

[HKEY_CURRENT_USER\Software\Microsoft\Office\Lync\Security\Trusted Sites\example.com]
 "https"=dword:00000001
 "http"=dword:00000000

This indicates that https://example.com will be trusted. If the same URL with HTTP should be trusted, then flip the “http” part to a 1:

[HKEY_CURRENT_USER\Software\Microsoft\Office\Lync\Security\Trusted Sites\example.com]
 "https"=dword:00000001
 "http"=dword:00000001

To install this, all you need to do (after changing the domain to your own, of course!) is copy it into a text file, save it with a .reg extension, and double-click it. You’ll get a few warnings, and the key will be installed into the registry.

I hope this helps a few people who are tearing their hair out over a “Client is not trusted” error. If you’d like more details on getting your Lync 2010 client applications working with Lync 2013, there is some information at MSDN and Tom Morgan also has an excellent blog post on the subject.