Lync 2013 Centralized Logging

Monitoring in Lync 2013 has changed from Lync 2010. This article contains some basic concepts and syntax on how to collect logging under Lync Centralized Logging.

I admit, I still like OCSlogger. Please feel free to to download the Lync 2013 Resource Tool KitOCSLogger and Snooper are both included and can collect logging on a multitude of issues.  But what if your environment has many servers in one pool? what if the issue is spread across a large geographic deployment? If this is the case, you may find the Lync 2013 Centralized Logging Service a much better way to go about troubleshooting.

Before we begin, It is worth noting the other ways of monitoring, including the Plug-in for SCOM , Event Viewer errors, Performance counters, ClsController (command line) and Client logs.  This article will focus on  the Centralized logging  power shell commands .

The Monitoring setup is published in the Lync  topology builder. Once the Monitoring Shared Role is deployed to the Front End Pool, you may then use the SQL Reporting Service (of the watcher node) to gain incite into many failure scenarios. The Reports can be found on the home page of the Lync Control Panel after you have completed the install.

 

img5

 

Centralized logging should be administered from a Watcher Node.  This term is used to refer to an additional machine that has the Lync core files installed. This machine may also have the SCOM agent installed. finally, the Watchernode.msi is installed.

Set up Test Users

This document is meant to be brief so please make sure you have the Monitoring Server Deployed and set up.  Now the collection of failure information is strait forward.  Use CsWatcherNodeConfiguration to configure test users to be employed by the watcher node.

$x = New-CsExtendedTest -TestUsers “sip:kenmyer@litwareinc.com”, “sip:pilar@litwareinc.com” -Name “Audio Conferencing Test” -TestType “AudioConferencingProvider”
Set-CsWatcherNodeConfiguration -Identity “atl-cs-001.litwareinc.com” -ExtendedTests @{Add=$x}

Remove Extended test

$x = Get-CsWatcherNodeConfiguration -Identity “atl-cs-001.litwareinc.com”
$x.ExtendedTests.RemoveAt(0)
Set-CsWatcherNodeConfiguration -Instance $x

Remove Extended tests

Set-CsWatcherNodeConfiguration -Identity “atl-cs-001.litwareinc.com” -ExtendedTests $Null

Basic always On Log

The basic command for an anytime logging is :

  • Start-CsClsLogging -Scenario AlwaysOn

  • Search-CsClsLogging -OutputFilePath “C:\LogFiles\logfile.txt

  • Stop-CsClsLogging -Scenario AlwaysOn -Computers computera,computerb -Pools pool1.domain.com,pool2.domain.com

  • Sync-CsClsLogging – If doing multiple log runs, use this to clear the Server Cache

Alas, there are many caveats, so please see the following additional information. There are variables in catching a specific technical problem. The following provides incite in how to look at more advanced ways of controlling logging for troubleshooting purposes.

Scenarios and Provider

So lets start with some needed tools to keep nearby. Use OneNote, keep this link, or use a shell command to make sure know know how to get a list of Scenarios.  Get-CsClsScenario | fl identity will give you a list.  The Scenarios are shown below:   

Figure 1.

img3

To break down the scenario into its providers, just run the command in figure 2, on any of the scenarios listed in Figure 1. Below uses the “Incoming and outgoing call” as an example:

Figure 2.

$scenario=Get-CsClsScenario global/IncomingAndOutgoingCall

foreach ($sc in $scenario.provider) { $sc.name }

Get-CsClsScenario global/<ScenarioName> | Select -ExpandProperty Provider | Format-Table Name,Level,Flags -a

From TechNet, you may also run the command below to get the provider list in order of attributes. For example  Get-CsClsScenario -Identity “global/IncomingAndOutgoingCall” | Select-Object -ExpandProperty Provider

For a “raw” list of the providers you can look in  C:\Program Files\Common Files\Microsoft Lync Server 2013\Tracing\default.xml . You can make a yourscriptname.PS1 (figure 3)  file, by putting the following into a text file and save as .ps1: 

Figure 3.

[xml]$providers = Get-Content “$env:ProgramFiles\Common Files\Microsoft Lync Server 2013\Tracing\default.xml”

