LyncMD: Troubleshooting Lync Server 2010 when a Remote Sign-In Fails Due to Certificate-Related Issues

Posted on by — No Comments ↓

This post has been republished via RSS; it originally appeared at: Skype for Business Blog articles.

First published on TECHNET on May 23, 2013

Series Lead : Premal Gandhi, Microsoft Senior Supportability Program Manager


Authors : Sunil Kumar, Consultant | Arnab Sarkar, Support Escalation Engineer | Pankaj Rai, Technical Support Lead | Mahesh S, Service Delivery Manager


Published : May 23, 2013


Product Version : Lync Server 2010


Lync Server 2010 Edge Server is installed to provide support for external user access for all SIP-enabled users. The Edge Server provides Access Edge, Web Conferencing, and A/V Edge service. After deployment, the service should start. If it doesn’t start, there are either issues with replication, an incorrect certificate, or a dependency service that has not started. This troubleshooter provides a brief introduction to basic login and authentication processes that can be used to troubleshoot both internal and remote login issues.


LyncMD Series Note


Microsoft Escalation Engineers are experts in troubleshooting and resolving the toughest and most complex issues with Microsoft Lync Server. Your issue may not have the same root cause mentioned in the example. However, the troubleshooting approach, tools, and data gathering are similar. The process outlined in this article aligns with the troubleshooting methodology used by Microsoft Escalation Engineers when approaching an undocumented issue.


This article is the first in a series of three LyncMD articles that provide guidance for troubleshooting Lync Sign-In, Presence, IM, and Contacts issues, including troubleshooting tools, steps for resolution, and the necessary data to gather for each scenario prior to directly escalating an issue to Microsoft Customer Service and Support Escalation Engineers.


Background


Lync Server 2010 Edge Server is installed to provide support for external user access for all SIP-enabled users. The Edge Server provides Access Edge, Web Conferencing, and A/V Edge service. After deployment, the service should start. If it doesn’t start, there is either an issue with replication, an incorrect certificate, or a dependency service that has not started.


This troubleshooter provides a brief introduction to basic login and authentication processes, which can be used to troubleshoot both internal and remote login issues. The login process seems simple from the user perspective, because it only involves starting Lync with valid credentials. However, it actually entails a number of complex interactions between Lync Server 2010 and the Lync 2010 client. Understanding these interactions is critical for troubleshooting user login failures, client connectivity, authentication, and discovery issues.


For planning, deployment, and supportability information, see:



Understanding the Authentication Process


Figure 1 below shows the authentication process.




Figure 1. Understanding the authentication process


Remote Sign-In Fails Due to Certificate-Related Issues Cause


The certificate requirements for Edge Server include both an internal certificate and external third-party certificate from a known certificate authority. Certificates are required for TLS and MTLS connections.


The internal interface of the certificate is typically a certificate from the Internal Enterprise Root Authority. The external interfaces on Edge Server are configured with a Public Certificate. Remote sign-in issues related to a certificate are caused by misconfigured certificates, unwanted certificates in different stores, untrusted certificates, missing private keys, and wildcard certificates. Certificates must be enabled for all purposes. Cached information is provided on the client machine for a specific user.


Detection


1. Start detecting certificate-related issues from the server by rechecking the certificates assigned to the Edge Server internal and external interface.



  • Check the MMC on Edge Server and verify the certificate assigned to it. Alternatively, run the Certificate wizard from the Lync 2010 Deployment wizard, and determine the certificate assigned to the internal Edge interface.

  • Always assign a private or internal certificate to the Internal NIC. If there is a public certificate assigned to the internal interface of Edge Server, assign an internal certificate temporarily to detect any issues.

  • If you are not sure about the root certificate installation, ensure that the root certificate is installed on all the clients and servers.


    • Start MMC on the local computer, add Snap-In for local computer Certificate Store , and check Trusted Root Authority .

    • Check for the root certificate from Certificate Authority used on the Edge Server deployment.

    • In the same Certificate Store , click Intermediate Certificate Store , and verify the Intermediate Certificate.

    • Look for Unwanted Certificate in Root Store , Personal and Intermediate Store .



2. In Local Computer Trusted Authority, check for the number of certificates . Ensure that this number does not exceed 100.


Most of the record data exchanged during the handshake process is considerably smaller than the 16KB limit defined in the RFC. The potential exception to this is the trusted root certificate list record. If a server trusts more than approximately 100 root certificates, the root certificate list could exceed the 16KB limit, and the connection would be terminated. (For more information, see SSL/TLS Record Fragmentation Support .)


3. The certificate must be set to Enable for All Purpose. This option can be found in the Property dialog box for the certificate .


4. Perform a network capture for the Lync remote sign-in process, as follows:



  • Download Microsoft Netmon 3.4, and install it on the remote client computer.

  • Start the Network Monitor Tool, and select the appropriate network card.

  • Start a Network Capture, and try to sign in to the Lync 2010 Client.

  • Filter the trace for protocol TLS, and verify the TLS handshake procedure.

  • Find out which party involved in TLS negotiation is resetting the connection (RST).

  • Locate the peer responsible for resetting the connection.


5. If you deployed HLB in the Lync topology, then verify that the certificate on HLB has not expired and is trusted by your Edge Servers and remote clients.


