Migration mit Schattenpostfach

Zu dieser Seite ist TargetAddress und Add-Targetmailbox thematisch verwandt.

Diese Migrationsart ist keine offizielle Migration und nur für besondere Fälle geeignet.
Im Zweifel sollen Sie eine Beratung und Analyse ihrer individuellen Anforderungen vorsehen.

Von Microsoft gibt es eine ganze Menge Tools und Werkzeuge, um von den größeren Wettbewerbern auf Exchange zu migrieren. Aber was machen all die Firmen, die von kleinen unscheinbaren Mailservern nach Exchange migrieren wollen, aber keine Tools zur Migration finden? Viele der früher eingesetzten Systeme unterstützen ja nicht mal IMAP4 als Importquelle.

Wer eine Konsolidierung mehrere Exchange Organisation plant, kann zwar sehr wohl über Kontakte eine Koexistenz (Siehe Verbinden von Organisationen und Verzeichnisabgleich) erreichen, aber erschwert sich später den Weg der Migration, da die Kontakte gelöscht und neue Postfächer angelegt werden müssen. Gruppenmitgliedschaften gehen so schnell verloren. Auch in so einem Fall kann es ratsam sein, in der Zielorganisation keine Kontakte sondern gleiche Postfächer mit einer Weiterleitung (siehe. TargetAddress) anzulegen.

Und selbst wenn man ein Werkzeug gefunden hat, um die Daten aus der alten Anwendung nach Exchange zu übertragen, dann stellt sich immer noch die Frage, ob die Datenmenge wirklich an einem Wochenende übertragen werden kann, oder doch eine Koexistenz eingeplant werden muss. Das führt uns zu zwei Problemen.

• Datenmenge
  Wenn man keine Koexistenz vorsieht, dann werden die meisten Firmen wohl die Alt-Daten komplett übernehmen wollen. Hier gibt es einen Flaschenhals "MAPI" zu beachten. Selbst bei einer Migration von Notes nach Exchange oder Exchange nach Exchange sind Werte von 2-6 Gigabyte/Stunde realistisch. Damit kann eine Migration von 100 GB aber schon mal bis zu 50 Stunden dauern. Zuviel, um das alte und neue Mailsystem in der Zeit "offline" zu belassen.
• Adressbuchabgleich und Mailrouting bei Koexistenz
  Bei einer Koexistenz muss man aber für einen Abgleich der Adressbücher und vor allem ein sauberes Mailrouting sorgen. Werden z.B. im Zielsystem schon alle Postfächer angelegt, dann werden bereits migrierte Mitarbeiter ohne Probleme die Postfächer der noch nicht migrierten Benutzer erreichen, nur die Anwender selbst können darauf ja noch nicht zugreifen (von einem Notbetrieb per OWA mal abgesehen).

Also muss ein Weg gefunden werden, wie man z.B. Inhalt schon migriert, ohne dass die Benutzer schon aktiv sind und wie man Mail an bereits angelegte Postfächer noch in das Altsystem bringen kann. Einige kommerzielle Produkte wie Quest Migration Manager, migrieren sogar über einen permanenten Abgleich, aber das ist eher für ganz große Firmen von Bedeutung.

Ziel: Kontakt, Postfach und Weiterleitung

Ein Exchange Server kann natürlich nur Daten in ein Postfach importieren, wenn es ein Postfach ist. Bei einer Koexistenz werden in Exchange aber primär MailKontakte oder MailUser angelegt, die natürlich kein Postfach haben. Wenn Sie nun aber statt dessen ein Postfach anlegen, dann können Sie dieses als Migrationsziel auswählen.

Allerdings werden dann auch Mails, die ja schon früh durch die neue Exchange Struktur geleitet werden, in das gleiche Postfach abgelegt und der Benutzer bekommt diese nicht mehr zu Gesicht, bis er auch umgestellt ist. Ein einem "Rollback" der Migration mit einem leeren der Datenbank sollten sie dann komplett absehen.

Aber Exchange wäre nicht Exchange, wenn es hierzu keine Lösung gibt. Wie bereits auf Weiterleitungen beschrieben, können Sie bei jedem Postfach eine Weiterleitung auf einen Kontakt eintragen, der dann wiederrum auf das Altsystem verweist, zudem Exchange die Mails per SMTP mit dem passenden Connector zustellen kann. Allerdings möchte ich nicht für jedes Postfach noch einen Platzhalterkontakt anlegen, der ebenfalls in der Adressliste erscheint. Neben dem Pflegeaufwand verwirrt es spätestens die migrierten Benutzer. Exchange kennt aber einen anderen Weg, der den meisten Administratoren bislang verborgen geblieben ist, da er nicht über die GUI zu erreichen ist.

