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 50001, TCP 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 Infolevel, 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-CsClsProviderpage on TechNet currently (April 2013) states that the provider Nameparameter 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 failwhen you stop correctly run the Stopcommand:
>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 specificcustom 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.
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.
Cheers, great summary :)
ReplyDeleteVery nice article, thanks alot
ReplyDeleteExcellent summary, just what i was looking for.
ReplyDeleteThank you so much. Nice detailed explanation!
ReplyDelete