Migrationsphasen

Jede Migration ist individuell und es hängt immer in der aktuellen Quell und ZielUmgebung ab, wie der genaue Weg aussieht. Die Einrichtung eines Parallelbetrieb mehrerer Exchange Organisationen mit einem Abgleich von Benutzerdaten, Kontakten etc. ist nicht zu berücksichtigen. Die Migration der Quelle erfolgt in einem Stück, z.B. An einem Abend oder Wochenende. für die Migration sind entsprechende Kenntnisse in den Bereichen Active Directory, WINS, DNS, Trusts, SID, SIDHistory, Exchange, SMTP-Routing etc. erforderlich
Dies ist kein "How-To" mit dem Anspruch auf Vollständigkeit.

Die Migration und Konsolidierung zweier Firmen erfolgt meist in Phasen:

  • Koexistenz und Zusammenarbeit
    Die meisten Firmen versuchen zuerst einmal eine lockere Kopplung der Umgebungen durch VPN und Trusts, damit die Anwender mit ihrem bestehenden Account nun auch andere Ressourcen erreichen können. Zudem werden Mails sehr schnell durch interne Verbindungen zwischen den vormals getrennten Firmen ausgetauscht. Manchmal werden auch schon Kontakte für Postfächer eingerichtet. Voraussetzung ist aber, dass die Verbindung der Firmen kein Risiko bedeutet. Schließlich könnten sehr unterschiedliche Sicherheitsrichtlinien vorzufinden sein.
  • Vorbereitung
    Ehe an eine Zusammenführung gedacht wird, sind entsprechende Vorarbeiten zu leisten.
  • Windows Konsolidierung
    Es ist nicht zwingend erforderlich, aber es kann ratsam sein, zuerst die Infrastrukturen bezüglich Windows und Active Directory zu konsolidieren. Dann gibt es im Ziel schon den "richtigen User", der später auch ein Postfach bekommt
  • Messaging Migration
    Es ist gar nicht immer Exchange, auch Migrationen von Notes oder GroupWiseetc. können vergleichbar betrachtet werden. Die Inhalte und Dienste sind nun in das Zielsystem zu übertragen.
  • Abbau
    Am Ende steht in der Quelle nur noch eine rudimentäre IT-Struktur mit dem Mailserver, der nicht mehr tut und eventuell ein paar DCs, die auch niemanden mehr authentifizieren.

Schauen wir uns die Phasen mal etwas im Detail an, damit Sie einen Hinweis auf die Komplexität einer solchen Konsolidierung erhalten:

Phase 1: Koexistenz und Zusammenarbeit

  • Abprüfen der Sicherheitsanforderungen
    Sichern der eigenen "Shares, Kennwortrichtlinien, Virenscanner etc
  • Verbinden der LANs per VPN/Firewall
    Wenn beide Standorte die gleichen IP-Adressen nutzen, muss einer wohl oder übel diese ändern. Sie könnten per NAT und Proxies zwar ausgewählte Protokolle umsetzen, aber gerade Trusts und SMB--Zugriffe oder RPC sind schwer möglich.
  • Gegenseitige Namensauflösung
    Wenn Mitarbeiter auf Ressourcen des anderen Standorts oder der Firma zugreifen, dann sollten Sie schon aus eigenem Interesse eine funktionierende Namensauflösung bereit stellen. Die Pflege von IP-Adressen in Verbindung ist möglich aber unterbindet z.B. die Nutzung von SSL-Zertifikaten, welche einen "Namen" brauchen. Sie müssen ja nicht alle Adressen transparent durchgeben. Es kann auch reichen auf der jeweils anderen Seite eine Rumpf-DNS-Zone mit den relevanten Systemen anzulegen und die Server als statische WINS-Einträge zu ergänzen
  • Optional "Trust" und ACLs über Gruppen vergeben
    Damit für den gegenseitigen Zugriff keine zusätzlichen Anmeldekonten (mit Kennwort etc.) erforderlich sind, sollten Sie auch hier aus eigenem Interesse eine "Ein Benutzer = ein Konto"-Strategie fahren. Dazu gehört natürlich die Einrichtung eines Trusts oder anderen Kniffen, damit die Anmeldekonten des anderen Standorts verwendet werden können. Berechtigungen sollten anhand von Gruppen vergeben werden.
  • Mailempfänger per Verzeichnisabgleich ergänzen
    Steht eine Migration der Mailsystem nicht kurz bevor, sollten Sie einen Verzeichnisabgleich in Betracht ziehen, bei dem die Postfächer, Verteiler etc. des einen System im anderen System als "Kontakte" angelegt werden. Dies erleichtert die Adressierung von Empfängern und konsistente Pflege. Bei wenigen Empfängern und statischen Listen können Sie dies auch per Hand machen. Ratsam ist aber immer ein Skript oder Produkt, welches diesen Abgleich automatisiert und auch Systemfelder setzt die eine spätere Migration erleichtern.
  • Optional PublicFolder und FreeBusy Replikation
    Mit Hilfe der im vorigen Schritt angelegten Kontakte können Sie über ein Replikation der öffentlichen Ordner (Exchange 2000/2003) oder über eine Exchange Federation (Exchange 2007/2010) auch die Terminplanung mit der Anzeige von Frei/Belegt-Zeiten unterstützen.

