Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
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.
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.
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:
Figure 1 below shows the authentication process.
Figure 1. Understanding the authentication process
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.
1. Start detecting certificate-related issues from the server by rechecking the certificates assigned to the Edge Server internal and external interface.
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:
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.
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.
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.
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:
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.
By default, IIS logs are located in folder %SystemDrive%\inetpub\logs\LogFiles.
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:
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.
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:
Tools that should be run after the fact:
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 “email@example.com” |fl > get-csuser.txt.
Keywords: List any keywords that would help readers find this article.