Get-Transporterlog

Dieses Skript kann nur die Logs auswerten, die von der Notes Transporter Suite bei einer GUI-Migration durchgeführt werden. Wenn Sie bei einer Migration per Powershell mit DGBView das Log aufzeichnen, dann hat dieses ein anderes Format.

Auch wenn der Name erst mal auf ein Powershell-Skript hinweist, so ist Get-TransporterLog ein VBScript, welches die Protokolldateien der TransporterSuite auswertet. Wenn Sie schon einmal eine größere Notes Umgebung migriert haben, dann werden ihnen erst mal die Haare zu Berge stehen, wie viele Errors und Warnungen sich in den Protokolldateien der Transporter Suite finden. Hier mal ein Auszug:

Und wenn Sie bei 400 Benutzern dann 100 MB eines solchen Logfiles haben, dann scheitern Sie bei jedem Versuch, dies manuell auszuwerten. Aber auch eine einfache Auswertung ist nicht möglich, da die Fehlermeldungen alle unterschiedlich formatiert sind. Manchmal steht der Benutzer am Ende, manchmal ist der Betreff in Klammern eingeschlossen. Auch erstrecken sich einige Meldungen über mehrere Zeilen. Kurzum, es war Zeit für ein VBScript, welche die einfach auswertet und die Fehler entsprechend konsolidiert.

Diese Logs werden nur bei einer Migration über die GUI gestartet. Die Powershell Commandlets geben diese Daten an die Debug-:Schnittstelle aus, die von der GUI überwacht wird. Wenn Sie hingegen nur mit der Powershell und per Skript migrieren, dann können Sie vorher den Sysinternals DBGView als Minianwendung starten und nach dem Ende des Durchlaufs wieder beenden, z.B. wie in diesem Beispiel

$migusers = get-content c:\migusers.txt
foreach ($user in $migusers) {
    dbgview.exe /l logfile-$user.txt
   
    move-dominomailbox $user -Targetmode Merge
   
    (get-wmiobject Win32_Process -filter "Name = 'dbgview.exe'") `
|    foreach {$_.terminate()}
}

Das Skript

Ich habe es mir einfach gemacht, indem das Skript einfach die Daten von STDIN annimmt, auswertet und dann drei Dateien erstellt. Der Aufruf erfolgt also einfach in der Form:

type transporter*.log | cscript.exe gettransporterror.vbs

Auf der Konsole sieht dies dann (hier nur mit wenigen Testdaten) etwas wie folgt aus

Aufruf des Skripts und Diagnoseausgabe

Auch den VBScript eigentlich "nur" interpretierter Code ist, und damit langsamer als ein kompiliertes Programm sein muss, so ist die Leistung auch führ größere Migrationen ausreichend. Selbst auf meinem Notebook habe ich ganz passable Laufzeiten erhalten.

Quelle in MB Quelle in Zeilen #Events Debug Laufzeit Performance
5x5 MB 200361 51313 3 75 Sek 200kByte/Sek
2671 Zeilen/Sekunde
5x5 MB 200361 51313 2 19 Sek 863kByte/Sek
10545 Zeilen/Sekunde
91 MB 1.068.130 230003 2 82 Sek 1109kByte/Sek
13025 Zeilen/Sekunde

Als Bremse stellt sich natürlich ein höher gestelltes Debugging dar, da hierbei das Debugfile immer wieder fortgeschrieben wird. 

Hinweis:
Ich kann mein Skript natürlich nur auf die Fehler reagieren lassen, die ich selbst schon gesehen habe. Neue Fehler werden natürlich nicht unterschlagen, sondern ungefiltert im Protokoll abgelegt und können einfach erkannt werden.

Die Ergebnisse

Das Skript legt bei jedem Lauf drei Dateien an, von denen ein Teil des Dateinamens das Datum und die Zeit des Starts wiedergibt:

Das ganze kann man einfach in Excel öffnen und wie üblich sortieren, filtern, auswerten etc.

Die Datei "getTransporterError-tt.mm.jjjj-hh-mm-ss.csv" enthält die geparsten Fehler in einer CSV-Datei zur Filterung, Sortierung etc.

Volle Ergebnisliste

Man kann hier mehrere Dinge erkennen:

Man muss also schon selbst genauer hinschauen.

Die zweite Datei "getTransporterError-tt.mm.jjjj-hh-mm-ss-errorsum.csv" enthält die Liste der Fehler und ihre Häufigkeit

ErrorSum

Zu jeder Fehlerklasse wird die Schwere und die Häufigkeit der Vorkommen aufgeführt. So kann ich z.B. einfach die Bedeutung von verschlüsselten Mails und anderen Fehlern erkennen.

Die letzte Datei "getTransporterError--tt.mm.jjjj-hh-mm-ss-usersum.csv" zeigt eine Liste der Benutzer und pro Benutzer aufsummiert die vorgekommenen Warnungen und Fehler und als eigene Spalte die Anzahl der verschlüsselten Mails.

So kann man die Mailboxen ausfindig machen, die anscheinend die meisten Probleme verursachen werden.

Mit Warnungen und Fehlern umgehen

Ideal wäre eine Migration ohne Fehler und ohne Warnungen. Das funktioniert mit Testpostfächern fast immer aber mit produktiven Daten eher nicht. Es gibt auch in Notes immer mal wieder inkonsistente Daten (z.B. fehlende Serientermine, Mails ohne Sendedatum etc.) die bei der Transporter Suite zu Warnungen führen. Aber Sie können natürlich anhand der Meldungen die fraglichen Elemente genauer unter die Lupe nehmen. Sicher wird man nicht alle Elemente "reparieren" aber die Anwender können sicher verschlüsselte Elemente entschlüsseln, damit diese bei der Migration nicht vergessen werden.

Auf der anderen Seite können Sie mit Skripten und den Notes COM-Objekten natürlich auch durch die Mailboxen laufen und die fraglichen Elemente verändern oder sogar löschen (z.B. Feiertage) und damit jede Menge Meldungen zukünftig vermeiden.

Mit den Tools "Remove-Holiday" und "Fix-Repeatunit" (Siehe TransporterSuite Notes) habe ich schon entsprechende Tools für zwei Anwendungsfälle.

Dieses Skript ist kein öffentlicher Download
Bitte haben Sie Verständnis, dass ich solche Skripte, die zu großem Teil bei Kunden entwickelt und angepasst werden müssen´, nicht zum öffentlichen Download bereit stelle.
Dieses Skript ist noch nicht nicht öffentlich, da es nur ein Baustein einer erfolgreichen Notes Migration ist und und ich diese Leistung noch meinen Kunden vorbehalte. Informationen, warum, einige Skripte nicht öffentlich sind, finden Sie auf nicht public.

Wer die Migration direkt mit der Powershell durchführt, kann dieses Skript so leider nicht nutzen, da die Ausgaben über Debugview leider komplett anders formatiert sind. Ich habe hier für mit GetPSTransporterError ein vergleichbares VBScript entwickelt.

Weitere Links

Keywords:VBScript