Wenn die WAN-Verbindung und das IP-Routing steht, sind die weiteren Schritte in der Regel innerhalb weniger Stunden oder Tage umzusetzen. Wer allerdings noch Migrieren und Konsolidieren will, wird sich diesen zusätzlichen temporären Aufwand erst einmal überlegen. Schließlich kann eine gut funktionierende Koexistenz auch Druck von dem Zwang einer schnellen Migration nehmen.

Phase 2: Migration Vorbereitung

  • Aufräumen der Quelle
  • Inventory: Liste der PCs, Server und Dienste
  • Inventory: Connectoren, Faxserver etc
  • Monitoring
    Sofern möglich sollten alle wichtigen Dienste "bekannt" und testbar sein.
  • Aktivierung von Logging
    Das Nachrichtentracking und andere Zugriffsprotokolle sind später wichtige Indikatoren, ob die Systeme wirklich "idle" sind und in der letzten Phase abgeschaltet werden können.
  • Vorbereiten der Active Directory Forests
  • Überprüfung der Infrastruktur, Namensauflösung (DCDIAG, NetDIAG)
  • Einrichten von Vertrauensstellungen
  • Anpassen der Infrastrukturdienste (DHCP, DNS, WINS)
    DNS CNames, Aliasse, LMHOSTS, HOSTS etc
  • Einrichten des Monitoring
    z.B. Eventlog, Überprüfen der Funktionslevel etc
  • Installation ADMT und MailMig
    Eventuell Testmigrationen

Phase 3: Migration Active Directory

Das präferierte bordeigene Hilfsmittel ist natürlich ADMT (Active Directory Migration Toolkit). Es gibt zwar Dritthersteller, die ihnen Arbeit sparen können, weil einige Prozesse und Sonverfälle betrachtet werden, aber ADMT ist durchaus ein sehr geeignetes Hilfsmittel

  • Gruppenmigration
  • Benutzerkontenmigration mit Gruppenmitgliedschaften
  • Dienstkontenmigration
  • Computerkontenmigration
  • Passwort-Migration (PWDMIG)
  • SID History

Phase 4: Mail Migration

Je nach Quelle und Ziel kommen unterschiedliche Programme zum Einsatz. Das kann das Exchange 2003 eigene MailMig sein oder die Exchange 2007/2010 Commandlets. Beide Tools haben aber das Ziel, eine "statische Mailbox" der Quelle in das Ziel zu übertragen. Exchange 2010 kann nach der Migration aus dem Quellpostfach sogar einen Kontakt machen. Dritthersteller erlauben aber z.B. eine Replikation von Postfachinhalten, so dass für die Migration ein erweitertes Zeitfenster zur Verfügung steht. Hier ist eine individuelle Beratung empfehlenswert. Insbesondere wenn die Datenmenge oder Verteilung eine "Stichtags-Migration" nicht zulassen.

Migration der Postfächer

  • Offline Benutzer sollen noch einmal "Synchronisieren"
    So wird sichergestellt, dass Mails versendet werden.
  • Clientzugriff unterbinden
    Stellen Sie sicher, dass sich nun niemand mehr mit dem Server verbinden kann, z.B. Firewall zu machen, Konten in der Quelle deaktivieren etc.
  • Eingehenden Verbindungen stoppen
    Es wäre sehr ungeschickt, wenn nach der Migration noch neue Nachrichten in die Quelle kommen. Diese würden dann nicht mehr mit migriert werden. Das gilt nicht nur für SMTP, sondern auch für FAX-Connectoren etc.
  • Ausgehende Warteschlange leeren
    Sorgen Sie dann dafür, dass alle Mails in Warteschlangen übertragen werden.

