If you've had to troubleshoot server side issues in an OCS\Lync environment then you are familiar with OCSLogger.exe tool. The OCSLogger tool is installed as part of the debugging tools which can be download from the Microsoft Download Center (link below). Although this is a great tool for collecting data it has one major downside "Lack of Centralization". So this means that when troubleshooting issues you would have to go to each OCS\Lync server, set your logging levels and flags, start logging, repro the issue, stop logging, and then analyze each log individually. This turned into a major project if you had a lot of servers that data was collected on. With the introduction of 2013, logging got a significant overhaul, now named Centralized Logging Service (CLS).
For this article I am going to focus on how to custom collections (called Scenarios) rather than the architecture of the centralized logging service (links below). The collections within CLS utilize Scenarios which are made up of providers. The providers are made up of components, logging level, and Flags which is similar to how OCSLogger collects data. By default, CLS has 29 built-in Scenarios (Figure 1) which can be used for some common troubleshooting situations that might occur. If you want to see what components each of these scenarios contain along with the levels and flags, run the following command:

·         Get-CsClsScenario <Scenario_Name> | Select –ExpandProperty Provider | FT Name,Level,Flags -Auto

Figure 1: Default CLS Scenarios

Although these default scenarios might work for common issues what if we need to customize the data we collect? To achieve this we need to create custom providers and group them into custom scenarios. In order to create providers we need to determine the components, flags, and level that we want to capture for that data. There are 257 different components we can capture data on which I have listed in the text file below. These were gathered from C:\Program Files\Common Files\Microsoft Lync Server 2013\Tracing\default.xml.
.
.
First we need to create our providers and put those into variables:
$a=New-CsClsProvider –Name "Component1" –Type WPP –Level Verbose –Flags All
$b=New-CsClsProvider –Name "Component2" –Type WPP –Level Verbose –Flags All
$c=New-CsClsProvider –Name "Component3" –Type WPP –Level Verbose –Flags All
 
Second we will add those 3 provider variables into a custom scenario named "NewScenario":
New-CsClsScenario -Identity "Global/NewScenario" -Provider @{add=$a,$b,$c} –verbose
 
Lastly we capture the data:
Start-CsClsLogging –Scenario "NewScenario"
Repro the Issue
Sync-CsClsLogging
Stop-CsClsLogging – Scenario "NewScenario"
Search-CsClsLogging –OutputFilePath c:\newscenario.log (data can be filtered if needed)
Open newscenario.log with Snooper (Snooper is also a part of the debugging tools)
 
There are a couple of things that are important when creating customs scenarios which could cause headaches if not done properly.

·         After creating a custom scenario you MUST restart the Lync shell before the start command will recognize the new scenario.

·         In OCSLogger most of the time we set the –Level to "All". With CLS in some scenarios setting the –Level to "All" will result in no data being captured. By setting this to "Verbose" you avoid this issue and still capture all the data.

·         In order to collect data on Edge servers you must have ports 50001, 50002, and 50003 open outbound from the machine you are running these commands on (CLS Controller) to the Edge servers.

 
Examples:
CMS Replication
$a=New-CsClsProvider –Name “XDS_File_Transfer_Agent” –Type WPP –Level Verbose –Flags All
$b=New-CsClsProvider –Name “XDS_Master_Replicator” –Type WPP –Level Verbose –Flags All
$c=New-CsClsProvider –Name “XDS_Replica Replicator” –Type WPP –Level Verbose –Flags All
New-CsClsScenario -Identity "Global/CMSReplAll" -Provider @{add=$a,$b,$c} –verbose
 
Persistent Chat
$a=New-CsClsProvider –Name "ChatCommon" –Type WPP –Level Verbose –Flags All
$b=New-CsClsProvider –Name "ChatEndpoint" –Type WPP –Level Verbose –Flags All
$c=New-CsClsProvider –Name "ChatServer" –Type WPP –Level Verbose –Flags All
$d=New-CsClsProvider –Name "ChatWebService" –Type WPP –Level Verbose –Flags All
New-CsClsScenario -Identity "Global/Chat" -Provider @{add=$a,$b,$c,$d} –verbose
 
I recently did a presentation for the Lync User Group (lyncug.com – created by Kevin Peters and Jeff Schertz) and they brought up some good points on why you might still use OCSLogger. CLS can only run one scenario (In addition to AlwaysOn), so if you need to run multiple scenarios at once you will need to utilize OCSLogger. If you need to use OCSLogger with Lync 2013 you should replace the default.tmx file so that you see all the components.
- Copy the “default.tmx” file from C:\Program Files\Common Files\Microsoft Lync Server 2013\Tracing to C:\Program Files\Microsoft Lync Server 2013 Debugging Tools and overwrite the existing file. It's always good to rename the old file before overwriting.
 
Hope this helps people avoid some of the issues I commonly run into with CLS.
Using the Centralized Logging Service - http://technet.microsoft.com/en-us/library/jj688101.aspx