Resolution


1. Ensure that remote clients have the root certificate installed and unwanted certificates are deleted.


2. Enable certificate for all purposes.


3. Ensure that Trusted Certificates in the Trusted Root Authority of the local computer do not exceed 100. If there are more than 100, delete unwanted certificates.


4. To verify the remote sign-in process, analyze the network monitor capture and recheck certificate SAN entries, subject name, and private key association for certificates on the servers.


5. For cached information, you can delete all personal certificates.


6. Delete the certificates in the following folder: C:\Documents and Settings\(USER)\Application Data\Microsoft\Crypto\RSA\ (a recent folder/string name). This folder stores PKI information for the user after signing into Lync.


Verification


1. Run the Remote Connectivity Analyzer Tool .


2. Sign in to a Lync client, and test if you can sign in successfully. If you can sign in, then the issue is fixed.


Data Collection Checklist for Escalation to Microsoft


Use the following data checklist to gather data prior to engaging Microsoft Escalation Engineers for support. When your scenario does not exactly match the scenario listed in the article, isolate the involved servers and features. When the issue has been isolated, gather the following core data:



  • Event Logs (preferably gathered with MPS Reports) from the involved servers.

  • Lync Server Logging for the S4 and SIPStack components.

  • Lync client logs (UCCP and ETL) for any affected clients.

  • Get-CSUser output for an affected user(s).

  • Get-CsTopology -AsXML | Out-File C:\Logs\Topology.xml

  • Use SDP Manifest to collecting data from the front-end server.

  • Collect output from the Lync Server 2010, Best Practices Analyzer .


Lync Client Logging to Collect the uccp and etl Logs


Lync client-side logging is a valuable troubleshooting tool, which can be enabled with the following steps:


1. In the upper-right corner of the Lync main window, click Options .


2. In the Lync > Options dialog box, click General .


3. Under Logging , select Turn on logging in Lync and Turn on Windows event logging for Lync .


4. Click OK .


5. Restart Lync , and then try to reproduce the issue. The result will be a Communicator-uccp.log file, as well as some Windows ETL files, all located in username\tracing.


Gather IIS Logs If Needed


By default, IIS logs are located in folder %SystemDrive%\ inetpub\logs\LogFiles.


Lync Server 2010 Logging Tool


The Microsoft Lync Server 2010 Logging Tool facilitates troubleshooting by capturing and logging tracing information from the product while the product is running. The Logging Tool with the Lync Server administrative tools can be used to troubleshoot issues on any Lync Server role.


The Lync Server 2010 Logging Tool generates log files on a per-server basis, so it must be actively running and tracing on each computer for which you want to generate a log.



Figure 2. Lync Server 2010 Logging Tool


Unless otherwise noted, you should use the following when gathering traces:



  • Level: All

  • Flags: Check All

  • Type: New File

  • Maximum Size: 100 MB


Data Capturing Process


Data gathering often requires additional tracing or network captures to be started. It is crucial that the relevant logging be gathered during the issue itself. To ensure this is done, follow the steps below when gathering data for the scenarios in this article series.


Gathering Data


1. Ensure that all previous logs are archived. This will minimize the amount of data that needs to be analyzed and narrow the scope of the logs to the current problem.


2. Ensure that all the trace logs and network monitor traces above have started capturing.


3. Reproduce the issue.


4. After the issue has been reproduced, stop all tracing and collect the logs.


5. Give the file a descriptive name (e.g. NetMon_From_Client1.cap, Get-CsUser.txt).


6. Compress the data to minimize the upload time when escalating the issue to Microsoft.


Logging that needs to be gathered while reproducing the issue:



  • Lync Server Logging Tool Logs

  • Network Monitor captures

  • Lync Client Logging


Tools that should be run after the fact:



  • MPS Reports

  • PowerShell cmdlets collecting configuration information


PowerShell cmdlet Guidelines


Most scenarios involve gathering configuration information using PowerShell. When running these cmdlets, it is important to pipe the results to the Format-List cmdlet, in order to present the output as a list. Example: Get-CSUser –Identity “user@contoso.com” |fl > get-csuser.txt.


Additional Information



About the Authors











Premal Gandhi is a Senior Program Manager (Supportability). He works with the Services and Product teams driving solutions for top support issues, which feed the Lync Top Solutions site and the NextHop LyncMD series. Premal authored the Lync Diagnostics Packages for Client and Server , available through the Microsoft Fix It Center for self-help. He also developed the Lync Connectivity Analyzer , which is now part of the Microsoft Connectivity Analyzer .










Arnab Sarkar is a Support Escalation Engineer. He has always been passionate about technology. He also enjoys playing Cricket and Volleyball. He loves watching movies and music energizes him.










Pankaj Rai joined the Microsoft Unified Communication Premier Support team 2½ years ago. He is a Technical Support Lead for Lync Online and works out of Bangalore.










Sunil Kumar is a Lync Technical Support Lead for Partners. He engages with partner teams for their technical readiness and is responsible for Lync On Premise broad commercial business for the US/EMEA/IND/APAC region.

Lync Server Resources



We Want to Hear from You



Keywords : List any keywords that would help readers find this article.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.