UC  ClientLog Parser

Der Lync Client protokolliert per Default umfangreiche Daten auf dem Windows Client. in  bis zu drei Textdateien a 5 Megabytes werden umlaufend Ausgaben generiert, die für die Fehlersuche essentiell sind. Ich nutze sehr gerne diese Clientlogs, da sie sehr schnell erreichbar sind und man nicht erst ein Logging auf dem Server zur Fehlersuche aktivieren muss.

Siehe auch Keyhole-Debugging und Parse-UCCAPI

. Allerdings ist nun nicht jeder "1st-Level Helpdesk" in der Lage diese Logs zu finden, zu lesen und den Fehler oder die Einstellungen zu finden. So bin ich auf die Idee gekommen, mit einer eigenständigen Windows Applikation eben diese Logs zu parsen und ggfls. sogar kontinuierlich zu überwachen und Events zu melden.

Die Idee

Der Lync Communicator ist defacto der Client für alle Lync Aufgaben. Leider verschweigt er viele nützliche Informationen, die für eine Fehlersuche oder Eingrenzung hilfreich wären. Wer schon einmal in das Debug-Log geschaut hat, kann dort sehr wohl die detaillierte Fehlermeldungen eines fehlgeschlagenen Anrufs, einer gescheiterten Konferenzteilnahme oder einer Anmeldung sehen. Dazu müssen Sie nur das Logging aktivieren und die Inhalte dort auslesen. Aber das lesen von Megabytes an Logdateien ist zugegeben nicht gerade einfach. Es braucht schon etwas Übung und genau das soll dieses Programm "lösen"

Die Dateien

Sobald Logging aktiviert ist, protokolliert Lync seine Aktivitäten in Textdateien, die einfach gelesen werden können. Wenn ich mit Lync 2013 arbeite, dann sind die bis zu sechs Dateien im Verzeichnis C:\\AppData\Local\Microsoft\Office\15.0\Lync\Tracing\, (bei Lync 2010 liegt es in C:\\Tracing). Leider habe ich bei Microsoft nicht gefunden, wie genau der Lync 2013 Communicator die Logs durchrollt, so dass ich nach ca. 300 MB sicher war, dass Lync durchrollt

Wenn es also keine Lync-UccApi-0.UccApilog gibt, dann fängt er damit an. Danach schreibt er eine Lync-UccApi-1.UccApilog und dann eine Lync-UccApi-2.UccApilog. In der Folge fängt er aber an, die bestehenden Dateien um zu benennen, d.h. aus der Lync-UccApi-0.UccApilog wird dann eine Lync-UccApi-0.UccApilog.bak uns so weiter. Die aktuellste Datei ist also immer die Lync-UccApi-2.UccApilog, es sei denn sie wurde gelöscht. Ich habe mich nun damit bedient, dass die Software einfach die Datei "Lync-UccApi-?.UccApilog" überwacht, die zuletzt verändert wurde. Am Anfang ist das die "0" und dann die "1" und irgendwann immer nur noch die "2".

Ich bin noch nicht sicher, ob ein "Parsen" der bestehenden Dateien sinnvoll ist. für eine nachträgliche Analyse ist dies sicher interessant, zumindest wenn das Logging schon angeschaltet war.

Aufgabenstellungen

Deutlicher wird dies, wenn die möglichen Anforderungen beschrieben werden.,

  • Dirkter Zugriff auf die aktuelle Debugdatei
  • Anzeigen von Fehlern (MS-Diagnostics)
  • Anzeigen der Policies (Location, Conference, Mediarelay, Voice)
  • Anzeigen der MRAS/Edge Einstellungen
    MRAS-Token + URL
  • Anzeigen der ICE-Kandidaten
    Candidates (a=candidates, a=remote-candidate)
  • Tracing der SIP-Meldungen (INVITE, BYE, REFER, ERROR
  • Ausgabe der SIP Cause
  • MS-Errors (ms-diagnostics)
  • Anzeigen der InCall QoE- Daten

Der Inhalt

Mein Schwerpunkt liegt auf der Behandlung von Fehlern bei SIP-Verbindungen um Probleme leichter diagnostizieren zu können. Als zweiten Punkt interessiert mich natürlich, welche SDP-Endpunkte zum Einsatz kommen, d.h. welchen Weg meine RTP-Daten gelaufen sind. All diese Daten können aus dem Trace bzw. den darin enthaltenen SIP-Messages extrahiert werden.

Erste Anlaufstelle ist natürlich der Kopf des SIP-Pakets selbst. Hier ist schon mal das Feld "ms-diagnostics" eine gute Quelle.

ms-diagnostics: 10037;source="NAWLYNC001.netatwork.de";reason="Normal termination response from gateway before the call was   established";component="MediationServer";sip-reason="Q.850 ;cause=16"
ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";domain="msexchangefaq.de";dns-srv-result="NegativeResult";dns-source="WireQuery";source="sip.netatwork.de"
ms-diagnostics: 1027;reason="Cannot route this type of SIP request to or from federated partners";source="sip.netatwork.de"
ms-diagnostics: 1003;reason="User does not exist";destination="room3sg5@netatwork.de";source="sip.netatwork.de"
ms-diagnostics: 12006;reason="Trying next hop";source="NAWLYNC001.MSXFAQ.DE";PhoneUsage="Usage DE +49 no +49900";PhoneRoute="Route DE PB M1000 NationalDE noPremium";Gateway="nawm1000.netatwork.de";appName="OutboundRouting"
ms-diagnostics: 5002;reason="Request was cancelled";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FTranslationService";source="NAWLYNC001.netatwork.de"
ms-diagnostics: 12006;reason="Trying next hop";source="NAWLYNC001.MSXFAQ.DE";PhoneUsage="Usage DE +49 no +49900";PhoneRoute="Route DE PB M1000 NationalDE noPremium";Gateway="nawm1000.netatwork.de";appName="OutboundRouting"
ms-diagnostics: 5002;reason="Request was cancelled";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FTranslationService";source="NAWLYNC001.netatwork.de"

 

Die Auswertungen

 

 

Das Programm

Meine erste Idee war ein GUI-Programm, welches in der Taskleiste als Icon ablegt und z.B. als Bubble-Info die letzten Meldungen anzeigt. Auf der anderen Seite kostet eine GUI-Entwicklung mich deutlich mehr Zeit als ein schnödes PowerShell, zu dem ich die entsprechenden Module und Codes schon vorrätig habe. Daher ist es doch wieder ein PowerShell-Script geworden, welches

 

Ich habe mich mal wieder an einem "GUI-Programm" versucht und nicht per PowerShell die Dateien ausgewertet. Mein Ziel war natürlich ein "Klick Once"-Programm, welches aus nur einer EXE besteht und ohne Installation lauffähig ist. Das Programm prüft zuerst,, dass unter Lync das Logging auch tatsächlich aktiviert ist. Erst dann macht es weiter. Es prüft dazu den Registrierungsschlüssel

PS > get-childitem C:\\AppData\Local\Microsoft\Office\15.0\Lync\Tracing\Lync-UccApi-*.* | sort lastwritetime

 

Diese Seite ist noch nicht fertig

Weitere Links