Note: Updated 28 August 2015 to reflect changes in newer version.
I’m surprised no one has written about this yet. If someone has, please let me know and I’ll give you props and a link right up top. Until then….
The Skype for Business debugging tools are a replacement for the Lync Server Debugging tools. First off, the Lync debugging tools will work on a Skype for Business server. However the new debugging tools leverage the Centralized Logging Service (CLS) feature introduced in Lync 2013. This makes it far easier to do logging across multiple servers at the same time. The Lync debugging tools have to be run independently on each server.
The primary change is that the OCSLogger.exe from Lync 2013 has been replaced with the CLSLogger.exe program. Snooper remains the same though it is a newer version. There has been the addition of a “Codepoint” menu which ….I’m guessing….is used to load external diagnostics…or something. But it’s new, and newer is always better.
Also, CLSLogger can be used against Lync 2013 servers as well as Skype for Business. No dice on Lync 2010 though.
There is nothing that the CLSLogger can do that you can’t do via PowerShell. If you are a CLS ninja, then you can probably skip the CLSLogger altogether and just go on about your business.
But for the rest of us…..
Before you even fire up the tool, run Get-CsClsConfiguration . This will let you know how you are set up. For the most part, ignore everything returned except for the “ETLFileFolder” and “CacheFileLocalFolders” values. By default this is set to %TEMP%\Tracing. And where exactly is that directory?
Or most likely, here:
These directories are important because this is where the log files are going to be created. You may want to edit this to get them off of your C: drive so you don’t accidentally fill it up.
And since I never like editing the Global configuration of anything (if it can be avoided), create a new CLS Configuration for your Skype for Business Site(s). This is done with the New-CsClsConfiguration cmdlet. Below is an example creating a new configuration for a Site named “Site 2” and changing the logging folders to e:\logging:
New-CsClsConfiguration -Identity "site:Site 2" -ETLFileFolder "d:\logging" -CacheFileLocalFolders "d:\logging"
Even if you only have a C: drive, you may want to change the directories to something you can find more easily than %WINDIR%\ServiceProfiles\NetworkService\AppData\Local
CLS will automatically create the directory you define, so that saves time connecting to every server in your site to create a directory.
So, now that the directories have been defined, it’s time to launch CLSLogger, right? Yeah well not quite.
CLSLogger is really a super elaborate PowerShell wrapper. And if there’s one thing you’ve learned about running PowerShell scripts it should be this: You need to set the Execution Policy before you can run somebody else’s script, even Microsoft scripts.
So open a PowerShell window with “Run as Administrator” and type the following to permit this to run:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted
If you are super security conscious, you may want to use something other than Unrestricted. But that’s up to you to figure out the magic voodoo. I always use Unrestricted but then I don’t entirely know what I am doing with this. I just set it to Unrestricted because it tells PowerShell to never bother me again with this security nonsense.
So now, assuming you have installed the Debugging Tools already, you can finally go ahead and launch CLSLogger. Navigate to C:\Program Files\Skype for Business Server 2015\Debugging Tools and launch ClsLogger.exe
Now, even with the execution policy in PowerShell set correctly, you still get:
Error: Access to the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’ is denied. To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the “Run as administrator” option. To change the execution policy for the current user, run “Set-ExecutionPolicy -Scope CurrentUser”.
Oh wait…Run ClsLogger as Administrator too. Otherwise it won’t have rights to read the key from the registry. So note to self: Run everything as Administrator….
When it starts, the Start/Stop Scenarios tab opens and there are three main sections.
Section 1 is where you can select a scenario. Remember with OCSLogger you had to semi-randomly pick what to log? So you always picked the same stuff (S4/SIPStack) and then randomly picked some options like Inbound Routing and Outbound Routing hoping to get what you wanted.
Scenarios take the guesswork out of your hands. Microsoft has created a whole pile of scenarios for you with all of the correct options already selected. So for example if you aren’t tracking an Enterprise Voice issue, S4 will be unselected for you thus minimizing the amount of “noise” in your logs.
To select a scenario, just hit the pull down and
HOLY DUMBNESS WHAT IN SAM HILL!!!! YET ANOTHER UNSORTED LIST FROM THE LYNC/S4B TEAM. WHAT IS WRONG WITH YOU PEOPLE. SORTING IS LIKE THE EASIEST THING IN THE WORLD TO DO. %^&*(&*^%$#^&!@#!!!!!!!!! pick the desired scenario from the sorted list..
If you have multiple sites, you will also notice that the list contains duplicates…possibly a lot of them. If you type
Get-CsClsScenario | select Identity
in a PowerShell window you will see that the list in PowerShell matches the list in CLSLogger. Except the PowerShell version prepends the scenarios with the site name making the duplication easy to understand. Hopefully they will improve the naming in the scenario list to include the Site name in a future update.
Fortunately, all of the out-of-the-box scenarios are the same regardless of Site so you can pick any one of them. In my case, I selected AlwaysOn because I am lazy and that is the default option. After selecting one, the Scenario Information screen will list all of the logging options, logging levels, and logging Flags that are part of the scenario.
After selecting the scenario, you have to tell the logger against which pools and servers (and trunks????) you want to run this scenario against. So pick a pool or two off the list. You can also drill down to pick a specific server too in case you suspect a subset of your pool is having issues.
mp112.flinchbot.com is an AudioCodes gateway. PBX1 and PBX 2 are Asterisk servers….
The 3rd section, at the bottom is a PowerShell window showing you which PowerShell cmdlets the tool is running. This is a nice touch.
There are three buttons above the Topology window (Section 2). Before running a new scenario, click the “Logging Status” button to see if you are already doing logging against the pool/server(s) you selected in the Topology window.
If everything looks ready, click the “Start Scenario” button and watch the magic happen.
Actually, replicate your issue as fast as you can and then click the “Stop Scenario” button. No one wants to deal with a 37GB log file because you couldn’t be bothered to stop the logging until hours after the issue has been tested.
If none of the pre-configured scenarios match what you want to log, you can create your own custom scenario. To do this, click on the “Edit Scenario” tab and the following screen appears.
In general you will be editing one of the existing scenarios because you need an additional component to be logged or you need more detail than what is provided. In the image above, the ACPMCU scenario is selected. You can see in section 1 that this scenario logs AcpMcu as verbose and Collaboration, S4, and SIPStack as Information-level. Let’s say we want to add logging of the Mediation service to this scenario.
Scroll down in section 3 to find the “MediationServer” Component. Section 2 will adjust to “Information” and Flags will go to “All”. Just for fun, let’s change the Level value from Information to All.
Now you click on the “Save Scenario” button underneath section 3. You will be prompted to verify the change. After saving the change, Section 1 will be updated. Note that MediationServer is now added to the list.
The Scenario name now also has a new name I gave it which is admittedly not terribly descriptive. I just added “Custom” to the default name.
To create a new scenario, click the “Create Scenario” button found underneath section 2 and 3 – right above the 4 in the image. You’ll be prompted to provide a name so give it something descriptive beyond just “Test Scenario” or “Flinchböt’s Scenario 1”. A better name would be something like “Inbound calls from SIP trunk”
Now if you flip back to the Start-Stop Scenarios tab, you should see your new scenario in the Scenarios list. Select this and start your logging.
So the next step….looking at all of this wonderful data. That’s where the “Search CLS Logs” tab comes into use.
Unfortunately….nothing is automated here. It would be nice if it carried over the settings from the “Start/Stop Scenario” tab to here. Maybe in a future update….
From my point of view, the point of this tab is to get a unified log file that you can open in Snooper. As such, I leave most of this stuff empty.
Make sure the Start and End Time fields are correct. To me it feels like this is a semi-random guess by CLSLogger to what window of time you want to review. So don’t trust it to be correct or your logs may be very empty.
The only setting in Section 1 you have to set is the Log File Folder setting. You can’t type anything here and have to navigate to a folder. If you aren’t running this on a server then….manually create the folder on your PC in the exact same location it is on your server. I hope your PC has a D: drive like your server does. If not…..run this from the server.
Remember when we set the logging directory at the very beginning? Navigate to there and click OK.
You do not have to pick anything in section 2. So unless you really want to narrow down your logs, leave this blank. If you are using the AlwaysOn scenario, then it’s a good idea to check the relevant boxes here. How do you know which boxes to select? Go back to the “Start/Stop Scenario” tab and pick a specific scenario off the list and manually replicate what’s pre-configured there into Section 2.
In Section 3, you have to select the pool you logged against. Automatically having this setting copied from the “Start/Stop Scenarios” tab would be a time saver.
Once you have at least a Log File Folder, a valid time range, and a Server/Pool selected, click “Search Logs”. This will go out to the servers, grab the logs and put them into one big file.
Curiously, once this is done it asks you if you want to open the log file. Say No. This just launches Notepad and opening really large log files in Notepad is painful and the whole point of Snooper is so that you don’t have to use Notepad. But do take notice of the file name for the log.
You are going to open the log file in Notepad? Then no, I don’t want to open this file at all!
You don’t have to memorize the log file path in the message. It is conveniently listed in the PowerShell monitor (Section 4).
So how do you get this log file opened in Snooper which by absolutely any logic should be the default? Go to the menu at the top of the Logging Tool and select the Logs pull down. Then select “Open Logs with Snooper”. Like magic, Snooper opens and pulls in the log file automatically.
This should be the default action.
Now that it’s in Snooper, go do your Snooper magic to track down your issues and whatever it is you do in there. I know we are all adults, but what happens in Snooper stays in Snooper.