Vergleich der Exchange Migrationen "SameOrg" und "NewOrg"
Diese Seite stellt kurz die wichtigsten Kriterien für die Wahl einer Migrationsart gegenüber. Gerade bei der Migration von Exchange 5.5 nach Exchange 200x ist diese Frage wichtig, da damit große Kosten aber auch Arbeit und im schlimmsten Fall ein Scheitern oder schlechte Ergebnisse verbunden sind.
Migration in der gleichen Organisation
Die Migration der Daten auf einen neuen Server im Parallelbetrieb ist mein persönlicher Favorit. Wir installieren den neuen Server in eine bestehende Organisation und verschieben die User auf den neuen Server um am Ende den alten Server zu deinstallieren.
Die Vorteile
Wenn alles glatt geht, dann können Sie von folgenden Vorteilen profitieren:
- Keine oder minimale Ausfallzeit (im optimalen Fall)
- Kein Update/Upgrade von NT4 auf Windows 2000 und Exchange 5.5. auf Exchange 2000
- Testzeit des neuen Servers im Bezug auf Backup, Virenscanner, Festigkeit gegen Relaismissbrauch und auch eigene Administrationsfähigkeiten ist möglich ohne den Produktivbetrieb zu gefährden (mit einigen Ausnahmen wegen dem ADC)
- Profile auf dem Client werden automatisch geändert.
- Langsame Migration einzelner Postfächer und Kontrolle der Funktion möglich.
- Betrachtungen im Bezug auf Lastverhalten möglich
- Installation entsprechender Zusatzsoftware (Archivierung, Virenschutz etc.)
- Alter Server kann als Sicherheit (Fallback) und für den Betrieb von Connectoren bestehen bleiben
Die Nachteile und Risiken
Was nicht verschwiegen werden sollte:
- Diese Migration funktioniert NICHT mit den SBS Versionen von Windows NT4.0 und Exchange 5.5, da die Windows NT 4-Server keine Trusts einrichten können und die Exchange 5.5. Server keine weiteren Server im gleichen Standort unterstützen.
In solch einem Fall bleibt ihnen nur die Migration in einen neuen Forest und Organisation mittels ADMT und dem Exchange Migration Wizard. Siehe dazu auch Exchange 200x - Update per Neuinstallation - Ich brauche extra Hardware für den neuen Server. Wenn ihr Exchange aber schon in die Jahre gekommen ist, dann werden Sie dies sowieso ins Auge gefasst haben
- Die Umstellung szeit kann sich über mehrere Wochen hinziehen. Zwar stören Sie die Clients damit nicht, aber ehe nicht alle Clients einmal ihr Profil aktualisiert haben, können Sie den alten Server noch nicht entfernen
- Die Migration in größeren Umfeldern mit mehreren Standorten ist nicht als einfach zu bezeichnen, aber in solchen Umfeldern sind die anderen Migrationspfade auch nicht gerade in wenigen Minuten zu schaffen.
Bewertung
Kurzum, diese Umstellung svariante ist mir am angenehmsten, da Sie die geringste Störung der Anwender bedeutet und jederzeit ein Stopp möglich ist. Allerdings ist die Planung besonders in größeren Umfeldern keineswegs trivial.
Migration in eine neue Organisation
Neben der SameOrg Migration können Sie natürlich auch migrieren, indem Sie eine Organisation aufbauen und die Daten der bisherigen Organisation übernehmen.
Die Vorteile
Wenn alles glatt geht, dann können Sie von folgenden Vorteilen profitieren:
- Sie können komplett neu anfangen und bisherige Fehler vermeiden
- Ein gangbarer Weg, wenn Sie den Namen der Organisation ändern wollen oder müssen
- Sie können den Server umbauen, neu partitionieren etc.
- Sie entfernen alte Produktleichen eines jahrelangen Betriebs und
Testinstallation
(na na na wer macht denn so etwas auf einem Produktivserver :-)
Die Nachteile und Risiken
Was nicht verschwiegen werden sollte:
- Viel Arbeit, Hoher Konfigurationsaufwand, hohe Fehleranfälligkeit, Lange Pausenzeit
- Profile auf den Clients müssen samt OST-Datei neu gemacht werden
- Kennworte dürften sich ändern
- Rechte auf Ordner sind neu einzurichten.
- Sehr lange Ausfallzeit
- Hohes Risiko "vergessener" Einträge: Im Laufe eines Serverbetriebs werden viele Änderungen an der Konfiguration durchgeführt. Das bedeutet aber nicht, dass diese auch immer dokumentiert sind und die lückenlose Nachdokumentation eines bestehenden Servers ist nahezu unmöglich. Insofern werden einige Dinge "danach" nicht mehr funktionieren.
- Sichern sie ihre PST-Dateien doppelt und auf einen anderen Server, nicht dass beim FDISK oder der Neuinstallation diese mit verloren gehen.
- Und einiges mehr
Bewertung
Also wer sich wirklich an diese Version des Update heranmacht, der muss schon einen langen Leidensweg hinter sich haben, z.B.: weil beide anderen Updates, warum auch immer, fehlgeschlagen sind, die Datenbank so korrupt ist (warum wohl ?), oder weil Sie wirklich alles neu machen wollen, z.B.: neuer Organisationsname, neue Ordner etc.
Vergleich
Hier finden sie eine kurze Gegenüberstellung der beiden Migrationsarten nach Kategorien:
Infrastruktur
| Kriterium | Gleiche Organisation | Neue Organisation |
|---|---|---|
Know-how |
Höher. Der Parallelbetrieb ist problemlos, wenn auch der Betrieb das ADC in größeren Umgebungen knifflig sein kann. Ideal ist die Hilfe durch Firmen, die Migrationen häufig durchführen und das Wissen für diese einmalige Sondersituation mitbringen. |
Geringer. Der Aufbau der neuen Organisation kann ohne ADC und
Exchange 5.5 Kenntnisse aufgebaut werden. Die Migration der Daten ist bei einem Big-Bang relativ einfach. Knifflig wird es bei der Umstellung der Clients und einem längeren Parallelbetrieb. |
Hardware |
Bestehende Server können über ein "Rolling Update" einfach wieder eingesetzt werden. (Hardwarevoraussetzungen beachten) |
Ideal sind neue Server, so dass die alte Umgebung bis zum Abschluss
der Migration nicht verändert wird. Knifflig werden Dienste wie Faxserver etc., da diese oft nur eine Organisation bedienen können und damit faktisch eine Doppelung erforderlich wäre. |
Zeit |
Kann sich über Monate und Jahre hinziehen, wenn eine schnelle Umstellung z.B.: aus Lizenzkosten oder einfach der Größe nicht möglich ist. |
Sinnvoll nur bei einem "Big-Bang". Ein längerer Parallelbetrieb ist mit vielen Einschränkungen verbunden. Die Migration sollte in kurzer Zeit durchgezogen werden. |
Problembehandlung und Rückgängig machen |
Nahezu jeder einzelne Schritt kann relativ einfach rückgängig gemacht werden. Die Migration kann auch einfach "pausiert" werden. |
Die Migration kann "vorher" bei einer Big-Bang-Umstellung geprobt werden. Werden aber schon Benutzer im Ziel genutzt, ist der Weg zurück sehr steinig. Das Ziel muss in allen Bereichen funktionieren. |
DirSync und Connectoren
Wenn die Umstellung nicht als "Big Bang" erfolgt, werden alt und neu nebeneinander existieren müssen. Die Informationen über Empfänger müssen entsprechend abgeglichen werden.
| Kriterium | Gleiche Organisation | Neue Organisation |
|---|---|---|
Abgleich der Empfänger |
Abgleich per ADC |
Abgleich mit zusätzlichen Programmen, z.B.: MIIS oder eigenen Skripten |
Mitgliedschaften in Verteilern |
Abgleich per ADC |
Manuell zu pflegen/übernehmen. Gerade wenn Verteiler in der Quelle außerhalb ihres administrativen Einfluss stehen, muss der andere Admin die Pflege durchführen. |
Eingehendes Routing während der Koexistenz |
Problemlos |
Knifflig Denkbar ist das löschen der Postfächer in der Quelle und neue Kontakte. (Siehe dazu auch ADC Interorg) Alternativ könnte ein versteckter Kontakt in der Quelle als Weiterleitungsadresse für das Postfach eingetragen werden. Das würde die Verteiler erhalten aber Stellvertreter würden nicht merken, dass das Postfach gar nicht mehr aktiv genutzt wird. |
Postfächer und Client
| Kriterium | Gleiche Organisation | Neue Organisation |
|---|---|---|
Migration der Postfachinhalte |
Einfaches Verschieben mit der MMC für Benutzer und Computer |
Export aus dem Quellsystem und Import im Zielsystem. Quellpostfach sollte dann gelöscht/weitergeleitet werden. |
Outlook Client |
Wird beim ersten Start automatisch angepasst |
Profil muss neu angelegt oder angepasst werden. Siehe Profile Tools |
OST-Dateien |
Bleiben gültig und erhalten |
Werden ungültig. Komplette Neusynchronisation |
Stellvertreter |
bleiben erhalten und nutzbar |
Neu einrichten und nur begrenzt über die Grenzen der Organisation verwendbar |
Lokale PST-Datei |
bleibt gültig |
bleibt gültig |
Stellvertreter |
wird übernommen und |
Muss durch den Anwender neu eingerichtet werden |
Regeln |
Werden migriert und funktionieren überwiegend weiter |
Anwender muss Regeln neu einrichten oder vorher selbst exportieren/importieren. Regeln mit Ziel auf Objekte der GAL müssen meist durch den Anwender angepasst werden |
ActiveSync |
funktioniert weiter bzw. war bei Exchange 5.5 nicht möglich und muss dann neu eingerichtet werden. |
Muss auf jeden Fall neu eingerichtet werden. |
POP3/IMAP4 |
Eingeschränkt. User muss entweder IP-Adresse/Hostname ändern oder alle User eines Servers werden als Block migriert und die IP-Adresse/Name umgestellt. |
User muss Konfiguration neu erstellen, außer bei einer "Big-Bang"-Umstellung. |
öffentlichen Ordner
| Kriterium | Gleiche Organisation | Neue Organisation |
|---|---|---|
Inhalte |
Migration per Replikation auf neuen Servern. |
Export und Import über PST-Dateien. |
Berechtigungen |
Werden konvertiert und bleiben erhalten |
Manuell wieder einzutragen, z.B. mit PFDavAdmin oder PFinfo/PFAdmin |
Ansichten |
Bleiben erhalten |
Müssen beim Import berücksichtigt werden |
Replikate |
Während der Migration anzupassen, z.B.: mit PFMigrate |
Neu einzurichten |
Grenzwerte |
Bleiben erhalten |
Neu einzurichten |
Mailadressen |
Bleiben erhalten |
Neu einzurichten bzw. MailMig übernimmt Adressen |
Verfügbarkeit/Erreichbarkeit
| Kriterium | Gleiche Organisation | Neue Organisation |
|---|---|---|
Verfügbarkeit |
Hoch, da nur das jeweils zu migrierende Postfach kurz nicht erreichbar ist |
Geringer, da bei der Migration |
Konsistenz |
Hoch |
Geringer, da z.B.: öffentlicher Ordner und "Frei/Belegt-zeiten) zwischen zwei Organisationen nicht oder nur verzögert abgeglichen werden können. |
User Impact |
Niedrig, die meisten Benutzer werden die Migration nicht bemerken bzw. maximal eine vielleicht neue Outlook Version und verbessertes OWA erkennen. |
Höher, da in der neuen Organisation alles neu ist, d.h. auch Adressbücher, öffentliche Ordner Strukturen etc. Und bei der Koexistenz mit Kontakten und eingeschränkten Stellvertretern gearbeitet werden muss. |
