Sunday, 7 April 2013

Lync 2013 Centralised Logging Deep Dive

Overview


Lync 2013 brings with it a new form of logging that differs greatly from the logging tools previously supplied in Lync 2010. In Lync 2010 the Lync Logging Tool offered the ability to log directly on a single server in a pool. As a result, in Lync 2010 logging across a pool of ten servers requires running the logging tool on multiple servers at once, which can be a cumbersome undertaking.   

Lync 2013 has new capability called the Centralised Logging Service. The new logging service consists of two main components, a Logging Controller, and a Logging Agent. The Logging Agent runs on each of the Lync Front End servers, under the service name “Lync Server Centralised Logging Service Agent”.




The service runs the ClsAgent.exe executable and listens for commands on the following ports: TCP 50001TCP 50002, and TCP 50003. This can be seen using netstat:



When the agent receives a command, it sends messages to the defined components for tracing, and writes the trace logs to disk. It also reads the trace logs for its computer and sends the trace data back to the controller when requested.

The Second component used for centralised logging is the Centralised Logging Controller. The Centralised Logging Controller sends Start, Stop, Flush, and Search commands to the ClsAgents on all the servers in a specified pool. The Lync 2013 Preview release contained a command line tool called ‘ClsController.exe’ (which still exists in the RTM release) that could be used to control the Centralised Logging Agents on the Lync Front End servers. The release of Lync 2013 RTM has taken this a step forward offering Powershell commands that send commands through a Dynamic Link Library called “ClsControllerLib.dll”.

When search commands are sent, the resulting logs are returned to the ClsControllerLib.dll and aggregated. The controller is responsible for sending commands to the agent, receiving the status of those commands and managing the search log file data as it is returned from the agents, and aggregating the log data into a meaningful and ordered output set.

Here is a diagram of the relationship between the two Controller and Agents:


The documentation now available on TechNet states that two scenarios can be run on a given computer at any one point in time. What this actually means in practice is that you can run one default or custom scenario, in addition to AlwaysOn logging. Even if you have AlwaysOn logging turned off, you can’t run multiple other scenarios at once. If you are in a situation where you need to run multiple default scenarios at once, then you can create your own custom scenario that includes all of the logging providers used by the default scenarios you are trying to emulate (see the Custom Scenarios section of this post).

 

How Does Centralised Logging compare to Lync 2010 Logging Tool?

So, what are all these weird scenario names and how do they relate to my favourite Lync Logging Tool filters (SIPStack, S4, etc)? I’m glad you asked, and I made this table to help you understand what the new Scenarios are doing in the background. The following table shows the default scenario names used for centralised logging, and the components that are logged for each of these scenarios.
Lync 2010 Logging Tool
The third column in this table relates to the Components from the old Lync Logging Tool (which is incidentally still available for download for Lync 2013 in the Debugging tools install). The components list can be seen on the left hand side of the tool.

Logging Comparison Table


The table explains which components get used for each default logging scenario in Lync 2013 centralised logging.

Description
Centralised Logging Tool Scenario
Lync 2010 Logging Tool Components
AlwaysOn is a special scenario that can be enabled to log all the time. The AlwaysOn scenatio can run in conjunction with one other scenario.