$providers.ComponentInfo.Components.Component

Then simple run the command inside powershell with the select-object pipe:

Figure 4.

.\yourscriptname.ps1 | Select-Object name  

You should see the old list similar to Lync 2010 OCS logger flags. We now can choose a scenario (figure 1), find out the associated  providers (figure 2). We also know where the provider XML file is located. We can parse the provider list with a short script (Figure 3 and 4). Knowing this information, you can do most of your troubleshooting without having to go custom. However, If you so desire to, you can  take control of what is being captured. Read on.   

What Comprises a Custom Scenario

Lets begin with what the custom Scenario looks like, make some definitions, and establish how we can define our own. the command to make your own custom Scenario are provided here:

  • $<variableName> = New-CsClsProvider -Name <provider component> -Type <log type> -Level <log level detail type> -Flags <provider trace log flags>

  • An example from TechNet- $LyssProvider = New-CsClsProvider -Name “Lyss” -Type “WPP” -Level “Info” -Flags “All”      

  •   New-CsClsScenario -Identity “global/MYlyss” -Provider $LyssProvider

The $variable name is created, as a container($LyssProvider), and assigned the values of an existing provider. See above the temp provider LyssProvider is being assigned the properties of LYSS (Lync Server Storage Services).  Use the definitions below to populate the rest of the $variablename assignment.  It is confusing because TechNet jj688082 does not define the Type variable properly. Under Type, they placed the -“level” log values. Compare to the list of possible “types” below. This is important to understand to populate your command parameters:  

Definitions

1. Scenario (Figure 1.) Is nothing more then a container of providers

  • Scope of Scenario – Global,Site,Pool

  • Provider -as discussed above

