Lync 2010 and 2013 client login troubleshooting for Servers

This article provides information on how to troubleshoot a Lync Client.

Table of Contents:

1. Collect Deployment Specific Details
2. Test the Lync Client connection
3. Reset the Lync Client
4. Fix the Issue

Issue 1: Collect Deployment Specific Details

Before beginning to troubleshoot issues on Lync deployments, take a moment to find the characteristics of the deployment. Some questions to ask might include:

1. What is the source subnet and target subnet?

2. How many firewalls, routers, and switches are part of the Lync network?

3. Is an Edge server deployed?

4. Are VLANS used? How many and are they well connected?

5. How many sites and DCS are involved?

6. What is the name of the Sip domain? Is it the same as the mail domain or domain name?

7. Are public certificates being used?

Microsoft has formalized the process into a checklist: The Microsoft Lync Check List.  Another tool that can be helpful is the Lync Planning Tool. Answering questions on the Lync Server Planning Tool will generate a network diagram. Provided the questions were answered with the actual setting of the Lync deployment, this will generate  an accurate network topology diagram that can be used to proof the Lync environment for best practices.

Back to Top

Issue 2: Test the Lync Client connection

An important Lync client troubleshooting step utilizes the client information property. Using the keyboard, hold the control key and right click the Lync icon, at the bottom right corner of the windows task bar. You will see a choice called configure information. choose this option as seen below in Figure 1.

Figure 1.

Review and research failure lines from Figure 2 below. For Example the EWS failure line may indicate there is an Exchange communication failure. While this may not be a root cause, this would point to to failure between Exchange and Lync. See the remote unified communications troubleshooting tool (RUCT tool) at the end of this article. The RUCT tool may be able to help explain why some of the failures in figure 2 may be occurring.

Figure 2.

Manual configuration

If you find connection problems from the Lync information, compare the results with using a manual configuration. The steps to set manual configuration are:

1. Verify the configuration mode is automatic (tools ->options-> advanced on the Lync client)

2. If the configuration is already automatic and fails, try putting in the connection IP address (Figure 3).

Figure 3.

Address Lookup

Another step to isolate the failure to IIS or http is to verify the lync.domain.com/abs/handler URL. Place this http address into a browser on the affected client.

Failure indicates a connection problem with IIS on the Lync server. See TechNet documentation for more information. Along a similar path of troubleshooting, port failure. Verify the SRV record for automatic client login. Type enter after each line below:

• Nslookup (enter)

• set type=srv (enter)

• _sipinternaltls._tcp.contoso.com (enter)

If the lookup fails, either the service locator record (SRV) is missing from the server DNS, or there is a blockage in the connection to the server. another connection point that must be reachable is the Lync server fully qualified domain name. Start a new nslookup session and type fqdn.domain.com to verify the fully qualified domain name can be reached.

Lync Client Logging

If all checks out to this point, turn on Lync client logging on the Lync client itself. See Figures 4 and 5 below. (click the gear symbol (Figure 4) ->tools -> options-> general on the Lync client). You can see check boxes to turn logging and event errors on (Figure 5).

Figure 4.

Figure 5.

If logging use the The Remote UC Troubleshooting Tool (RUCT) to verify the SRV is resolvable. You can also verify if the client had access to all the necessary certificates, ports, and connection records.

Back to Top

Issue 3: Reset the Lync Client

If there is an error during login, the error may suggest client authentication failure. The error may even call out a certificate problem. Cached credentials or certificate problems can be fixed by clearing the history on the client machine. The easiest way to test for this problem is to create a user who has never logged in anywhere. A new user has to communicate to the Lync server and get new credentials and certificate registered on the client. If this user is able to login, then we suspect the following will resolve the problem for existing users.

1. Verify there are not oddities in the way the DNS records are made. If they have a different exchange accepted domain, a unique SIP domain, and have a .local and .com domain name, it can become confusing. refer to the Microsoft documentation for specific scenarios where the naming schemes are complex.

2. Clear user credential history by clearing the cache from the "credential locker" . find this locker in windows 7. the path is  Control Panel\All Control Panel Items\Credential Manager (or type "cred" into the start-> search on windows 7)

3. Clear user registry history:

• Go to the registry and remove the user specific registry keys
• Remove the problem user principle name folder from HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient
• Remove the problem user principle name folder from HKEY_CURRENT_USER\Software\Microsoft\Communicator\ConfAddin\
• Remove the user folder from \Users\username\AppData\Local\Microsoft\Communicator
• Run ipconfig /flushdns && ipconfig/registerdns on the client
• On windows XP,  Open Windows Explorer and go to C:\Documents and Settings\User\Application Data\Microsoft\Crypto\RSA\ folder and  Delete the RSA key subfolder

Back to Top

Issue 4: Fix the issue

You may notice most of the Lync material here was related on how to find information. Realize its not the Lync client which is usually having to be fixed. As this articles illustrates, the Lync client depends on the server connection being set correctly. To summarize what to look for:

1. DNS - The client must be able to resolve the FQDN of the Lync Front end server.

2. SRV. the client looks for the auto configuration record after fining the Lync FQDN

3. @domain. The client checks your sip domain to see if there is any Front end servers with that name, using SRV records

4. If the domain is found, It will check the client certificate on the server.

5. The server and client certificate both need to be trusted. (issued by the same authority).

6. If the Certificate is OK,the client will negotiated authentication. This will be NTLM or Kerberos.

Peripheral barriers to the process include but are not limited to antivirus, firewall port blocking, cached credentials and certificates, improper authentication settings,virtual directories, user credentials incorrect or not set up in Lync control panel.

Hopefully, This gives some direction where to begin to fix the issues, when faced with Lync client logon trouble. Please review additional resources from Microsoft TechNet Blogs and  Microsoft TechNet.

Back to Top