Lync2013 Logging and Tracing 12 Dec 2012
Most of us who have done troubleshooting and analyzed SIP traces on Lync2010 will be familiar with the Lync Server Logging Tool and Snooper. However, there are significant changes in the way Lync Server 2013 provides logging and analysis for troubleshooting. The Lync Server Logging Tool is now gone and replaced by the Centralized Logging Service (CLS). This article expores the CLS architecture and how to conduct basic logging and SIP trace analysis for the new Lync2013 server.CLS enables IT administrators to manage logging and search logs across all Lync servers in a deployment centrally rather than on individual servers. This is an advantage as one no longer needs to enable logging and having to look at traces on multiple front end servers in a pool. Now, we can start, stop and flush trace logging for any or all machines in the deployment from a single location. Administrators can also turn on logging based on scenarios on a per pool/machine for the entire deployment. From a centralized location, we can then search and trace these logs based on specified parameters.
CLS Architecture Overview
Two main components form the CLS:
1. CLS Agent - runs on every Lync server and controls logging based on commands from the CLSController. It also manages log files for drive space usage and moves old logs to a fileshare. The ClsAgent listens for commands on the following ports: TCP 50001, 50002 and 50003
2. CLSController - sends start, stop, fiush and search commands to all CLSAgents in the deployment. It aggegrates search results from CLSAgents and is available on every Lync server in C:\Program Files\Common files\Microsoft Lync Server 2013\CLSAgent
CLS logging is performed based on scenarios and there are a set of built-in scenarios that specify a group of components and log levels to be started and stopped together. Some examples of these scenarios include:
1. CLS Agent - runs on every Lync server and controls logging based on commands from the CLSController. It also manages log files for drive space usage and moves old logs to a fileshare. The ClsAgent listens for commands on the following ports: TCP 50001, 50002 and 50003
2. CLSController - sends start, stop, fiush and search commands to all CLSAgents in the deployment. It aggegrates search results from CLSAgents and is available on every Lync server in C:\Program Files\Common files\Microsoft Lync Server 2013\CLSAgent
CLS logging is performed based on scenarios and there are a set of built-in scenarios that specify a group of components and log levels to be started and stopped together. Some examples of these scenarios include:
|
AddressBook
AlwaysOn ApplicationSharing AudioVideoConferencingIssue CAA CLS CPS DeviceUpdate |
HostedMigration
HybridVoice IMAndPresence IncomingAndOutgoingCall LILRLegacy LILRLYSS LYSSAndUCS MediaConnectivity |
MeetingJoin
MonitoringAndArchiving RGS SP UserReplicator VoiceMail WAC XMPP |
To find out specific details on a particular scenario, we can use the Lync Management Shell cmdlet Get-CsClsScenario cmdlet as shown below:
There's a special "AlwaysOn" scenario available that can be turned on all the time. It logs at the "INFO" level for many common components used in troubleshooting. By using "AlwaysOn", the idea is that admins don't need to reproduce the issue again, but rather that when an issue occurs there will be enough info in the component logs to debug. If the logs from "AlwaysOn" are not sufficient, then you still need to turn on the specific scenario relevent to the issue, reproduce the issue and get a higher level of logging. At any given time, one additional scenario can be enabled along with "AlwaysOn".
Getting Started with CLS
OK enough about the architecture and let's get started using CLS to capture some logs. Let's first start AlwaysOn logging for the entire deployment followed by another scenario for a specific pool. Finally, we get the current SipStack log for a specific pool:
ClsController.exe -start -scenario AlwaysOn
CLSController.exe -start -scenario IncomingAndOutgoingCall -pools lync2013.apbeta.local
CLSController.exe -search -components Sipstack -pools lync2013.apbeta.local > sip.log
ClsController.exe -start -scenario AlwaysOn
CLSController.exe -start -scenario IncomingAndOutgoingCall -pools lync2013.apbeta.local
CLSController.exe -search -components Sipstack -pools lync2013.apbeta.local > sip.log
The resulting sip.log file can then be viewed using the familiar Snooper.exe tool but first, lets download and install the Microsoft Lync Server 2013 Debugging Tools from http://www.microsoft.com/en-us/download/details.aspx?id=35453. This will install snooper.exe and other tools in C:\Program Files\Microsoft Lync Server 2013\Debugging Tools. Run snooper and open the sip.log file created earlier to see the logs:
One of the coolest features about the new snooper is the ability to display the call flow diagram for a particular call. Simply select the invite message of the call and hit the Show Call Flow button. Being able to see the call in a diagram really helps to troubleshoot the problem much more easily Hovering the mouse over a message also displays additional details as shown in the diagram below:
If the log files don't contain the information you think it should contain from an issue you were trying to reproduce, you may need to flush the logs using the ClsController -flush cmdlet to make the latest logs available for searching immediately.
Lync2013 Client Log Files
The location of the Lync2013 client log files have changed and are now located at
%userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing.
%userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing.
Conclusion
The new CLS in Lync2013 provides a superior logging capability and user experience over its predecessor in Lync2010. For more details on how to use and manage the CLS, refer to this website http://technet.microsoft.com/en-us/library/jj688101.aspx. Happy logging!