FixNotesItems

VBScript und 64Bit !
Viele 32bit COM-Objekte lassen sich auf einem 64bit System nur instanziieren, wenn die 32bit Version von CSCRIPT/WSCRIPT genutzt wird, welcher unter C:\Windows\SysWOW64\cscript.exe liegt.

Seit Exchange 2007 gibt es die TransporterSuite, welche die Übernahme von Daten aus Notes nach Exchange bei einer Migration erleichtert. Nachdem ich nun schon mehrere Migrationen geschafft habe kann ich sagen, dass nicht alle Informationen korrekt übertragen werden. Das ist besonders dann störend, wenn die Transporter Suite einfach nur "Fehler" meldet, aber keine Details dazu offenbart, welche Elemente nun nicht übertragen werden konnten. Mit etwas Suchen und verschiedenen Tests kann man aber die Übeltäter recht einfach dingfest machen. Meist sind es Feiertage, Jahrestage, Erinnerungen, besondere Termine und andere Objekte, die bei der Migration zu Fehlern oder Warnungen führen.

Prüfen Sie, ob die hier durchgeführten "Korrekturen" mit der aktuellen Version der Transporter Suite noch erforderlich sind. Microsoft entwickelt die Transporter Suite in eigenen Intervallen weiter, so dass das ein oder andere Problem schon gefixt sein kann.

Quelle putzen

FixNotesItems verbindet sich per Notes COM-API (ein installierter und mit Notes.INI versehener Notes Client ist Voraussetzung) auf die per Parameter übergebene Datenbank. Der aufrufende Benutzer muss die Berechtigungen für den Zugriff auf dieses Datenbanken haben. Dann nutzt das Skript den "AllDocuments"-View, um eine Liste aller Objekte zu erhalten.

Dankbar wäre auch eine Einschränkung auf andere Views wie z.B. "$Calendar", was im Bezug auf Termine das Tempo sicherlich erhöht hätte. Aber hierbei habe ich immer nicht alle Objekte gefunden.

Für jedes Objekt prüft FixNotesItems die Probleme und korrigiert diese, soweit möglich. Dazu gibt es aktuell folgende Parameter

  • CMD="removeholiday"
    Ähnlich wie Outlook kann auch der Notes Client im Kalender verschiedene Feiertage hinzufugen. Diese Termine sind an dem Notes-Feld $CSFlags="hi" oder $CSFlags="hc" erkennbar. Stößt die Transporter Suite auf solche Elemente, dann überspringt Sie diese, was eigentlich schon mal gut ist. Outlook bringt ja ebenfalls Feiertage mit. Aber die Fehlermeldungen stören derart, da man pro Postfach immer Fehler hat und kritische Fehler nicht mehr erkennt. FixNotesItems entfernt diese Feiertage in der Quelle.
  • CMD="FixAppointment"
    während Outlook nur Termine und wiederkehrende Termine kennt, nutzt Notes auch noch "Jahrestage" und "Erinnerungen" als besondere Termine, die die Transporter Suite natürlich wieder mit Fehler quittiert. Man erkennt Sie am Feld "AppointmentType", welche für normale Termine auf "0" steht. Ganztägige Termine werden intern dennoch mit einer Start/Endezeit von 04:00 bis 20:00 gepflegt. Daher sollte man aus Erinnerung und Jahrestagen ganztägige Termine machen.
Original AppointmentType Änderung Beschreibung

0 = Normaler Termin

Keine Änderung

Diese Standardtermine migriert die Transporter Suite meist problemlos

1 = Jahrestag

AppointmentType=2

Jahrestage kennt Exchange so nicht und meldet einen Fehler bei der Migration. Die Umsetzung in einen ganztägigen Termin übernimmt den Termin. Allerdings ist dieser in Outlook dann "unter Vorbehalt" zugesagt. Notes kennt Leider nur "belegt" ("BookFreeTime=1") oder Frei/Vorbehalt. Das kann aber nachfolgend gefixt werden (Siehe Tentative2Free)

2 = Ganztägig

Keine Änderung

Diese Standardtermine migriert die Transporter Suite meist problemlos

3 = Besprechung

keine Änderung

Diese Standardtermine migriert die Transporter Suite meist problemlos

4 = Erinnerungen

AppointmentType=2

Die Transporter Suite meldet auch diese Elemente als "Warning". Konvertiert man diese auch in einen ganztägigen Termin, dann kommen diese Elemente ebenfalls mit
  • Eine frühere Änderung auf 0 (normaler Termin) hat dazu geführt, dass die Termine von 04:00-20:00 importiert wird
    Weitere Werte sind: . FixNotesItems ändert den Wert von "AppointmentType" auf 2 (Ganztagtermin), damit diese Termine importiert werden können.
  • CMD="FixRepeatunit"
    Etwas kniffliger war die Analyse dieser Fehlerquelle. Wenn ein Anwender eine wiederkehrende Erinnerung anlegt, dann kann die Transporter Suite diese nicht  übertragen. Selbst nach einer Konvertierung in einen normalen Termin gibt es noch immer einen Fehler. Letztlich scheint der Inhalt des Felds Repeatunit der Auslöser zu sein, wenn er auf "Y" statt "YD". steht. FixNotesItems ändert den Wert auf YD, damit die Transporter Suite die Daten sicher importiert.
  • CMD="FixFaxBody"
    Diverse Faxlösungen senden empfangene Faxe als TIFF-Anlage per SMTP an Notes und lassen dabei den Body "leer". Selbst Notes zeigt das in der Übersicht etwas seltsam an. So empfangene Faxe haben kein Zeichen für einen Anlage

    Und wenn man die Mail öffnet, dann ist die Anlage zu sehen aber der Body leer.

    Solche Elemente kann die Transporter Suite nicht korrekt übertragen, da der Body in Exchange nicht leer sein darf. Auch hier ist die Abhilfe recht einfach: Mit dem Befehl "FixFaxBody" werden einfach alle Mails, die von "FAXG3/" kommen, mit einem Body versehen.