Es ist völlig normal, dass externe Mailkontakte und MailUser eine Mailadresse konfiguriert haben, die Exchange die Mail weiterleiten lässt. Diese Information im Feld "TargetAddress" kann man sogar per GUI pflegen. Allerdings ist dieses Feld bei einer Mailbox normalerweise leer. Aber auch bei einem MailboxUser kann man dieses Feld per ADSIEDIT oder Skript füllen und damit eine Weiterleitung erreichen. Über diesen Trick kann zur Migration ein Postfach auf dem Zielsystem angelegt und mit Daten gefüllt werden. neue Mails an dieses Postfach werden aber direkt an die angegebene Adresse, die außerhalb der Exchange Organisation liegen muss, weiter geleitet.

Erst zur späteren Migration entfernt man einfach diese Targetaddresse, damit die Mails dann wieder "lokal" verbleiben. Daher ist es auch zweckmäßig, bei einer geplanten Migration der Benutzer (z.B. mit ADMT) diese gleich als "Benutzer" anzulegen und nicht erst als Kontakte (Siehe auch Verbinden von Organisationen) Daher könnte eine Migration wie folgt ablaufen.

Das hört sich einfach an, aber ganz so einfach ist es natürlich nicht. Zum einen gibt es Datenmengen, die eine zeitliche Komponente mit einbringen. Auch das Quellformat muss erst mal übertragbar" sein Dann haben Anwender eventuell Kontakte, die nicht nur übertragen, sondern vielleicht auch noch konvertiert werden müssen. Auch die Frage der Weiterleitung vom Quellsystem muss beantwortet werden. Und dann bin ich bisher mit keinem Wort auf die Funktion von persönlichen und unternehmensweiten Verteilern eingegangen.

Mailrouting per SMTP

Ob man nun alle Postfächer auf einen Schlag oder nach und nach umstellt, spielt bei dem Mailrouting erst mal keine Rolle. Das Zielsystem sollte meiner Meinung nach sehr früh auch hier eine "entscheidende" Rolle spielen. Damit ist gemeint, dass eingehende Mails aus dem Internet oder anderen Quellen möglichst vor der Umstellung der ersten Benutzer schon durch das neue System laufen und damit die Mails an bereits migrierte Benutzer direkt in das neue Postfach abgezweigt werden können. Alle anderen Empfänger werden an das alte System weitergeleitet.

1Exchange kann diese Funktion sehr einfach bereit stellen, in dem die genutzten Domains als nicht "autoritativ" eingetragen werden. Damit werden dann alle unbekannten Empfänger an ein nachgeschaltetes System über einen SMTP-Connector und passendem Adressraum weiter gegeben.

Ich würde aber diesen Weg nicht gehen, sondern alle Empfänger in der neuen Umgebung schon anlegen, damit Exchange direkt die Gültigkeit der Adressen prüfen und ablehnen kann (siehe auch RCPTTO und NDR Spamming). Irgendwann müssen Sie sowieso ihr Altsystem abschalten, weil niemand mehr darauf zugreift. Er sagt ihnen denn, dass das alte System die Mails sauber an das neue System weitergeben kann? Zudem sind die Empfänger dann auch direkt im Adressbuch (GAL) zu sehen und zu nutzen.

Hierzu haben Sie dann drei Optionen:

• Mailenabled Kontakt
  Technisch ist es ein "Kontakt" im Active Directory, welcher für Exchange aktiviert wurde und damit auch als Empfänger erscheint. Nachteil dieser Lösung ist, dass man aus einem Kontakt später keinen Benutzer und damit kein Postfach machen kann. Bei der Migration muss man also den Kontakt löschen und dem neuen Benutzer die Exchange Adressen wieder geben. Leider muss man dann auch die Verteiler wieder pflegen. Kontakte sind daher gut, wenn die Empfänger wirklich "extern" sind und nicht migriert werden, z.B. Kunden, Zulieferer, Dienstadressen etc.
• Mailenabled User
  Sollen die Benutzer später auch migriert werden dann ist ein Active Directory Benutzer die bessere Wahl. Eine Option ist die Konfiguration eines Users als Exchange Kontakt. Der Benutzer hat kein Postfach, sondern nur eine Weiterleitungsadresse, die sogar per GUI gepflegt werden kann. Aber auch hier steht dieses Prinzip einer späteren Mailbox eher entgegen, da offiziell keine Konvertierung möglich ist. Dieser Typ eignet sich z.B. für externe Personen, die ihr Postfach anderswo haben aber sich in ihrem LAN anmelden müssen, z.B. Dienstleister.
