Knowledge Base

Lync 2010 and 2013 client login troubleshooting for Servers

Table of Contents:

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

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:

What is the source subnet and target subnet?

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

Is an Edge server deployed?

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

How many sites and DCS are involved?

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

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.

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:

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

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).

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.

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.

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)

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

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:

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

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

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

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

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

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.

Quick Tips content is self-published by the Dell Support Professionals who resolve issues daily. In order to achieve a speedy publication, Quick Tips may represent only partial solutions or work-arounds that are still in development or pending further proof of successfully resolving an issue. As such Quick Tips have not been reviewed, validated or approved by Dell and should be used with appropriate caution. Dell shall not be liable for any loss, including but not limited to loss of data, loss of profit or loss of revenue, which customers may incur by following any procedure or advice set out in the Quick Tips.