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

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.

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:

• getTransporterError-tt.mm.jjjj-hh-mm-ss.csv
  Eine Zusammenfassung der ausgewerteten Errors als "CSV-Datei" mit entsprechenden Spalten und Werten
• getTransporterError-tt.mm.jjjj-hh-mm-ss-errorsum.csv
  Eine Zusammenfassung der Fehler und Warnungen gruppiert nach "Klassen", d.h. ähnliche Fehler werden zusammen gezählt
• getTransporterError--tt.mm.jjjj-hh-mm-ss-Usersum.csv
  Eine Übersicht der Benutzer mit der Anzahl der Fehler und Warnungen für das Postfach und einer eigenen Spalte für die Anzahl der Fehler zu verschlüsselten Elementen

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.

Man kann hier mehrere Dinge erkennen:

• Verschiedene Benutzerschreibweisen
  Die Transporter Suite scheint bei einigen Fehlern die Notes-Adresse und das andere mal die SMTP-Adresse als Benutzer auszugeben.
• Warnung und Error sind fraglich
  Es gibt Meldungen die als Error bezeichnet, aber wohl eher kosmetisch sind (z.B.: Dictkey sind oft irrelevante Feiertage). Andererseits werden verschlüsselte Elemente (skipencrypteditem) oder Fehler bei Anlagen (AttachmentMigError) nur als "Warning" ausgegeben.

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

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

• TransporterSuite
• TransporterSuite Notes