Using Server-Side Logging to Troubleshoot Lync Server 2010 Mobility Issues

Sometimes, the quickest way to troubleshoot a Lync Server 2010 mobility issue is to view the server-side logs. In this article, we'll show you how to use server-side logging to gather the data you need. You will also learn how to spot a problem and determine what's gone wrong.

Author: Rob Pittfield

Publication date: May 23, 2012

Product version: Lync Server 2010

I recently moved to the Lync Office 365 Dedicated integration team. One of our team objectives is to determine how to deploy and integrate new features into our customer deployments. Recently, while working on mobility in our labs, I surfaced a few deployment-related issues. In most instances, I used server-side logging to figure out what was wrong and how to resolve the issue.

Getting Started

Sometimes, when you don’t have the actual client device needed to test a scenario, you can’t get enough information to troubleshoot a mobility issue from the client perspective. This article helps narrow down and resolve Lync mobile issues from the server-side and identifies which logs to review. For additional insight into troubleshooting mobility issues see Troubleshooting External Lync Mobility Connectivity Issues Step-by-Step.

The easiest place to start the log review and collection process is the Internet Information Services (IIS) logs on the Microsoft Lync Server 2010 Front End Server. By default these files are located in C:\inetpub\logs\LogFiles\. Before you start, be sure that logging is enabled; if you need additional information see How to Enable or Disable Logging in IIS. Two instances of logs are collected – one for the internal website logs and one for external website logs. In this instance I’m focused on the external logs. The process is the same for the internal logs.

After an external client initially logs in using Microsoft Lync 2010 for Windows Phone, you will see these requests (see Figure 1) in the IIS logs. If you see all these specific requests and responses, the mobile client should be fully functional. Use a successful log action as a baseline and compare it to a failed log action. By comparing the two, you can readily determine where things went wrong and what should happen next.

#Software: Microsoft Internet Information Services 7.5

#Version: 1.0

#Date: 2012-04-19 21:48:48

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken 2012-04-19 21:48:48 GET / 8080 - NativeHost 200 0 0 12650

2012-04-19 21:48:48 GET /Autodiscover/AutodiscoverService.svc/root 4443 - NativeHost 200 0 0 286

2012-04-19 21:48:48 GET /Autodiscover/AutodiscoverService.svc/root/user format=json 4443 - NativeHost 401 0 0 4

2012-04-19 21:49:00 POST /WebTicket/WebTicketService.svc/mex - 4443 - NativeHost 200 0 0 11784

2012-04-19 21:49:01 POST /WebTicket/WebTicketService.svc/Auth - 4443 - NativeHost 200 0 0 910

2012-04-19 21:49:01 GET /Autodiscover/AutodiscoverService.svc/root/user format=xml 4443 NativeHost 200 0 0 608

2012-04-19 21:49:15 POST /Mcx/McxService.svc/mex - 4443 - NativeHost 200 0 0 13450

2012-04-19 21:49:20 POST /Mcx/McxService.svc/WebTicket_Bearer - 4443 - NativeHost 200 0 0 4350

2012-04-19 21:49:20 GET /Mcx/McxAsyncDataChannel.ashx sid=4368ab8f-0865-e90e-d1c0-0bff47902377&AckID=0&timeout=60000&UA=True&TimeStamp=129793457251920000 4443 - NativeHost 200 0 0 159

2012-04-19 21:49:20 POST /Mcx/McxMainCommandHandler.ashx TimeStamp=129793457252170000 4443 - NativeHost 200 0 0 277

Figure 1. Sample IIS log file.

Let’s examine the log file shown in Figure 1. The first line is: 2012-04-19 21:48:48 GET / 8080 - NativeHost 200 0 0 12650.

Table 1 describes the key elements in the first line.


This is the requested URL.



This is the port connection. 

NOTE:  When using Lync on a Windows Phone, it's possible for the initial lyncdiscover external connection to use TCP port 80 HTTP. Port 8080 is used from the reverse proxy to the Front End Server.  The remaining connections use SSL on TCP port 4443. 


This is the User Agent string for Windows Phone. iOS uses the string darwin and Android uses the string acomo.


This is the HTTP Response code. It should be 200 in every instance except for the first request for /autodiscover/AutodiscoverService.svc/root/user. On first request it shows a 401 response. This lets the client know authentication is required. With the exception of the first 401 response, any response other than a 200 should prompt additional logging and tracing. For additional information on HTTP status codes see The HTTP status codes in IIS 7.0 and in IIS 7.5. 

Table 1. Key log elements.

There is additional information in an IIS log file, but for our purposes let’s focus on things that may have gone wrong when a Lync 2010 for Windows Phone login fails.

