CLSLogging

Mit Lync 2013 hat Microsoft das Debugging von Fehlern auf Lync und Skype für Business Servern umgekrempelt. Der bisherige vom Namen schon älter wirkende OCSLogger kann zwar noch weiter verwendet werden, aber statt dessen hat Microsoft ein Service integriert, der aktuell aber nur per Kommandozeilenprogramm konfiguriert werden kann. Als Lync Administrator kann man damit "Szenarien" aktivieren, und dann werden damit auf den angegebenen Servern die verschiedenen Loglevel aktiviert, die zum Szenario passen.

Der Central Logging Service kann abstürzen, wenn beim Kopieren der Logs die Verbindung abbricht.
Siehe Release Notes auf http://technet.microsoft.com/en-us/library/jj205120(v=ocs.15).aspx

Logging mit Lync 2010 und früher

Haben Sie sich mal das Lync Logging Tool unter Lync 2010 genau angeschaut und im Vertrauen: haben Sie all die Optionen verstanden, die da aktiviert werden konnten? Zur Erinnerung hier noch mal eine Übersicht:

Und dann waren diese Optionen immer noch pro Server, d.h. sie mussten im Extremfall auf mehreren Servern das Tool zeitgleich starten und dann die Ergebnisse selbst zusammen fassen. Auf einem "Single Server" funktioniert das noch einfach aber sobald zwei oder mehr Server und noch ein Edge dazu kommt, müssen sie auf mehreren Servern die Einstellungen aktivieren und am Ende die Logs konsolidieren.

Szenarien

In Lync 2013 wurde das Logging umgebaut. Natürlich können Sie weiterhin mit OCSLogger einen Trace pro Server starten aber interessanter ist es, mit Lync 2013 eines der vordefinierten Szenarien für die Fehlersuche zu aktivieren und danach die Ergebnisse auszuwerten. Ein paar Stichworte:

  • Microsoft hat eine ganze Menge von Szenarien vorgegeben
  • Sie können zusätzliche eigene Szenarien definieren
  • Es kann immer nur ein Szenario pro Server aktiv sein
    Ein Sonderfall ist die "AlwaysOn"-Option, bei der ein Trace 24h läuft und permanent protokolliert. Siehe auch SfB: AlwaysOn Logging
  • Die Steuerung erfolgt per PowerShell oder CLSLogger.exe aus den Skype für Business DebugTools
  • Jeder Server protokolliert "lokal" die Traces mit
    Die Logs landen in der Regel auf C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing
  • Für das Logging auf dem Server ist der CLSAgent zuständig
    Der Code dazu liegt auf C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent
  • Zur Auswertung werden per Suche von allen Servern die gewünschten Informationen gesammelt und in einer Datei bereitgestellt
  • Diese "Ergebnisdatei" können Sie mit Notepad oder Snooper (OCSLogger) auswerten

CLSController.exe und ClsAgent.exe

Das Logging besteht aus einem Dienst, der auf allen Lync-Servern aktiv ist und einer Clientsoftware, die mit den Servern spricht. Der Dienst ist recht einfach in "Services" zu finden.

Da der Dienst natürlich auch remote angesprochen werden muss, lauscht er auf ein paar TCP-Ports. Laut aktueller Dokumentation müssen Sie die Ports 50001/TCP bis 500003/TCP erreichbar machen, um die Funktion zu nutzen. Dies betrifft insbesondere die Edge-Server die in der Regel auch nach innen durch eine Firewall abgeschottet sind. Auf dem Lync Server kommt das Programm CLSController.exe zum Einsatz, welches aktuell leider nur als Kommandozeile verfügbar ist.

Diese drei Ports werden gerne vergessen und liegen auch leider in der gleichen Range, die auch für RTAudio verwendet wird, die zudem auch auf dem Edge Server aus dem Internet erreichbar sind. Aber die Ports sind dennoch nicht von extern erreichbar. Trotzdem finde ich diese Portwahl zumindest unglücklich.

Konfiguration

Das komplette CLSLogging-System wird zentral konfiguriert. Über die Powershell können Sie sich die aktuelle Einstellung anschauen und bei Bedarf verändern.

PS C:\> Get-CsClsConfiguration
Identity                      : Global
Scenarios                     : {Name=AlwaysOn, Name=NonTopologyAlwaysOn, Name=MediaConnectivity,
                                Name=ApplicationSharing...}
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
NetworkUsagePacketSize        : 64
NetworkUsageThreshold         : 10
Version                       : 6.0.9319.0

Das "%TEMP%"-Verzeichnis liegt auf Windows Servern aber nicht unter C:\TEMP oder C:\Windows\Temp sondern da die Dienste als "Network Service" laufen, ist das Temp-Verzeichnis im Verzeichnis C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing. Dahingehend ist es natürlich schon erst einmal irritierend, wenn mit dem Parameter "CacheFileLocalMaxDiskUsage" bis zu 80% der Festplatte für die Cachedateien genutzt werden dürfen und kein absoluter Grenzwert oder eine "minFree"-Option genutzt wird.

Ich habe noch keine Testreihe gestartet, ob sic die 80% auf die Brutto-Kapazität der Festplatte beziehen oder auf den "freien Platz" und weiß daher auch nicht, ob CLSLogger schneller Platz wieder freigibt. Eine Überwachung des freien Platzes und ggfls. von TMP-Bereichen ist auf jeden Fall ratsam

Auswertung