• Mailbox User
  Bleibt also nur das vollwertige Postfach, welches direkt aktiv sein kann. Allerdings würde Exchange dann jede Mail an diese Adresse sofort lokal zustellen und nicht an das bisherige System weiter leiten. Aber hier kann man mit dem Feld TargetAddress nachhelfen. Auch wenn dies offiziell und zwischen den Zeilen erwähnt wird.

Wenn alle Empfänger in Exchange gepflegt sind, dann muss natürlich auch sichergestellt werden, dass die Mails aus dem alten System auch die später migrierten Postfächer im neuen System erreichen. Der einfachste Weg ist hier, dass Exchange den alten Mailserver als Relay bedient und der alte Mailserver alle Mails nicht mehr selbst in das Internet sendet, sondern an Exchange abliefert.

Damit ist sichergestellt, dass auch hier der neue Server die Arbeit und das Queueing übernimmt. Vor allem kann so schon der Virenscanner aktiv werden und intern Nachrichten bleiben auch intern. Werden bei der Konstellation die Verteiler gleich komplett im neuen System gepflegt, so können auch die alten Anwender diese indirekt nutzen, wenn Sie die Adresse können oder im alten System sowas wie ein Kontakt angelegt werden kann.

Etwas Spaß könnten Sie auch mit der "WINMAIL.DAT" bekommen, wenn Sie Mails an ein Exchange Postfach, welches per TargetAddress weiter geleitet wird senden und das Altsystem kein Outlook oder Outlook Express ist. Selbst das Eintragen des Altsystems als "Remote Domain" mit "TNEF = $False" hilft nicht. Einzig das Setzen von "MapiRecipient = False" bewirkt, dass Mails an dieses Postfach nicht mit einer WINMAIL.DAT-Anlage gesendet werden.

Daten ins Ziel übernehmen

Formate

Bleibt noch die Frage, wie die Inhalte übertragen werden. Eine pauschale Antwort für alle Quellsysteme kann ich hier auch nicht geben. man muss schon genau zuschauen, wie das Quellsystem die Informationen speichert und auch wieder herausrückt. Viele Systeme nutzen Verzeichnisse und einzelne Dateien auf einem Server als Ablage. Andere Server bieten IMAP4 an, so dass man mit Exchange Bordmitteln die Daten extrahieren kann. Auch Dritthersteller liefen teils kostenfrei Konvertierungsprogramme. Hier müssen Sie für ihr aktuelles Produkt einfach mal "schauen"./p>

Ich habe auch schon Migration über temporäre virtuellen Server durchgeführt, weil z.B. Exchange 5.5 noch problemlos Inhalte aus MSMail, cc:Mail, GroupWise 4 oder Notes 5 extrahieren konnte. Die aktuellen Migrationswerkzeuge nehmen auf solche Sitzenbleiber aus verständlichen Gründen keine Rücksicht mehr. Wohl dem, der noch die alten Installationsmedien hat. Alternativ kann man sich überlegen, ob die alten Nachrichten nicht einfach über eine Weiterleitung (Skript, Regel) in das neue Postfach kommen. Die Daten sind dann natürlich nicht mehr "original" aber per Volltextsuche zumindest noch erreichbar.

Datenmenge

Wer keine Koexistenz mit mehreren Tagen oder Wochen Parallelbetrieb vorsieht, muss sich die Datenmenge der Quelle und die Performance der Übernahme genau anschauen. MAPI und Konvertierung benötigen Zeit und 2-6 Gigabyte/Stunde sind Erfahrungswerte. Wenn es möglich ist, kann man mit mehreren Systemen parallel migrieren. Behalten Sie dabei aber die Transaktionsprotokolle des Exchange Server im Auge, dass die Disk nicht gleich voll ist. Ein "Zwischenbackup" oder die temporäre Aktivierung der "Umlaufprotokollierung" kann hier helfen, zumal die Daten in der Quelle immer noch vorhanden sind.

Bei einer "schnellen" Migration ohne Parallelbetrieb kann die Datenmenge künstlich reduziert werden. Dazu gibt es mehrere Wege, um den kritischen Pfad, zu dem beide Systeme für Anwender nicht nutzbar sind, zu reduzieren:

• Archivierung
  Ein Weg ist die Archivierung der Daten vor einem bestimmten Stichtag. Vielleicht planen Sie ja sowieso eine Archivlösung und es könnte daher durchaus sein, dass ihr Hersteller ein entsprechendes "Import-Modul" bereitstellen kann.