Open the IIS log file, and figure out where it diverges from your baseline. Find the relevant lines and see where the first failure occurred. The following list contains the same URLs, with the full FQDNs that were used for the connections, shown in Figure 1. After you identify where the error occurred, you can configure the Lync Server 2010 Logging Tool to analyze the file. Below are five different logs collected using the Lync Server 2010 Logging tool. Look to see which URL shows errors in the IIS log file. For detailed information on using the Lync Server 2010 Logging tool to collect and review data, see the Lync Server 2010 Logging Tool.

1. If you see any errors with these three URLs, select Autodiscover in the Lync Server 2010 Logging Tool.

  • (this shows a 401 on first request)

2. If you see anything other than a 200 response to these two requests, select WebInfrastructure in the Lync Server 2010 Logging Tool.


3. If you see anything other than a 200 response here (this is the second request for this information and it should contain valid authentication information), select Autodiscover in the Lync Server 2010 Logging Tool.


4. If you see anything other than 200 responses here, select McxService in the Lync Server 2010 Logging Tool.


5. If you see anything other than a 200 response here, select Dlx in the Lync Server 2010 Logging Tool.


NOTE: You may not see the Group Expansion URL if there are no Exchange Distribution Groups in the contact list of the user testing.

NOTE: is the external reverse proxy URL name above.

Figure 2 shows the Lync Server 2010 Logging tool with Autodiscover selected. Note that Level is set to All and the All Flags checkbox is selected under Flags. This setting is recommended for the log types recommended below.

Figure 2. Lync Server 2010 Logging Tool

Understanding Log Files

Understanding the output of these logs can be challenging. The following tips can help you make sense of the logs:

Search for TL_ERROR or TL_WARN. Lines in the log file that start with those two words are usually the most helpful way to narrow down an issue.

Sometimes, logs can be incredibly large due to the number of users connecting to the system. The application is a commonly used tool. Tom Laciano showed me where to download it -- Powerful log file analysis for everyone [Releasing TextAnalysisTool.NET!]. Tom explains how to use it on his blog, see TextAnalysisTool.Net – Fantastic tool for analyzing large log files.

If the information in the TL_ERROR or TL_WARN lines is not immediately helpful, and you see an error code in those lines that appears relevant, use cserror.exe to look up the error code (for example, cserror.exe 0x80092013). You can download the cserror.exe tool as part of the Lync Server 2010 Resource Kit at Microsoft Lync Server 2010 Resource Kit Tools. Whenever possible, these tools should be installed on every Lync Server in the deployment.

If cserror.exe doesn’t provide helpful information, you can also try the err.exe tool. It uses the same syntax as the cserror.exe tool. Sometimes the error is on the network or in a call to another Windows component. You can download the err.exe tool at Microsoft Exchange Server Error Code Look-up. The download link states it’s for Exchange; however, it works for most Windows error codes.

If you still haven’t found something helpful, go to the end of the log and slowly work your way back up the file. Look for clues about what the gateway was doing. For example if connecting to another service or another component returns an error. When you see something of interest, research that part of the log. Keep in mind the order the processes should occur in. This process takes patience and practice to get used to, so don’t be discouraged if you can’t immediately find what you’re looking for.

Compare a log file with an error, to a log file of a connection that works. Look for the instance where the processes diverge. This helps you quickly understand where things went wrong.

Troubleshooting Lync for Windows Phone related issues can be a challenge. This article provides an overview of how to identify connection errors using server-side log files. Reading log files takes practice. You will find, however, that log files can provide you with the clues you need to effectively troubleshoot connection errors. If you’re unable to determine the cause of the issue from the information in the log, contact Microsoft Support.

Additional Resources

Lync Server Resources

We Want to Hear from You

Keywords: Lync Server, Mobility, Troubleshooting, IIS.

Comments (5)
  1. SMS Bradley says:

    Excellent article Rob, thank you! Would love to see a few more troubleshooting articles along these lines, from an insider's perspective. But wait, you are already working on a series! 🙂

  2. Karlos says:

    I can't see Autodiscover, MCXService on Loggin tool options, How I can add this????

  3. Rob Pittfield says:

    Hi Karlos,

    If you have the mobility services installed on the Front End Server you should see Autodiscover and MCXService in the Lync Server Logging tool as options.  Ensure you're running this on that server and these services are installed.

  4. I've followed another post by you on troubleshooting mobile connectivity – TS guide for external connectivity using mobile clients. It passed all the tests. However, when I run…/domain

    the output contains NULL values for

    SipClientExternalAccess":null,SipClientInternalAccess":null,"SipServerExternalAccess:null, SipServerInternalAccess":null}}

    What would this indicate?

    When we try mobility using our internal Wi-Fi, it works perfectly. Changed the 'Exposedweburl' to external. No joy yet

  5. Rob Pittfield says:

    Hello Luke,

    I'm actually not certain what that would indicate.  This question would be much better suited to directly asking support.  Could you get a support case opened to look at this issue?


Comments are closed.

Skip to main content