Es gibt sicher noch weitere Dinge, die bei der Migration zu Fehlern führen, aber mit dem Tool "FixNotesItems" noch nicht gelöst werden können. Sie sehen auch, dass es für die Microsoft Entwickler schwer ist, alle möglichen Kombinationen zu erstellen, die nicht mal in den Notes Programmieranleitungen zu finden sind. Insofern bin ich sicher, dass zukünftige Migrationen mir noch weitere Dinge aufzeigen werden, die vorab zu korrigieren sind.

Einsatz und Aufruf

Auch wenn FixNotesItems ein VBScript ist, so benötigt es zuerst einen installierten Notes Client. Zudem wird die Datenbank, der Servername, ein optionales Kennwort und die gewünschten Aktionen über Kommandozeilen angefordert. Hier ein Beispiel:

cscript FixNotesitems.1.0.vbs
  /nsffile:"C:\Programme\lotus\notes\data\AdminMail.nsf"
  /cmd:"FixRepeatunit,FixAppointment,removeholiday"

Der Aufruf mit CSCRIPT ist ratsam, damit die Bildschirmausgaben nicht als Messagebox bestätigt werden müssen. Die Parameter bedeuten im Einzelnen:

  • /Server
    Name des Notes Servers in der gleichen Schreibweise, mit der auch der Notes Client darauf zugreift, z.B. "SERVER/Domain/ORG". Wenn lokale Dateien geöffnet werden sollten, dann lassen Sie den Server einfach leer
  • /NSFFile
    Pfad und Name der Notes Datenbank. Dies kann auch eine lokale Datei sein.
  • /Password
    Kennwort für die genutzte NOTES.INI.
  • /cmd
    Auszuführende Codebereiche. Das Skript macht eine "INSTR" Suche um die erforderlichen Aktionen dann auszufahren.

Wird das Skript ohne Parameter aufgerufen, dann erscheint eine kurze Hilfe

"Aufruf: FixNoesItems /server:<NotesServer> /nsffile:<Quelle> /csvffile:<Ziel>"
""
"Required:	/nsffile:""mail/Username.nsf"" or ""c:\pfad\datei.nsf"
"Optional:	/server:<NotesServer> leave empty für local files"
"Optional:	/password:""verySecurepassword"""
	wscript.echo "Optional:	/cmd:""command1,command2,command3"""

Wird das Skript ohne Kommando-Parameter aufgerufen, dann durchläuft es aber alle Objekte und zeigt den Betreff (Subject) mit an.

ReadOnly by Default
Werden die Kommandos nicht "GROSSGESCHRIEBEN", dann startet das Skript zwar die Module aber arbeitet nur lesend, d.h. es wird nichts korrigiert. Ideal, um die eigenen Berechtigungen zu Prüfen und die Ausgaben zu analysieren.

Damit ist sichergestellt, dass nur dann etwas geändert wird, wenn wirklich etwas zu ändern ist.

Ausgabe

Die Ausgabe erfolgt nicht nur auf dem Bildschirm, sondern auch im Dateisystem. Eine Debug-Datei protokolliert alle Bildschirmausgaben während eine Logdatei die entsprechenden Elemente und damit verbundenen Aktionen protokolliert:

Weiterhin wird pro NSF-Datei eine eigene CSV-Datei angelegt.

CSV Report

Download

Download noch nicht verfügbar. Bitte sprechen sie mich bei Interesse an.

Offen

Weiterentwicklungen sind geplant, wie diese bei weiteren Notes Migrationen erforderlich werden. Auf meiner Agenda steht dazu

  • Stabilität mit COM verbessern
    Anscheinend hängt ab und an die Notes COM-API, wenn das Skript zu schnell nacheinander aufgerufen wird. Killt man dann alle Notes Prozesse im Taskmanager und startet den Aufruf erneut, dann funktioniert es wieder. Eventuell hilft eine 15 Sekunden Pause am Ende nach dem Freigeben der Notes Session, um dieses Problem zu umgehen.
  • Postfächer auslesen
    Vielleicht schaffe ich es noch mal, als Datenbank einfach nur "*" angeben zu können und dann alle Datenbanken sequentiell abzuarbeiten. Aktuell hole ich mir die Postfächer als Admin ja per PowerShell und Transporter Suite und erstelle mit ein Batch, welches dann FixNotesItems aufruft.

PowerShell

Ich habe Natürlich auch versucht, das ganze als "PowerShell" Skript zu machen. Aber anscheinend ist auch hier wieder das gleiche COM-Problem, wie mit CDO (MTATHREAD). Folgende Zeilen funktionieren daher nur bis zur Verbindung der Datenbank:

Powershell mit Notes COM

$nsession = new-object -com "Notes.NotesSession"
$nsession.initialize

$db=$nsession.GetDatabase("","c:\notes\adminmail.nsf")

Bei der Datenbank kommt dann die lapidare Meldung, dass die Methode "GetDatabase" nicht verfügbar ist.

Weitere Links