PowerShell: Outlook Client-Versionen im Exchange RPC-Log analysieren

Bei der Migration von einem Exchange Server auf eine neuere Version ist es wichtig zu wissen, mit welchen Clients das aktuelle System noch kommuniziert. Hierzu gibt es mehrere Möglichkeiten, diese kann unter anderem mit einer evtl. vorhandenen Software zur Inventarisierung gemacht werden, mit einer temporären Indizierung von Software oder mit der folgenden Variante gemacht werden: Eine automatische Auswertung der Exchange RPC-Log-Dateien.

Die genutzten Dateien

Auf jeden Exchange-Server, der mit Clients kommuniziert, werden standardmäßig im Exchange-Installationsverzeichnis Logdateien angelegt, in die die Verbindungen mitprotokolliert werden. Da es sich im meinem aktuellen Fall um eine Exchange Server 2010-Farm handelt, die abgelöst werden soll, liegen die Logfiles unter
C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access

Diese Dateien werden durchforstet und ausgewertet. Für die Auswertung nutze ich nur die Windows PowerShell, für die spätere Ausgabe als HTML-Datei greife ich wieder auf das Modul ReportHTML zurück, welches ich bereits hier beschrieben habe.

Der Ablauf

Alles beginnt damit, dass ich testweise die Log-Dateien vom Exchange-Server aus dem weiter vorne aufgeführten Pfad C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access in einen temporären Ordner auf meinem Client kopiere. Dies mache ich nur, um das Skript anzupassen und um die Menge an Logfiles klein zu halten, damit Test-Durchläufe nicht ewig lang dauern (und natürlich, um nicht Logdateien auf dem Live-System löschen zu müssen) 🙂

Mit diesen drei Dateien kann ich erstmal testen und die Ausgabe so anpassen, wie ich sie benötige. Was alles zu beachten ist:

  • Welche Informationen möchte ich sehen?
  • Wie viele (Cas-) Server habe ich im Einsatz?
  • Wie soll der fertige Report aussehen?

Mein Report

Damit das alles ein bisschen greifbarer wird, hier ein Beispiel von meinem Report. Ich habe insgesamt zwei Server, die Verbindungen zu Clients aufbauen. Diese beiden Server möchte ich gerne nebeneinander im Report anzeigen, damit ich nicht erst komplett über den ersten Server scrollen muss, damit ich die Verbindungen vom zweiten System sehe.
Weiterhin möchte ich sehen, welcher Benutzer sich verbindet, welche Outlook-Version sich dahinter versteckt, welche Build-Nummer das Outlook hat und welche IP-Adresse der Client hat.
Das ganze sieht dann final wie folgt aus:

Wird die HTML-Datei aufgerufen, sieht das erstmal so aus wie im Screenshot. Man kann nun die einzelnen Reiter anklicken, um eine Sortierung zu bekommen: entweder nach Benutzer, Version, Build-Nummer oder IP-Adresse. Awesome 🙂

Der PowerShell-Code

Bevor wir zu den Erklärungen kommen, hier der eigentliche PowerShell-Code:

 

Download als TXT-Datei:

Einige Erklärungen zum Code

Ich habe ein bisschen gebraucht, bis ich den Code so hatte, wie ich ihn letztendlich haben wollte. Diese Informationen gebe ich hier mal an euch weiter, Hilfe und Beschreibungen können ja nicht schaden 🙂

Die Auswertung der .log-Dateien

Die eigentliche Auswertung der Dateien erfolgt mit dem Befehl

Alle Dateien mit der Endung .log werden mit Get-ChildItem geholt und an die Funktion Get-MrRCAProtocolLog übergeben. Diese Funktion macht einen großen Teil des Skripts aus und wurde von Mike F Robbins geschrieben, thank you for this! 🙂

Die Funktion durchforstet alle Log-Dateien und ich nutze die drei Werte client-name, client-software-version und client-ip. Um nicht ausschließlich die Build-Version zu nutzen, wird die Nummer nochmal in einen Namen umgeschrieben. Dies wird mit der zweiten Funktion Get-MrOutlookVersion realisiert. Der relevante Code-Teil ist

An dieser Stelle könnten auch noch weitere Attribute abgefragt und aufgelistet werden. Welche Attribute dies sind, lässt sich aus einer .log-Datei auslesen:

Der Parameter -unique sorgt dafür, dass ein Benutzer nur einmal aufgeführt wird. Wird dies nicht genutzt, so wäre jede Log-Zeile auch in der Auswertung enthalten. Meldet sich ein Client an einem Tag 7x an über einen Zeitraum von einem Monat, wären dies über 200 Einträge für einen einzigen Benutzer. Ein kleines Manko habe ich allerdings mit dieser Filterung: Benutzt ein Anwender mehrere Geräte, so wird hier nur der erste Eintrag aufgegriffen. Hier könnte alternativ nach einer einmaligen IP-Adresse gefiltert werden, dies macht allerdings auf einem Terminal Server keinen Sinn, da hier mehrere Benutzer von der gleichen IP-Adresse kommen.

Besonders gut gefallen (weil ich wieder was neues gelernt habe) hat mir die folgende Zeile:

Diese kleine Zeile ersetzt die Build-Nummer durch einen sprechenden Namen. Realisiert wird dies durch die Funktion Get-MrOutlookVersion.
Innerhalb dieser Funktion wird die Build-Nummer abgefragt, dies sieht dann wie folgt aus:

Ich habe die ursprüngliche Liste ein wenig erweitert und um weitere Versionen ergänzt. Was wichtig ist, ist die Abfrage nach der Outlook-Version mit einer fünfstelligen Nummer an Stelle drei (16.0.11001.xxxxx). Wird diese nicht explizit angegeben, kommt die Abfrage hier durcheinander und sortiert das Office 2019 bzw. Office 365 unter Office 2013 ein.
Kleiner Tipp von mir an dieser Stelle: Schauen Sie sich die Build-Nummern einmal an, manchmal kann man hier “Zwischenversionen” erkennen, z.B. durch die Installation von Hotfixes oder ähnliches. Nicht immer sind die Build-Nummern genau so, wie man sie erwartet. Dies ist auch der Grund, warum ich neben einem sprechenden Namen zusätzlich noch die eigentliche Build-Nummer mit ausgebe, obwohl diese ja schon durch die kleine Funktion “korrekt” ersetzt hätte werden müssen (könnte, sollte und so 😉 )

Jan

Jan Kappen arbeitet sein 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Seit September 2018 ist Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.