Die Logs landen auf den Servern und werden durch CLSController wieder importiert. Per PowerShell können Sie dann auf dem Server oder auch mehreren Servern das entsprechende Scenario aktivieren:

Start-CsClsLogging -Scenario "PowerShell"
Success Code - 0, Successful on 2 agents
 
Tracing Status:
 
lyncpool.msxfaq.de (lyncpool v5.0.8308.0) (AlwaysOn=No,Scenario=PowerShell,Started=12/10/2012 10:32:21 AM,By=admiun,Duration=0.04:00)
    lyncfe1.msxfaq.de (lyncfe1 v5.0.8308.0) (Same as pool)
    lyncfe2.msxfaq.de (lyncfe2 v5.0.8308.0) (Same as pool)

# oder z.B. für Telefonanrufe

Start-CsClsLogging `
   -Scenario "IncomingAndOutgoingCall" `
   -Pools "sfb01.msxfaq.net"

Dann sollten sie Zeitnah natürlich den Fehler nachstellen und dann zügig die Protokollierung wieder anhalten.

Stop-CsClsLogging `
   -Scenario "IncomingAndOutgoingCall" `
   -Pools "sfb01.msxfaq.net"

# oder gleich für alles

Stop-CsClsLogging
 
cmdlet Stop-CsClsLogging at command pipeline position 1
Supply values für the following parameters:
Scenario: PowerShell
Success Code - 0, Successful on 2 agents
 
Tracing Status:
 
lyncpool.msxfaq.de (lyncpool v5.0.8308.0) (AlwaysOn=No)
    lyncfe2.msxfaq.de (lyncfe2 v5.0.8308.0) (Same as pool)
    lyncfe1.msxfaq.de (lyncfe1 v5.0.8308.0) (Same as pool)

Die gesammelten Logs sind nun natürlich noch nicht lesbar. Das erfolgt dann mit Search-CsClsLogging:

# Ausgabe in Datei
Search-CsClsLogging -OutputFilePath cslog.txt

# oder

Search-CsClsLogging `
    -Pools "sfb01.msxfaq.net" `
    -StartTime (get-date).addminutes(-30) `
    -LogLevel "All" `
    -MatchAll `
    -OutputFilePath "c:\temp\trace.txt"

Ich habe mir angewöhnt hier immer absolute Pfade anzugeben. Bei relativen Pfaden landen die Ausgaben in der Regel in C:\Program Files\Skype for Business Server 2015\ und da haben Sie erst mal keine Rechte. Entsprechend kommt dann die Fehlermeldung:

Search-CsClsLogging : Unable to create OutputFilePath output file 'C:\Program Files\Skype for Business Server 2015\trace.txt' -
Access to the path 'C:\Program Files\Skype for Business Server 2015\trace.txt' is denied.

Lync 2013 Debugging Tools

Bei Lync 2010 gab es noch das Ressource Kit, in dem das Programm Snooper (Version 4.0.7577.0) enthalten war. für Lync 2013 gibt es das Programm als eigenen Download:

Microsoft Lync Server 2013 Debugging Tools (2,5 MB)
http://www.microsoft.com/en-us/download/details.aspx?id=35453

Die Installation auf dem Lync Server erfolgt einfach durch ein Doppelklick und ist in wenigen Sekunden erledigt. Sie können die Tools offiziell auf Windows 2008R2 und Windows 2012 installieren. Aber auch eine Installation auf Windows 7 ist möglich, wenn Sie die Voraussetzungen schaffen, auf die sie hingewiesen werden:

Wenn Sie nun die aktuelle Version von Microsoft herunter laden (z.B. 2019667 Latest Supported Visual C++ Downloads) dann wird das Setup damit nicht zufrieden sein, es muss genau die 11.0.50727 sein. Zum Glück ist diese Version in den Lync Installationsquellen enthalten. Erst dann installieren sich die Tools nach "C:\Program Files\Microsoft Lync Server 2013\".

Leider legt der Installation keine Icons im Startmenü an. Auf einem Client ist natürlich Snooper die interessanteste Komponente um auch Logs auf dem Client auszuwerten oder Logs, die man vom Kunden gesendet bekommt.

Achtung
Sie können sogar noch die Lync 2010 Debug Tools nutzen. Da diese aber wie der CLSLogger die gleiche API nutzen, müssen Sie den ClsAgent.exe auf dem Computer beenden

Am Anfang mag der Umgang mit dem neuen CLSLogging kompliziert erscheinen aber wer bei der Fehlersuche auf mehreren Servern das Logging aktivieren musste, will nie wieder zur alten Lync 2010-Technik zurück.

Logging auf dem Lync 2013 Client

Auch auf dem Lync Client können Sie weiterhin ein Logging einschalten. Siehe dazu auch Lync Keyhole Diagnose.

Allerdings hat sich der Ablagepfad der Logs von Lync 2010 zu 2013 geändert:

Lync 2010: C:\Users\<%Username>\Tracing
Lync 2013: C:\Users\<%Username>\AppData\Local\Microsoft\Office\15.0\Lync\Tracing
Skype for Business : C:\Users\<%Username>\AppData\Local\Microsoft\Office\16.0\Lync\Tracing

Auch die Profileinstellungen wurden verlagert:

Lync 2010: C:\Users\<%Username>\AppData\tLocal\Microsoft\Communicator
Lync 2013: C:\Users\<%Username>\AppData\Local\Microsoft\Office\15.0\Lync\

Weitere Links