Microsoft Transporter Suite mit Notes

Beachten Sie hierzu auch die Seite TransporterSuite

Die Transportersuite ist für März 2010 abgekündigt, d.h. danach gibt es keine Updates o.ä. mehr. Migrationen von Notes, GroupWise und anderen Quellen sind dann nur noch über Drittprodukte möglich.

Über praktische Erfahrungen mit der Notes Transporter Suite möchte ich auf dieser Seite berichten. Die Migration von Notes nach Exchange ist eine durchaus häufige Migration und Microsoft stellt hierfür auch ein leistungsfähiges Werkzeug zur Verfügung. Die vorherige Version hat sogar IBM in seinen Dokumentationen (http://www.redbooks.ibm.com/abstracts/sg247777.html) beschrieben, um Notes mit Exchange zu verbinden. Um das Thema etwas zu vereinfachen, beschränke ich mir hier auf die eigentliche Migration der Nutzdaten von Notes nach Exchange über die Transporter Suite und behandle nicht die Koexistenz mit Connector und Dirsync. Speziell kleinere Firmen mit einem Notes Server werden eher eine "Ad Hoc"-Migration durchführen wollen, bei der eine neue Exchange Umgebung parallel aufgebaut wird und zum Zeitpunkt X dann einfach alle Inhalte migriert werden.

Eine solche Migration ist mit der Transporter Suite auch sehr einfach möglich, da man immer wieder Daten migrieren kann und Dubletten verhindert werden. Eine Migration könnte daher wie folgt aussehen:

Phase Tätigkeiten
Exchange Aufbau Die neue Exchange Umgebung wird in ein neues oder bestehendes Active Directory integriert. Exchange kann komplett mit Backup, Virenschutz, Monitoring, SMTP-Versand und Empfang konfiguriert werden. Sogar Outlook kann testweise schon installiert werden.
Allerdings können natürlich eingehende Mails noch nicht an Exchange zugestellt werden und die Testbenutzer sollten noch nicht in Outlook ihre Kollegen anschreiben, da diese noch nicht arbeiten.
Transporter Matching Der nächste Schritt ist die Zuordnung der Notes Postfächer zu entsprechenden Active Directory Konten. Hierbei nutzt der Transporter Felder im AD, um die Übereinstimmung selbständig zu ermitteln. Je nach Umgebung muss man hier aber nachhelfen und die Inhalte entsprechend vorbereiten.
Cleanup und Vormigration Da die Übertragungsgeschwindigkeit der Inhalte aufgrund des Prinzips meist nur 1-3 Gigabyte/Stunde schafft, muss man sich überlegen, wie man größere Datenbanken in Kurzer zeit übertragen kann.
Schritt 1 ist natürlich die Datenmenge zu reduzieren. Das kann durch ein Archiv erfolgen (Achtung, dass das hinterher dann noch erreichbar ist) oder durch Export oder Löschen der Anwender.
Bei der Migration selbst kann man sich ebenfalls überlegen, ob man wirklich alle Mails komplett migrieren will oder z.B. "gelöschte Objekte" oder ältere Mails nicht zu migrieren.
Matching Der nächsten Schritt weist für die folgende Datenmigration die Transporter Suite an, welcher Notes-Benutzer zu welchem Active Directory Konto gehört. Dazu nutzt die Transporter Suite den Inhalt des Felds "Proxy Addresses". Sie können diese Adressen vorab entsprechend hinterlegen (Exchange aktivieren) oder über die GUI manuell das Konto zuweisen.
Benutzer und Gruppen migrieren

Nachdem die Zuordnung sicher gestellt ist, sollte man zuerst den Benutzer und Gruppen migrieren. Dabei wird allerdings noch kein Inhalt übertragen sondern die ganzen Adressen aus Notes werden als Proxy Adressen in das Ziel übertragen. Das ist wichtig, dass später weiter eine Antwort auf eine frühere Mails mit Notes-Adressen möglich ist. Exchange findet dann den neuen Benutzer dazu.

Eine zweite Aufgabe die die Übertragung der Gruppen und vor allem der Mitgliedschaften. So werden aus Notes Verteilen entsprechen Active Directory Gruppen mit Exchange Verteiler Funktion. Die Transporter Suite kann dabei die Mitglieder aktualisieren, indem es die Mailadressen nutzt.

Kontakte können so allerdings noch nicht übernommen werden. Das trifft auch für Gruppen sie, in denen solche externe Adressen Mitglied sein können. Aber auch hier gibt es mittlerweile Skripte die dies erledigen.

Inhalte migrieren

Bei einer "Ad-Hoc"-Migration kommt irgendwann der Zeitpunkt, zu dem man den Mailfluss und alle Clients blockiert, damit das Quellsystem zur Ruhe kommt.

Dann ist es an der Zeit im Backend die Daten zu migrieren. Hier kann man aber optimieren. So könnte man schon mal z.B.: eine Woche zuvor die älteren Objekte migrieren, so dass am Tag X nur noch wenige Objekte übertragen werden müssen.

Alternativ könnte man eben am Tag X nur die Objekte der letzten Wochen migrieren und den Rest nachholen. Ich migriere aber lieber den Großteil davor, weil das Zielsystem damit schon belastet ist, das Backup und der Virenscanner schon ihre Funktion zeigen konnten und der Aufwand dann klar ist. Nur den Anwendern könnte auffallen, dass eine danach gelöschte Mail im Ziel doch wieder vorhanden ist und verschobene Mails dann doppelt sind.

Über die Datei "c:\Program Files\Microsoft Transporter Tools\Config\FolderMap.xml" kann man z.B. "Deleted Items" und andere Ordner von der Migration ausschließen.

Prüfen und Umschalten Alles migriert und die Funktion geprüft ?, dann ist es an der Zeit die Clients wieder auf das System zu lassen und nun das eingehende Routing von Nachrichten auf das neue System umzustellen. Zur Sicherheit sollten Sie den alten Server einige Tage offline nehmen oder zuverlässig blockieren.

Diese Schritte sind natürlich nur eine große Zusammenfassung. Eine vollständige Aufnahme der Clients und deren Nutzung ist natürlich erforderlich um z.B. Kopierer, Drucker oder andere SMTP-Sender zu entdecken. Auch gibt es oft CRM und Buchhaltungssysteme, die ebenfalls Mails abholen.

Unterstützung durch Net at Work:
Dies soll nur eine kurze Abhandlung sein, weil die Microsoft Whitepapers und Onlinehilfen schon recht gut sind. Was ihnen aber niemand abnehmen kann ist das Verständnis beider Welten. Sie müssen dem Notes Admin zumindest erklären können, was Sie für die Migration benötigen (Benutzer, Client, Rechte etc.)

Debugging

In den seltensten Fällen starten die sie MMC und drücken auf "Migrieren" und alles funktioniert alleine. Man kann an einigen Stellen dem Migrationsprozess schon genau auf die Finger schauen:

Hingegen enthalten die TBIN-Dateien nur gecachte Informationen und werden nur temporär benötigt.

Einschränkungen und Tools

Auch wenn die Transporter Suite sehr viele Inhalte aus Notes mit übernehmen kann, so gibt es viele Quelldaten, die nicht korrekt übertragen werden.

Mit solchen Einschränkungen kann man sich als Kunde natürlich nicht immer abfinden und ich bin als Dienstleister gefordert. Zum Glück kann man auch an Postfächer von Notes Servern über die COM-API von Notes per VBScript und anderen Programmiersprachen zugreifen. Es ist daher nicht schwer, in allen Postfächern bestimmte Aktionen durchzuführen. Folgende Skripte sind bislang entstanden:

# Aufruf aus der Exchangevon der Transporter shell wegen get-dominomailbox
$mailboxes = Get-mailbox
foreach ($m in $mailboxes) {
  write-host migrate-pab User: $m.Samaccountname Mailaddress: $m.PrimarySmtpAddress
  [string]$nsfpath = "\\srv01\userhome\"+$m.Samaccountname+"\Notes\Data\names.nsf"
  write-verbose $nsfpath
  write-host Copy $nsfpath to $targetpath
  Move-NotesPABToExchange -SourceFileName $nsfpath -ContentOwner $m.PrimarySmtpAddress -DominoMailDomain msxfaq.de
}

Notes Tools
Die Skripte sind bei Kunden entstanden und sind kein fertiges Produkte oder Programm, sondern eine Sourcecode-Sammlung, die im Kundenauftrag angepasst sind. Sie finden diese daher nicht unter Tools zum Download. Sie werden im Rahmen eines Auftrags für Kunden bereitgestellt.

Allerdings habe auch ich kein Skript, welches verschlüsselte Mails vor der Migration entschlüsselt, wenn der passende Key nicht vorhanden ist. Allerdings könnte man zumindest einen Report erstellen, welche Postfächer verschlüsselte Nachrichten enthalten. Ich bin mal gespannt, welche Inhalte noch so alles mich in der Zukunft erwarten.

Demos und Videos

Weitere Links

Keywords:Migration Notes IMAP4 TransporterSuite