Just the Shell commands for Skype Trouble Logging

I wanted to take a few minutes to just document a simple thing. Well the scope of the subject can become complex quickly. But this is not that. This is just a quick review of how to get the basic log output so you can troubleshoot a Skype issue.

I have a Video for this topic on Youtube.

So now matter how you approach logging, you will end up needing the Skype Debugging Tools.

The Debugging tool contains the Snooper log tool you will use to analyze the log. But It also contains the Skype GUI for also collecting the logs. So let me say your best method to collecting the Skype logs is to use the Gui in the Debugging tool kit. Here is a link for covering that topic: here

If the debugging tool kit is not working, you have another choice here that will act as a GUI for Log collection and analysis. Why not have a back up.


Command Line Logging

We are not going deep into Command line. If you want that please look here.

This is the emergency list of command if you just need to get logs now. below are the basic commands in order.

 

  • Show-CsClsLogging -Pools “pool.domain.com”
  • Start-CsClslogging -scenario  alwayson
  • Stop-Csclslogging -scenario “AlwaysOn”
  • Search-CsClsLogging -OutputFilePath “C:\Users\admin\mylogs\ouput.txt

 

This is the bare bones commands you can use in a pinch to get your basic logs.


Scenarios there are many you can run

So the one item missing from the commands above is a way to get the different scenarios you can choose. In order to get this information, just run the following:

  • Get-CsClsScenario | fT name

This command is important as you can target what your looking for more clearly by using the right scenario to log:

clsloggingscenario

So one thing to note is that the always on log will collect the sip stack trace, which is used in the lion share of Skype troubleshooting.

So now below I will include some examples of command you may find useful. this is not exhaustive, but this is the main things you may need for an average log collection

 

  1. Is logging running – Show-CsClsLogging -Pools “skypepool.domain.com
  2. Run Edge Log- Start-CsClsLogging -Pools pool.domain.com -Computers edge.domain.com -Scenario alwayson
  3. Complex search by time- 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”

 

To conclude, this is the crude basics you need to get those logs. if you want additonal information on hoe to make your own scenarios, that is very doable. see here for additional information if you are interested.

 

Thank you and happy logging.

 

Louis

 

 

 

 

Advertisements

How to Start, Stop and Search For failures or Issues in Skype For Business Server AKA CsClsLogging AKA Centralized Logging

tree

 

I have a video which complements this blog located at YouTube. Have a look if you need help-

Logging in Skype for Business has a lot of potential. However, it is made difficult by the need to use The command line. If you remember the Skype 2015 Resources tool kit, This kit contains CLSLogger And Snooper. This CLSLogger should be made part of the SFB product. It is a natural thing to do to help users gets the logs they need, without the size that command line logging can yield. If you Download CLS logger, I will show you in just a few steps, how to get the logs you need. Download the Performance toolkit from:

Microsoft.com CLSLOGGER

Once you have the tool in your hand, you simply run the default install, and the tool will be created in the path:

Start the application C:\Program Files\Skype for Business Server 2015\Debugging Tools\ClsLogger.exe

Before I even get started, I will tell you three times during this article, “Ignore the middle tab”. This is for advanced use. If you

Are just starting out, only pay attention to the first and third tab. Your going to run a trace and get a copy of the trace. That is

Our goal.

You are going to see three tabs, Ignore the Edit One

clip_image001

Begin at Tab1 Stop and Start Scenario

YOUR GOING TO RECEATE YOUR ISSUE DURRING THIS STEP. BEGIN REPRODUCING AS SOON AS THE START SENARIO BUTTON

IS PUSHED. MABYE 5 SECONDS AFTER-

 

  1. 1. Choose the Stop and stop scenario (1) See Figure 1 Below
  2. 2. Choose “Incoming and outgoing call” from the Drop Down. This choice will work for most issues because we just need the S4 and Sip Stack Flags (2)
  3. 3. Check the Front end server- or what ever sever you want logs from. you should collect FE servers and Edge logs separately (3)
  4. 4. Choose “start scenario”, when you are ready to recreate issue. In our case we are making a call to another user. (4)
  5. 5. Once the call is finished chose “stop scenario” (5)

 

Figure 1

  clip_image002  

Now Tab 3 the Search CLS LOGS

(Skip tab2 in the middle, it will only confuse things)

Use Figure 2 below to help with instructions

Go to search CLS logs tab. (ignoring the Edit Tab) and follow these steps

1. Log File Folder: Output is going to be where you want your output log to be placed

2. Log level- We usually want “All”

3. Start and stop Time is most important. we want to include the period where the issue occurred. So be early and log a little longer to make Sure you captured the issue

4. Like I said generally select Sip Stack and S4 for SIP calls or IM’s (Voip yes I said it)

5. Finally, You should only select what you captured, an if you captured only front end traffic. Capture Edge traffic in a separate trace

  1. That’s It! Your log should be on your Desktop, or wherever you specified!

 

Figure 2.  clip_image003

Now you should have your log. You can open the log with SNooper, which is in the same folder as CLSLogger. Good Luck and I hope this

was helpful.

Snooper tool is located in C:\Program Files\Skype for Business Server 2015\Debugging Tools\Snooper.exe. By Default.

 

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