AlwaysOn
AsMcu
AcpMcu
AVMCU
AVMP
BICommon
BICOSMOS
BIDATACOLLECTOR
CAAServer
Collaboration
DataMCU
DataMcuRuntime
ExumRouting
IMMCU
InboundRouting
InterClusterRouting
McuInfra
MediationServer
OutboundRouting
Routing_Data_Sync_Agent
S4
ServerTransportAdaptor
Sipstack
LDM
AppShareOoty
RDPApiTrace
RDPEncComTrace
RdpApiTrace
UserServices
UDCAgent
PNCHService
TenantAdminUI
HostedMigration
Powershell
UCWA
ChatCommon
ChatEndpoint
ChatServer
ChatCompliance
ChatWebService
XmppTGW
XmppCommonLibrary
XmppListener
XmppRouting
XmppTGWProxy
Lyss
StoreWeb
TranslationApplication
RgsClientsLib
RgsCommonLibrary
RgsDatastores
RgsDiagnostics
RgsHostingFramework
RgsMatchMakingService
CpsDiagnostics
CpsHostingFramework
JoinLauncher
WebInfrastructure
Infrastructure
InternalCommon
McxService
UserPinService
CertProvisioning
BackupService
RtcDbSyncAgent
WebRelay
ServerAgent
Media related logging
MediaConnectivity
MediaStack_AUDIO_AGC
MediaStack_AUDIO_DRC
MediaStack_AUDIO_ECHODT
MediaStack_AUDIO_FAXDT
MediaStack_AUDIO_HEALER
MediaStack_AUDIO_NOISEDT
MediaStack_AUDIO_VAD
MediaStack_AUDIO_VSP
MediaStack_AudioCodecs
MediaStack_AudioEngine
MediaStack_COMAPI
MediaStack_COMMON
MediaStack_Crossbar
MediaStack_Crypto
MediaStack_DebugUI
MediaStack_DebugUI_AEC
MediaStack_DEVICE
MediaStack_MassConvertedTraces1
MediaStack_MediaManager
MediaStack_PerFrame
MediaStack_PerPacket
MediaStack_QualityController
MediaStack_RTCP
MediaStack_RTP
MediaStack_StreamingEngine
MediaStack_TLS
MediaStack_Transport
MediaStack_VIDEO
MediaStack_VOICEENHANCE
Application Sharing
ApplicationSharing
AsMcu
AppShareOoty
ServerTransportAdaptor
RDPApiTrace
RDPEncComTrace
MCUInfra
Collaboration
S4
Audio and Video Conferencing Logging
AudioVideoConferencingIssue
AvMcu
AvMP
MCUInfra
Collaboration
S4
Hybrid Cloud voice deployments
HybridVoice
MediationServer
S4
Sipstack
OutboundRouting
TranslationApplication
General Call logging
IncomingAndOutgoingCall
MediationServer
S4
Sipstack
TranslationApplication
OutboundRouting
InboundRouting
UserServices
Voice Mail
VoiceMail
Sipstack
ExumRouting
InboundRouting
IM and Presence Logging
IMAndPresence
Sipstack
UserServices
Address Book service logging
AddressBook
ABCommon
ABServer
ABServerIISModule
Dlx
Device Update service logging
DeviceUpdate
DeviceUpdate
DeviceUpdateHttpHandler
Lync Storage Service and Unified Contact Store logging
LYSSAndUCS
UserServices
Lyss
McuInfra
Centralised Logging Service logging
CLS
CLSAgent
CLSCommon
CLSController
CLSControllerLib
Support Portal logging
SP
SupportPortal
SPHelper
SPModule
SPSearchTool
SPCLSTool
CLSCommon
CLSControllerLib
Web Access Server logging
WAC
DataMCURunTime
DataMCU
LDM
Infrastructure
WebInfrastructure
InternalCommon
User Replicator Service (synchronization between AD DS and Lync Server)
UserReplicator
UserServices
Lync Online Migration
HostedMigration
HostedMigration
Powershell
WebInfrastructure
Monitoring and Archiving logging
MonitoringAndArchiving
UDCAgent
LILRLegacy
LILRLegacy
LogRetention
LegalIntercept
LILRLYSS
LILRLYSS
LogRetention
UDCAgent
Meeting logging
MeetingJoin
Collaboration
S4
UserServices
McuInfra
JoinLauncher
WebInfrastructure
Infrastructure
InternalCommon
UCWA
WebRelay
Response Group Service
RGS
RgsClientsLib
RgsCommonLibrary
RgsDatastores
RgsDeploymentApi
RgsDeploymentLibrary
RgsDiagnostics
RgsHostingFramework
RgsMatchMakingService
UserServices
Collaboration
S4
Sipstack
Call Park Service 
CPS
CpsDiagnostics
CpsHostingFramework
UserServices
Collaboration
S4
Sipstack
XMPP service logging
XMPP
XmppTGW
XmppCommonLibrary
XmppListener
XmppRouting
XmppTGWProxy
Collaboration
S4
Sipstack
Conference Auto Attendant 
CAA
CAAServer
Collaboration
S4
Sipstack
UserServices
Dial in conferencing MCU
ACPMCU
AcpMcu
Collaboration
S4
SipStack
Authentication Logging
Authentication
SipStack
UserServices
WebInfrastructure
UserPinService
CertProvisioning
High Availability
Disaster Recovery
HADR
UserServices
PowerShell
BackupService
RtcDbSyncAgent
Powershell
Powershell
Powershell
FilterApps
FilterApps
IIMFilter
ClientVersionFilter
ServerAgent
SipStack


What is AlwaysOn Logging?


