Using Centralized Logging Service in Lync Server 2013 Preview

(1 Aug 2012: Updated with information about the AlwaysOn scenario provided by Natasha the PM for CLS)

Centralized Logging Service (CLS) is a new feature in Lync Server 2013 Preview. It provides a mechanism to enable/disable logging across all Lync servers in a deployment from a single interface and to search the resulting logs from the same interface.

You specify what should be logged based on the scenario you want to investigate. The scenarios supported are AlwaysOn, MediaConnectivity, ApplicationSharing, AudioVideoConferencingIssue, HybridVoice, IncomingAndOutgoingCall, VoiceMail, IMAndPresence, AddressBook, DeviceUpdate, LYSSAndUCS, CLS, SP, WAC, UserReplicator, HostedMigration, MonitoringAndArchiving, LILRLegacy, LILRLYSS, MeetingJoin, RGS, CPS, XMPP and CAA.

The AlwaysOn scenario is special. CLS is designed to have that scenario running by default. This way, when you have an issue you do not have to turn on logging, repro the issues and then get your logs. The hope is that there is enough logging occurring with AlwaysOn that when you have an issue you will already have the logs available. If AlwaysOn does not provide you with enough logs, then you can turn on a particular scenario to get a more verbose set of logs.

CLS is implemented by agents and a controller used by the Lync administrator to interact with CLS.

The Lync Server Centralized Logging Service Agent service (also known as ClsAgent) is running on all Lync 2013 Preview servers in the deployment. The purpose of the agent is to respond to requests to enable/disable logging and to respond to search requests.

The Lync administrator controls the agents via the ClsController interface. ClsController is a program default installed into C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent. You can specify different parameters to ClsController. You can see detailed usage information about parameters and their values by just running ClsController without parameters.

The typical sequence of commands you want to run are:

  • ClsController.exe -start –scenario <scenario> –pools <pool fqdn>
  • Repro issue
  • ClsController.exe -stop –scenario <scenario> –pools <pool fqdn>
  • ClsController.exe -flush –pools <pool fqdn>
  • ClsController.exe -search –pools <pool fqdn> –components <component> –loglevel <loglevel>

For example to investigate an issue with UCS for a user on the lync.contoso.com pool:

  • ClsController.exe -start –scenario lyssanducs –pools lync.contoso.com
  • Repro issue
  • ClsController.exe -stop –scenario lyssanducs –pools lync.contoso.com
  • ClsController.exe -flush –pools lync.contoso.com
  • ClsController.exe -search –pools lync.contoso.com –components lyss –loglevel verbose

The last invocation of ClsController will write the resulting log entries to standard output, so you might want to re-direct it to a file by using >.

You can get an understanding of which components are included in which CLS scenarios by the Lync Management Shell command Get-CsClsScenario. Below I’m showing how to find the components or providers in the CPS scenario:

  • PS C:\> $scenario=Get-CsClsScenario global/cps
  • PS C:\> foreach ($sc in $scenario.provider) { $sc.name }
    CpsDiagnostics
    CpsHostingFramework
    CpsOrbit
    Collaboration
    S4
    Sipstack