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:
- Koexistent 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 Groupwise etc. 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
- Abpü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 EXCHSYNC - 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
- ADMT V2.0 (5/30/2003) http://www.Microsoft.com/downloads/details.aspx?familyid=788975B1-5849-4707-9817-8C9773C25C6C&displaylang=en
- Domain Migration Cookbook Chapter 9: Migration of a Windows NT 4.0
Account Domain to Active Directory
TechNet Home > Products & Technologies > Server Operating Systems > Windows 2000 Server > Deploy > Domain Migration Cookbook
http://www.Microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookchp9.mspx
http://www.Microsoft.com/technet/images/prodtechnol/windows2000serv/deploy/cookbook/images/ckch0908_BIG.gif - 322970 How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2
- 322981 How to Troubleshoot Inter-Forest Password Migration with ADMTv2
- 260871 HOW TO: Set Up ADMT for Windows NT 4.0 to Windows 2000 Migration
- Solution Accelerator for Domain Server Consolidation and Migration: Windows NT 4.0 to Windows Server 2003 http://www.Microsoft.com/technet/itsolutions/ucs/ds/dmcnmgsa.mspx
- Solution Accelerator for Domain Server Consolidation and Migration
Guidance
http://go.Microsoft.com/fwlink/?LinkId=24474