AlwaysOn is a setting that can be made on a pool that forces the pool to be logging all the time. When you run a Show-CsClsLogging on your server you can see that AlwaysOn gets its own separate status shown in the output:

> Show-CsClsLogging
Success Code - 0, Successful on 1 agents

Tracing Status:

2013STDFE001.mylynclab.com (2013STDFE001 v5.0.8308.0) (AlwaysOn=No,Scenario=HostedMigration,Started=
4/6/2013 11:25:47 PM,By=2013STDPC\Administrator,Duration=0.04:00)
    2013STDFE001.mylynclab.com (2013STDFE001 v5.0.8308.0) (Same as pool)

This is because AlwaysOn functions as an everyday log that can be used to troubleshoot issues that might have happened during the day. The AlwaysOn logging scenario logs for all of the components available, at an Info level, as shown below:


> Get-CsClsScenario | Where-Object {$_.identity -like "Global/AlwaysOn"} | Select-Object provider | Select-Object -ExpandProperty provider

Name  : AsMcu
Type  : WPP
Level : Info
Flags : TF_COMPONENT,TF_PROTOCOL

Name  : AcpMcu
Type  : WPP
Level : Info
Flags : TF_COMPONENT

Name  : AVMCU
Type  : WPP
Level : Info
Flags : TF_COMPONENT,TF_PROTOCOL

Continued...

So, if you are running AlwaysOn already on a pool, then the only reason you would need to run another scenario at the same time would be to log at a higher level of detail (eg. Debug). Note, only one additional scenario can be logging at the same time as AlwaysOn is running.

If you run a Search-CsClsLogging (with no filters) on a scenario, at the same time as AlwaysOn was logging, you will receive the AlwaysOn logging in the output file as well. As a result, if you need to do very specific logging, you might want to turn off the AlwaysOn logging before you start the specific scenario you want to log for (or remember to use an appropriate filter when running Search-CsClsLogging to remove the unnecessary logs).

Logging Files

Temporary log files are written to the folder on each of the Lync servers with logging enabled. All log files will be placed in the folder specified in the Get-CsClsConfiguration command, as shown below:

> Get-CsClsConfiguration


Identity                      : Global
Scenarios                     : {Name=AlwaysOn, Name=MediaConnectivity, Name=ApplicationSharing, Name=AudioVideoConferencingIssue...}
SearchTerms                   : {Type=Phone;Inserts=ItemE164,ItemURI,ItemSIP,ItemPII, Type=URI;Inserts=ItemURI,ItemSIP,ItemPII, Type=CallId;Inserts=ItemCALLID,ItemURI,ItemSIP,ItemPII,
                                Type=ConfId;Inserts=ItemCONFID,ItemURI,ItemSIP,ItemPII...}
SecurityGroups                : {}
Regions                       : {}
EtlFileFolder                 : %TEMP%\Tracing
EtlFileRolloverSizeMB         : 20
EtlFileRolloverMinutes        : 60
TmfFileSearchPath             :
CacheFileLocalFolders         : %TEMP%\Tracing
CacheFileNetworkFolder        :
CacheFileLocalRetentionPeriod : 14
CacheFileLocalMaxDiskUsage    : 80
ComponentThrottleLimit        : 5000
ComponentThrottleSample       : 3
MinimumClsAgentServiceVersion : 6


Note: If you cut and paste this address into the file browser you will end up in a location like this:

C:\Users\Administrator.DOMAIN\AppData\Local\Temp\2\Tracing

Most likely this location is void of any logging files, which might leave you scratching you head. However, there is good reason for this: you’re logged in as a user on the server and as a result you’re getting taken to the temp folder of the user you’re logged in as.

Meanwhile, the Logging Service is logged in as the NetworkService (as are all Lync services), so when it accesses this address it ends up at the following folder:

C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing




The logs folder will have three different types of files in it: ETL, HDR and CACHE files. Currently running logging services are streaming to ETL files (eg. CLS_WPP_04-05-2013-13-34-46_1.etl). When the logging is stopped the ETL file content gets converted into an HDR and a CACHE file.

The HDR file contains information about the capture, eg:

AgentVersion=2.0
Starttime=5/04/2013 2:27:11 AM
Endtime=5/04/2013 2:30:26 AM
MostSevereLevel=3
ComponentNames=(Shared),SIPStack,UserServices
CorrelationIds=0,2446939738,2446939785,2899899976,2970877857,1910046407,2765731706,1926842570,947404259,3734898740,3285769719,2895070652,2630969344,1910046457,3397217402,3308872234,2765731776,1484520309,1137574355