FROZEN STATE
Nun ist der Server in einem Status, bei dem sich nichts mehr bewegt oder ändert. Die Migration kann beginnen

  • MailMig - Migration von Postfächern
    Die Postfächer können nun alle mit dem Exchange Migration Wizard von einer Organisation in die Zielorganisation migriert werden. Wenn die Benutzer vorher mit ADMT migriert wurden, dann ordnet MailMig diese sogar wieder zu. Ansonsten werden eben Benutzer angelegt.
    Siehe auch MailMig für Exchange
  • Migration öffentliche Ordner
    Diese Inhalte müssen Sie "Leider" über Outlook und PST-Datei migrieren. Es gibt meines Wissens kein anderes Programm. Natürlich könnten Sie eine Replikation der Order mittels IOREPL - InterOrg Replication Tool herstellen, aber das ist sicher zu aufwändig.
  • Abschalten des alten Server
    Sie sollten den alten Exchange Server vielleicht noch nicht sofort neu installieren, aber beenden Sie die Dienste, damit niemand mehr auf der Quelle arbeitet.
  • Anpassen Empfängerrichtlinien
    Sorgen Sie im Ziel dafür, dass die Exchange Organisation auch die Mails für diese neuen Empfänger und deren SMTP-Domänen annimmt
  • SMTP-Routing umstellen
    Nun sollten Sie auch noch dafür sorgen, dass die Mails an die bisherige Organisation auch wirklich an die neue Organisation zugestellt werden. Hier geht es um Themen wie MX-Record und Firewall.

Denken Sie bei dieser Migration auch an den Zielserver. Große Datenmengen blähen die Transaktionsprotokolle auf. Denken Sie auch an Datensicherung, Virenschutz, Überwachung etc

Eventuell Zwei-Schritt Migration wenn der gleiche Server in der neuen Domäne eingesetzt werden soll.

Clientaufgaben

Nach der Migration kommt natürlich die Arbeit auf den Workstations.

  • Outlook Profilanpassung
    Das MAPI-Profil funktioniert nach der Migration mit MailMig nicht mehr und muss angepasst oder neu angelegt werden. Das betrifft natürlich auch alle im Profil hinterlegten Einstellungen (zusätzliche POP3-Konten, Verschlüsselung, Kategorien, Outlook Heute, etc. Anpassungen sind mit Profgen oder ExProfRe möglich. Siehe auch Profile Tools
  • Windows Anmeldung:
    z.B.: per Gruppenrichtlinie die Default Domäne vorgeben
  • Windows Profile, Übernehmen oder Neuanlegen
  • Gruppenrichtlinien ?
  • Softwareverteilung
  • Serviceeinstellungen
    z. B Dienstkonten in IN-Dateien und anderen Konfigurationen
  • Funktionstests

Phase 4: Auflösen der Quelle

  • Kontrolle der verbliebenen Zugriffe
  • Auflösen der Trusts
  • Bereinigen der Namensauflösung
  • Deaktivierung/Deinstallation

Probleme

  • Notebooks
    Diese sind meist nicht "online" und können per ADMT vermutlich erst nachträglich migriert werden
  • Offline User und OST-Dateien
  • PDAs
  • Dienstkonten und Domäne
  • Seriennummern
  • Nicht alle PCs eingeschaltet
  • Anmeldeskripte
  • Gruppenrichtlinien
  • Exchange 5.5 primäre Konten
  • Anmeldedomäne auf den Workstations auf den neuen Domänennamen setzen liegen
  • Programme, die in der Lizenz den "Domänennamen" haben
  • Programme die Anmeldedaten in einer für ADMT nicht lesbaren Form (INI-Datei, Skript o.ä.) stehen haben

Wenn es nicht nur um die Migration von Daten aus einer Organisation in ein andere Organisation geht, sondern auch langfristig eine Verbindung der Organisation erhalten bleiben soll, dann sind folgende Seiten noch interessant:

Links