You are currently offline, waiting for your internet to reconnect

Lync cannot verify that the server is trusted for your sign-in address" message during client sign-in

Summary

This article describes two scenarios that occur when the Lync client cannot establish a trust relationship with resources that require a secure TLS connection.

Scenario 1

When a user tries to sign in to Microsoft Lync in a Lync Server 2013 environment for the first time, she receives the following message in a dialog box:

Lync is attempting to connect to:
<Fully qualified domain name (FQDN) of a server>
Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?

For example, the following Trust Model dialog box is displayed:

Screenshot for Trust Model dialog box

Scenario 2

The Lync – Sign In dialog box that's shown in the screen shot in Scenario 1 displays the fully qualified domain name (FQDN) of the organization’s Exchange Client Access Server (CAS) interface that's used by the Lync client to access user mailbox information through Exchange Web Services (EWS). This behavior occurs when the Lync user’s SIP URI contains a domain suffix that does not match the domain suffix of the Exchange CAS’s interface. If the user chooses not to trust the connection to the Exchange CAS interface, the Lync client will not have access to the Exchange mailbox services that are provisioned by EWS.

To confirm this behavior, follow these steps:
  1. Make sure that the Lync client is signed in to on the Windows client’s desktop.
  2. Hold down the CTRL key and right-click the Lync icon in the Windows client’s notification area.
  3. In the shortcut menu, click Configuration Information.
  4. Locate the "EWS Information" line.
  5. If this line contains "EWS not fully initialized," you are experiencing Scenario 2 behavior.
Cause
This issue occurs because the SIP domain name of the user does not match the domain names in the following properties in the certificate of Lync Web Services and Exchange Web Services:
  • Subject Name
  • Common Name
Workaround
To work around this issue, use one of the following methods.

Method 1: Manually modify the TrustModelData registry value

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs.

For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

To manually modify the TrustModelData registry value for the user, follow these steps:
  1. Start Registry Editor on the computer that has the Lync 2013 desktop client installed.
  2. Navigate to the following registry location:

    HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync
    Note If the Lync registry key does not exist, you must create it.
  3. Right-click the Lync key, click New, and then click String Value.
  4. Type TrustModelData, and then press Enter.
  5. Right-click TrustModelData, and then click Modify.
  6. In the Value data box, add the domain of the server that is displayed in the Trust Model dialog box.

Method 2: Use Group Policy to modify the TrustModelData registry value

Use Group Policy to modify the TrustModelData registry value for the user.

For more information about the Lync 2013 Trusted Domain List (TrustModelData) Group Policy, see Configuring client bootstrapping policies.

For more information about the Lync 2013.admx (ADMX) and .adml (ADML) Administrative Templates, see Office 2013 Administrative Template files (ADMX/ADML) and Office Customization tool.
More information
Scenario 1

The Lync 2013 desktop client uses the new automatic discovery mechanism to locate the internal or external Lync Web Service, depending on the network location of the user.

The following process occurs when the Lync 2013 desktop client tries to locate the Lync Web Service:

  1. The Lync 2013 desktop client sends a pair of HTTP and HTTPS requests to locate the Lync Autodiscover Service. The HTTP and HTTPS requests consist of a default set of internal or external host name values and the SIP domain name of the user.

    For example, the Lync 2013 desktop client sends the following requests:

    http://LyncdiscoverInternal.contoso.com and https://LyncdiscoverInternal.contoso.com
    Note "LyncdiscoverInternal.contoso.com" is resolved to the FQDN or IP address of the Internal Lync Web Service.

    http://Lyncdiscover.contoso.com and https://Lyncdiscover.contoso.com
    Note "Lyncdiscover.contoso.com" is resolved to the FQDN or IP address of the external interface of the Reverse Proxy.
  2. The Lync 2013 desktop client receives a response that contains the secure internal and external URLs of the Autodiscover Service from Web Services.
  3. The Lync 2013 desktop client tries to contact the Autodiscover Service by using an HTTPS connection. If the SIP domain name of the user does not match the domain name in the Subject Name or Common Name property on the certificate that is assigned to Lync Web Service, the Trust Model dialog box is displayed.
Scenario 2

The Lync client makes https requests to the Exchange CAS interface as part of its post–sign-in process. These requests include access to the Exchange Autodiscover service through URLs that include the FQDN of the Exchange CAS interface. For example:
  • https://<smtpdomain>/autodiscover/autodiscover.xml
  • https://autodiscover.<smtpdomain>/autodiscover/autodiscover.xml
If the FQDN of the SMTP domain does not match the FQDN of the SIP domain that the Lync client is signed in to, the Scenario 2 issue will occur.
Properties

Article ID: 2833618 - Last Review: 03/09/2015 22:55:00 - Revision: 3.0

Microsoft Lync 2013, Microsoft Lync Server 2013, Microsoft Lync 2010

  • kbsurveynew kbtshoot kbexpertiseinter KB2833618
Feedback
amp;t=">p;t=">/html>/html>=1&t=">