The CACHE file is an actual logging file that contains the information that was logged. Sections of this file are in binary, and sections in clear text. The CACHE file cannot be directly opened in Snooper. In order to do this you must run the Search-CsClsLogging command to retrieve the correct format.

 Other Useful Centralised Logging Settings


There are a number of other useful settings within Get-CsClsConfiguration that might be of use to you when it comes to finely tuning your logging solution. Here are some settings that you might consider tweaking:

EtlFileRolloverSizeMB         : 20
EtlFileRolloverMinutes        : 60
TmfFileSearchPath             :
CacheFileLocalFolders         : %TEMP%\Tracing
CacheFileNetworkFolder        :
CacheFileLocalRetentionPeriod : 14
CacheFileLocalMaxDiskUsage    : 80
ComponentThrottleLimit        : 5000
ComponentThrottleSample       : 3

EtlFileRolloverSizeMB: Maximum size (in megabytes) that at event trace log file can reach before a new file is created. The default value is 20.

EtlFileRolloverMinutes: Maximum amount of time (in minutes) that can elapse before a new event log trace file is created. (This new file will be created even if the existing trace file has not reached the specified rollover size.) The default value is 60.

CacheFileLocalRetentionPeriod: Maximum number of days that cache files are retained locally. The default value is 14.

CacheFileLocalMaxDiskUsage: Maximum amount of disk space (percentage) that can be used for the cache files. The default value is 80.

Creating Custom Logging Scenarios


Let me first start by explaining in a little more depth what a scenario actually is. A scenario is basically a collection of one, or many, logging streams (in Microsoft speak; ‘components’). For example, if we were to take AddressBook scenario, which logs things to do with the Address Book Service. From the table earlier we can see that the components being logged for the AddressBook scenario include ABCommon, ABServer, ABServerIISModule, and Dlx. As might be obvious by their names, these services are all directly relating to the Address Book, whereas components like MediaStack_MediaManager have nothing to do with the AddressBook so we don’t include them in the scenario.
Put in a different way, a Scenario functions as a Pre-Capture filter that determines what is written to disk on the server running the Centralised Logging Agent Service. After this information has been logged to disk on the Agent server, the search-cslcslogging command can be used in conjunction with additional (Post-Capture) filter parameters to determine the logging output that is written to the final log file. Below is a diagram that describes the process:
 
Creating a custom Centralised Logging Scenario is quite simple: it’s a matter of first creating provider(s) and then creating a scenario from the providers:
Create a provider:
$provider = New-CsClsProvider -Name "AvMcu" -Type "WPP" -Level "Info" -Flags "All"


The New-CsClsProvider page on TechNet currently (April 2013) states that the provider Name parameter is a “Unique Name”. After reading this and looking at the command, I was left a little confused, because there are no other parameters that tell the provider what components it should be logging for. So, whilst the New-CsClsProvider command will let you create a provider with a Name of “MegaLoggingSuperLogLogger”, this isn’t a component name that means anything to the logging service. If you use this provider (with a unique name) and try and run it on an Agent it will Start successfully:

> Start-CsClsLogging -Scenario CUSTOMSCENARIO -pools 2013ENTFE004.mylynclab.com
Success Code - 0, Successful on 1 agents
Tracing Status:
2013ENTFE004.mylynclab.com (2013ENTFE004 v5.0.8308.0) (AlwaysOn=No,Scenario=CUSTOMSCENARIO,Started=4/04/2013 5:43:07 PM,By=2013ENT\Administrator,Duration=0.04:00)
2013ENTFE004.mylynclab.com (2013ENTFE004 v5.0.8308.0) (Same as pool)

It will say it’s logging when you run the Show command:
> Show-CsClsLogging
Success Code - 0, Successful on 6 agents
Tracing Status:
2013ENTFE004.mylynclab.com (2013ENTFE004 v5.0.8308.0) (AlwaysOn=No,Scenario=CUSTOMSCENARIO,Started=4/04/2013 5:43:07 PM,By=2013ENT\Administrator,Duration=0.04:00)
...

However, it will fail when you stop correctly run the Stop command:
> Stop-CsClsLogging -scenario CUSTOMSCENARIO -pools 2013ENTFE004.mylynclab.com
Failed on 1 agents
Agent - 2013ENTFE004.mylynclab.com, Reason - Error code - 20005, Message - Scenario 'CUSTOMSCENARIO' not currently running.