• Vorabmigration
  Ich habe bei Kunden schon den Weg gewählt, Mails älter als einen bestimmten Stichtag vorab zu migrieren. Bei diesen alten Elementen ist die Wahrscheinlichkeit gering, dass sich noch etwas "ändert", so dass diese quasi als "ReadOnly" angesehen werden können. In der Heißen Phase müssen dann nur noch die Objekte der Zwischenzeit übertragen werden. Nebenbei hat das Zielsystem vorher schon die Last abbekommen und konnte zeigen, dass alle Komponenten funktionieren. (Backup, Antivirus, Storage, Volltextindex). Auch fallen hier schon Fehler bei der Übernahme auf. Und wenn etwas "falsch" gelaufen ist, dann ist die Datenbank schnell wieder gelöscht und der nächste Versuch kann starten
• Nachmigration
  Alternativ können Sie in der umschaltzeit nur die Mail der z.B. letzten 4 Wochen und alle Kontakte und Termine übertragen und nach der umschaltung dann die alten Mails "nachziehen". Das ist aber die schlechtere Wahl.
• Ignorierung
  Rein theoretisch könnten Sie natürlich die Existenz des alten System leugnen und einfach auf der grünen Wiese anfangen. Einige Firmen sind den Weg sogar gegangen und haben das Altsystem mit einem Server und einem Client weiter existieren lassen, um über das Altsystem noch den Zugriff auf alte Mails zu haben. Abgesehen von den rechtlichen Aspekten ist dieser Weg nur für Firmen gangbar, die bisher quasi kein Mailsystem produktiv genutzt haben. Auch das Aufrechterhalten des alten Servers produziert Kosten.

Gerade die "Vormigration" ist eine interessante Funktion, auch große Datenbestände auf einen Schlag zu übertragen und die Koexistenz und eine lange Projektlaufzeit zu vermeiden. Entsprechende Referenzen sind vorhanden. Dieser Weg funktioniert sogar von Notes nach Exchange 2007 mit der Transporter Suite.

Stichpunkte der Migration

Eine komplette Migration kann ich hier natürlich nicht in der Kürze beschreiben. Aber die wesentlichen Stichpunkte sollen Sie auf dem richtigen Pfad halten.

Einschränkungen

Wo Licht ist, ist auch Schatten . Und ein paar Dinge kann ich schon jetzt beschreiben.

• Alte Daten
  Bei der Koexistenz kann es sein, dass Mitarbeiter des neuen Systems schon die "Frei/Belegt-Zeiten" der noch nicht migrierten Postfächer sehen wollen und natürlich nichts oder veraltete Informationen finden. Schließlich arbeiten die anderen Benutzer noch nicht aktiv mit ihrem Postfach
• Wiederauferstandene Elemente
  Werden die Inhalte über mehrere Stufen migriert, so kann es schon sein, dass Inhalte von der Quelle zum Ziel kopiert wurden und der Mitarbeiter in der Quelle das Element löscht. Der Löschbefehl wird natürlich bei der Migration nicht mit repliziert. Der Anwender sieht dann eben die Mails wieder, die er bereits gelöscht hat. Diesen Effekt können Sie reduzieren, indem Sie eben nicht ganz so weit an "Heute" bei der Vormigration gehen oder eine "Frozen Zone" benennen, in der die Mitarbeiter nichts löschen sollten.
• Doppelte Elemente
  Wenn das Quellsystem eine Ordnerstruktur wie Outlook erlaubt, können Mitarbeiter ja bereits durch die Vormigration "kopierte" Elemente in einen anderen Ordner verschieben. Bei der Finalmigration kommt es drauf an, ob das verschobene Element in der Quelle als "neu" nochmal migriert wird und damit doppelt ist oder eben nicht migriert wird und im Ziel das Objekt wieder am alten Platz erscheint.
• Stellvertreter
  Speziell bei der Koexistenz kann es passieren, dass im Altsystem noch nicht migrierte Benutzer in das tote Postfach bereits migrierter Anwender zugreifen können und z.B. als Stellvertreter Termine bearbeiten. Solche "Teams" sollten Sie in Gruppen migrieren oder deutlich Aufklären.
• Sonstiges
  Abhängig von der Quelle sind noch weitere Besonderheiten zu beachten.

Perfekt wäre natürlich nun noch ein Programm, welches die Inhalte von zwei Postfächern synchronisieren oder differenziell kopieren könnte. Dann könnte man die neue Umgebung komplett als SchattenUmgebung betreiben. Solche Migrationswerkzeuge gibt es aber von Drittherstellern./p>

Es gibt sicher noch weitere "Unstimmigkeiten". Vorab testen oder eben einen Fachbetrieb hinzuziehen, ist sicher ein guter Ratschlag.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

Weitere Links

• Migration und Koexistenz
• MailMig
• ADMT
• Verbinden von Organisationen
• TargetAddress
• Add-Targetmailbox
• Weiterleitungen