2. Providers (xml file, called components in 2010,  represent the data we want to collect, has attributes we can alter. provider variables break down into the following:

Pick a scenario from Figure 1 and run this command. this will show you the attributes of all providers in the Scenario. Example  Get-CsClsScenario -Identity “global/CAA” | Select-Object -ExpandProperty Provider. you will see these attributes

  • Name– The provider name (ex.) “s4”

  • Log Type “wpp” (eventlog, or iis logfile)

  • Logging Levels – All, Fatal, Error, Warning, Info, Verbose

  • Flags (TF_COMPONENT, TF_DIAG, TF_Security, TF_Protocol,All )

Now that you have your Customer Provider created, you simple create a new Scenario. The New-CsClsScenario refers to a scope, a name for the new scenario, and the name of the temp provider $variablename. The $variablename is the temporary provider.  That’s It! Its a long drop for a short walk. See the definitions below for help making the connections to the example above.  

Do we need custom Providers

Fortunately, the Centralized Logging Service provides a number of scenarios that are already defined for you. The provided scenarios cover the vast majority of possible issues that you will encounter. See Microsoft’s statement on the matter in TechNet:

Instead of requiring you to dig deeply into the details of providers, the Centralized Logging Service provides a number of scenarios that are already defined for you. The provided scenarios cover the vast majority of possible issues that you will encounter.”

That said, lets to stay with the (Figure 1) and just keep one or two default scenarios (Get-CsClsScenario | fl Identity).  See other good blog sites for default Scenario Information and tables.

Fitting the command to the issue

Now Armed with this new information. Lets revisit the general approach to collecting the logs for troubleshooting.

1. Determine which “scenario” fits the description of the problem.  Figure 1.

2. Turn on always on logging  Example : Start-CsClsLogging -Scenario “AlwaysOn”  (good to capture at least something)

3. Utilize command start, stop, search and flush -CsClslogging to collect and search for information.   The targets can be pools or FQDNs. See below:

  • Show-CsClsLogging to verify the logging is on.

  • Get-CsClsScenario to verify what logging is currently set

  • Other commands which may help viewing the initial settings (Get-CsClsLoggingConfiguration )

    • Get-CsClsConfiguration -LocalStore or

    • Get-CsClsConfiguration (nothing after will return CMS store info).

    • Use Set-CsClsLoggingConfiguration if you need to change something.

  • Get-CsClsLoggingConfiguration to verify the settings are correct. Adjust the setting to your needs. Approaches would be to set the default config or create your own config:

    • New-CsClsConfiguration -Identity “site:OklahomaCity” -CacheFileNetworkFolder “\\fs01.okc.net\filestore\logfiles” -EtlFileRolloverMinutes 120 -EtlFileRolloverSizeMB 40

    • Set-CsClsConfiguration -Identity “global” -CacheFileNetworkFolder “\\fs01.okc.net\filestore\logfiles” -EtlFileRolloverMinutes 120 -EtlFileRolloverSizeMB 40

    • Get-CsClsConfiguration | Set-CsClsConfiguration -EtlFileRolloverMinutes 120

  • Example of running the start command:

    • Start-CsCLSLogging -Scenario “desiredsenario”

  1. Search-CsClslogging (-components, -starttime, -endtime and/or -outputfilepath in any combination) if you use components you will want to refer to the Power Shell line above $scenario. If you search components, you may miss some of the anytime logging so It seems best to just output the log to a file.

  2. Stop-CsClslogging or remove-CSClsLoggingConfiguration to stop logging.

There are a few things I learned during the creation of this article, I thought I would pass along. I call them Gotcha’s, but really they are things to just think about as you are working out the basics. Some things do not come until you see someone else’s mistakes and errors. Here they are in a nutshell:

Gotcha’s

  1. The default log search only goes back 30 minutes. If you are collecting any time specific monitoring logs,  like anytime monitoring logs, you may not search the right time frame for the information period you need. Use something like the following

  2. Search-CsClsLogging -Pools “pool01.contoso.net” -StartTime “11/20/2012 08:00:00 AM” -EndTime “11/20/2012 09:00:00 AM” -OutputFilePath “C:\Logfiles\logfile.txt”

  3. The resulting log files from running the Start-CsClsLogging  command, run in the Network Service Account Temp folder. So it may be common to look for the files in the User Context and not be able to get the logs.  Default logs are under the Network Service in the following folder: %TEMP%\Tracing -> C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing

  4. To Avoid #2 Use a command like Search-CsClsLogging –OutputFilePath “c:\Logfiles\SearchResult.txt”. Notice the log location is not set on the Start-CsClsLogging.  It is set on the search, This seems counter-intuitive and could be confusing.

  5. The bottom line is Keep a list of scenarios and output the log file to a known folder location.  Another way to set the results folder is available on TechNet. An example of moving the output folder appears here- New-CsClsConfiguration -Identity “site:OklahomaCity” -CacheFileNetworkFolder “\\fs1.okc.net\filestore\logfiles” -EtlFileRolloverMinutes 120 -EtlFileRolloverSizeMB 40

  6. If you are collecting logging from the Edge Server, Ports 50,001,50,002,50,003 need to be open for TCP over the internal NIC.

  7. Two logs are allowed to be running at one time. The AllwaysOn log and one other “scenario”.  The steps at the bottom how to make gotcha free log collection possible.

  8. CClsController is also another way to collect logging. Power shell command for start, stop, search and flush-CsCLsLogging are easier to use.  Lync Centralized logging uses a CLSController Service to communicate to an agent on each Lync Server. The CLS agents all send the logs to the CLScontroller.

  9. You don’t have to have a watcher node. You can run the command from any pool server.

  10. If you dont have permissions to something due to RBAC, check your permissions with the command Get-CsAdminRole | Where-Object {$_.Cmdlets -match “Lync Server 2013 cmdlet”} example Get-CsAdminRole | Where-Object {$_.Cmdlets -match “Set-CsClsConfiguration”}

Now after spending a tone of time on this article, I have found a person who has created a Graphical tool for log collection. IT looks very promising. Please see the post Lync 2013 Centralized logging Tool. There is a download there for the logging tool and a Database mirror manager. Both are very good ideas!

Good luck and Lync on. 🙂

Louis

Advertisements

One thought on “Lync 2013 Centralized Logging

  1. Andrew says:

    It represents the water element, and is used to enhance wealth and career luck.
    According to the location of the mobile crusher station and shift based study will be divided into self-shift and
    shift two. The ability to let go of old emotions is based in this Chakra.

    This has nothing to do with my blog but is so poetic, I just had to let it go! 🙂 Thank you to the writer-

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s