So choosing a “Unique Name” doesn’t actually appear to be the way to go… The Name parameter should actually be the name of a component. Here is a list of Component names to choose from:

Component Names
ABCommon
InternalCommon
PNCHService
ABServer
JoinLauncher
Powershell
ABServerIISModule
LDM
RdpApiTrace
AcpMcu
LegalIntercept
RDPEncComTrace
AppShareOoty
LogRetention
RgsClientsLib
AsMcu
Lyss
RgsCommonLibrary
AvMcu
McuInfra
RgsDatastores
AVMP
McxService
RgsDeploymentApi
BackupService
MediaStack_AudioCodecs
RgsDeploymentLibrary
BICommon
MediaStack_AudioEngine
RgsDiagnostics
BICOSMOS
MediaStack_AUDIO_AGC
RgsHostingFramework
BIDATACOLLECTOR
MediaStack_AUDIO_DRC
RgsMatchMakingService
CAAServer
MediaStack_AUDIO_ECHODT
Routing_Data_Sync_Agent
CertProvisioning
MediaStack_AUDIO_FAXDT
RtcDbSyncAgent
ChatCommon
MediaStack_AUDIO_HEALER
S4
ChatCompliance
MediaStack_AUDIO_NOISEDT
ServerAgent
ChatEndpoint
MediaStack_AUDIO_VAD
ServerTransportAdaptor
ChatServer
MediaStack_AUDIO_VSP
Sipstack
ChatWebService
MediaStack_COMAPI
SPCLSTool
ClientVersionFilter
MediaStack_COMMON
SPHelper
CLSAgent
MediaStack_Crossbar
SPModule
CLSCommon
MediaStack_Crypto
SPSearchTool
CLSController
MediaStack_DebugUI
StoreWeb
CLSControllerLib
MediaStack_DebugUI_AEC
SupportPortal
Collaboration
MediaStack_DEVICE
TenantAdminUI
CpsDiagnostics
MediaStack_MassConvertedTraces1
TranslationApplication
CpsHostingFramework
MediaStack_MediaManager
UCWA
DataMCU
MediaStack_PerFrame
UDCAgent
DataMCURunTime
MediaStack_PerPacket
UserPinService
DeviceUpdate
MediaStack_QualityController
UserServices
DeviceUpdateHttpHandler
MediaStack_RTCP
WebInfrastructure
Dlx
MediaStack_RTP
WebRelay
ExumRouting
MediaStack_StreamingEngine
XmppCommonLibrary
HostedMigration
MediaStack_TLS
XmppListener
IIMFilter
MediaStack_Transport
XmppRouting
IMMCU
MediaStack_VIDEO
XmppTGW
InboundRouting
MediaStack_VOICEENHANCE
XmppTGWProxy
Infrastructure
MediationServer

InterClusterRouting
OutboundRouting



Now that you’ve created a provider and written it to a variable ($provider), it now needs to be attached to a Scenario. You do this by running New-CsClsScenario and passing it the provider as a parameter.

Attaching the provider to a new custom global scenario:

New-CsClsScenario -Identity "global/CUSTOMSCENARIO" -Provider $provider

If you would like to have a scenario with multiple providers (components) logging at once, then you can do so by passing the New-CsClsLogging command a plist with multiple providers in it.
Scenarios can be created with multiple providers, here’s how:
$LyssProvider = New-CsClsProvider -Name "Lyss" -Type "WPP" -Level "Info" -Flags "All"
$ABServerProvider = New-CsClsProvider -Name "ABSever" -Type "WPP" -Level "Info" -Flags "All"
$SIPStackProvider = New-CsClsProvider -Name "SIPStack" -Type "WPP" -Level "Info" -Flags "All"
New-CsClsScenario -Identity "global/MULTICUSTOMSCENARIO" -Provider @{Add=$LyssProvider, $ABServerProvider,  $SIPStackProvider}

What about if you want to only allow administrators at a specific site to use the logging scenario? Then you can create the scenario with a site scope.

You can attach the provider to a new site specific custom scenario:

New-CsClsScenario -Identity "site:Melbourne Site/SITECUSTOMSCENARIO" -Provider $provider
Note: After creating a Custom Site based scenario (as shown above), and you try and start any of the Default Global scenarios, you will get an error like the one below telling you that the scenario is “Unknown”:
Start-CsClsLogging : Cannot validate argument on parameter 'Scenario'. Unknown scenario name 'VoiceMail'
At C:\Users\Administrator.2013ENT\Desktop\myCentralisedLoggingUI.ps1:43 char:50
+         [string]$clscmd = Start-CsClsLogging -Scenario $scenariotype -pools $pooltotra ...
+                                                        ~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Start-CsClsLogging], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.Rtc.Management.Cls.StartOcsLoggingCmdlet
But hang on a minute, of course the “VoiceMail” scenario is a valid scenario! In fact, it’s one of the default scenarios… So what is going on here?
Well, the reason for this is that when you create a Site based Custom scenario, in the background, Lync will also create a new site based Configuration Identity (eg. In the background it runs New-Cs-ClsConfiguration), for example, if you run a Get-CsClsConfiguration you will see:
Identity                      : Global
Scenarios                     : {Name=AlwaysOn, Name=MediaConnectivity, Name=ApplicationSharing, Name=AudioVideoConferencingIssue...}
SearchTerms                   : {Type=Phone;Inserts=ItemE164,ItemURI,ItemSIP,ItemPII, Type=URI;Inserts=ItemURI,ItemSIP,ItemPII, Type=CallId;Inserts=ItemCALLID,ItemURI,ItemSIP,ItemPII,
                                Type=ConfId;Inserts=ItemCONFID,ItemURI,ItemSIP,ItemPII...}
SecurityGroups                : {}
Regions                       : {}
EtlFileFolder                 : %TEMP%\Tracing
EtlFileRolloverSizeMB         : 20
EtlFileRolloverMinutes        : 60
TmfFileSearchPath             :
CacheFileLocalFolders         : %TEMP%\Tracing
CacheFileNetworkFolder        :
CacheFileLocalRetentionPeriod : 14
CacheFileLocalMaxDiskUsage    : 80
ComponentThrottleLimit        : 5000
ComponentThrottleSample       : 3
MinimumClsAgentServiceVersion : 6

Identity                      : Site:Melbourne Site
Scenarios                     : {Name=SITECUSTOMSCENARIO}
SearchTerms                   : {Type=Phone;Inserts=ItemE164,ItemURI,ItemSIP,ItemPII, Type=URI;Inserts=ItemURI,ItemSIP,ItemPII, Type=CallId;Inserts=ItemCALLID,ItemURI,ItemSIP,ItemPII,
                                Type=ConfId;Inserts=ItemCONFID,ItemURI,ItemSIP,ItemPII...}
SecurityGroups                : {}
Regions                       : {}
EtlFileFolder                 : %TEMP%\Tracing
EtlFileRolloverSizeMB         : 20
EtlFileRolloverMinutes        : 60
TmfFileSearchPath             :
CacheFileLocalFolders         : %TEMP%\Tracing
CacheFileNetworkFolder        :
CacheFileLocalRetentionPeriod : 14
CacheFileLocalMaxDiskUsage    : 80
ComponentThrottleLimit        : 5000
ComponentThrottleSample       : 3
MinimumClsAgentServiceVersion : 6
See the new Site Identity (Site:Melbourne Site) that has appeared out of nowhere... It’s now taking precedence over the top of the Global policy for that pool. Also, notice that the only scenario that is under this Site is the SITECUSTOMSCENARIO, and as a result, this is the only scenario that can now be run from this site.
At this point, you may think that removing the scenario with a “Remove-CsClsScenario”, may fix this, however, this is not the case. To revert back using the Global configuration you need to remove the site configuration with the following command:
Remove-CsClsConfiguration –Identity “Site:Melbourne Site”
Now, you may need to restart the Lync Server Centralised Logging Service Agent in Windows Services so that the configuration is updated. 
The moral of this story is to only use Global policies for Centralised Logging, unless you have a very good reason not to!

Wrap up

This Deep Dive into the Centralised Logging Service has clarified how the service works, and how you can use it to get the information you need out of the system. Hopefully, this will leave you in a position to start debugging using it instead of leaning on the old Lync Logging Tool. As far as Custom Scenarios go, I would suggest you think about the type of information you may be needing out the system to fix common problems and tailoring some custom scenarios ahead of time, because you don’t really want to be messing around when the faults start rolling in. Keep logging, and bye for now.
PS: But what if you don’t like Powershell? Well, have no fear, as my next post will include a new Centralised Logging Tool GUI for your logging pleasure. 

4 comments:

  1. Very nice article, thanks alot

    ReplyDelete
  2. Excellent summary, just what i was looking for.

    ReplyDelete
  3. Thank you so much. Nice detailed explanation!

    ReplyDelete

Popular Posts