EXO Bordmittel zur Migration

Natürlich möchte Microsoft, dass möglichst viele Kunden einfach und schnell zu Exchange Online umziehen. Aber verschiedene Quellen, Anzahl der Postfächer und Zielkonfigurationen erfordern individuelle Tools. Diese Seite beschreibt die Unterschiede von Cutover, Staging, Hybrid. Die komplette Steuerung erfolgt über die Cloud und wird im Exchange Admin Center angestoßen. Natürlich kann dies auch per PowerShell erfolgen:

Damit stellt sie die Frage, welche Migration für welche Umgebung passende ist. Alle Migrationen von Microsoft basieren auf einer "Synchronisation", d.h. die Verlagerung der Daten ist kein einmaliger "XCOPY". Die Unterschiede liegen in der Verwaltung der Postfächer im Ziel. Und hier gibt es eine Migration in ein bestehendes Postfach nur in Verbindung mit IMAP4. Alle anderen Optionen legen selbst ein Postfach an und können nicht in ein bestehendes Postfach migrieren.

Verfahren Max User Quelle Provisioning Ablauf Anmerkung

Cutover (CEM)

<2000

Ex2003
Ex2007
Ex2010
Ex2013
Ex2016
Ex2019

ADSync muss deaktiviert sein!!

Die Migration nach Exchange Online mittels Cutover basiert darauf, dass die Cloud sich die Inhalte der lokalen Postfächer über RPC/HTTP, also analog zu Outlook, aus der Quelle ins Ziel kopiert. Dabei muss es im Ziel zwar die Benutzer geben aber sie dürfen noch kein Postfach haben. Da Cutover die Postfächer anlegt, darf kein ADSync aktiv sein. Sobald alle Postfächer in der Cloud angelegt wurden, sollten Sie das Mailrouting ins Ziel umstellen, damit in der Quelle nichts mehr ankommt. Wenn alle Mails aus der Quelle kopiert wurden, löschen Sie den Migrationsjob und die Quelle. Die Migration passiert in der Regel in wenigen Tagen und betrifft alle Benutzer.

  1. Migration legt Postfach an
    LegacyExchangeDN kommt mit!
    Neue Kennworte werden angelegt
  2. Sync des Postfach über RPC/HTTP alle 24h
  3. MX Record umstellen
  4. User lizenzieren und Clients umstellen
  5. Finaler Sync
  6. Altsystem abschalten bzw. Umleitung aktivieren.

Ob ihr Tenant eine Cutover-Migration unterstützt, können Sie per Exchange Online PowerShell ermitteln:

PS C:\>(Get-MigrationConfig).SupportsCutover
False

Meist ist ein aktivierter DirSync für die Blockade zuständig.
  • Ordner und Mails
  • Regeln; Kategorien; OOF
  • Termine, Kontakte, Tasks
  • Delegates
  • max. 25MB/Mail
  • Kein Dumpster
  • Kein SendAs
  • Keine Dynamische DLs
  • Keine Sicherheitsgruppen
  • Keine UM-Mailboxen
  • OST wird neu generiert
  • Keine Public Folder
  • Es bleiben keine Postfächer On-Prem

Staged (SEM)

1000 pro Batch

Ex2003
Ex2007

DirSync legt Anwender an

Wenn mehr als 2000 Postfächer migriert werden sollen und die Cutover-Migration nicht praktikabel ist kann die Staging- Migration genutzt werden. Dabei darf ADSync im Ziel schon die Benutzer anlegen und die Migration per RPC/HTTP aktiviert die Benutzer zum Postfach. Nach der Migration müssen sie selbst in der Quelle aus den Postfächern dann MailUser mit Weiterleitung zur Cloud machen. Der MX-Record wird erst am Ende umgestellt. Elegant finde ich das nicht und habe ich selbst nie genutzt.

  1. DirSync legt MailUser oder Mailbox an
  2. MX Record mit Routing via "mail.onmicrosoft.com"
  3. Einmaliger Sync des Postfach über RPC/HTTP
  4. User lizenzieren und Clients umstellen
  5. MX Record umstellen
  6. Finaler Sync
  7. Altsystem abschalten bzw. Umleitung aktivieren.
  • Siehe CEM
  • Kein Ex2010
  • Kein Ex2013
  • Mailrouting
  • kein F/B

Hybrid

kein Limit

Exchange 2010
Exchange 2013
Exchange 2016

DirSync managed User

Das ist die klassische "Hybrid-Migration", der auch in beide Richtungen und sogar zwischen Tenants funktioniert. Der Migrationsdienst legt ein Postfach im Ziel an, um die Inhalte zu replizieren und am Ende wird aus der Quelle ein MailUser und im Ziel ein Mailboxuser.

  1. DirSync legt MailUser an
  2. Hybridmode mit SMTP-Connector und CAS Proxy
  3. User lizenzieren
  4. "Remote Move" je Mailbox mit Sync und Switch
  5. Clients umstellen (Autodiscover)
  6. MX Record jederzeit umstellbar
  7. Altsystem abbauen
  • Beste Koexistenz
  • Lange Koexistenz
  • Kein Exchange 2003
  • Einschränkung bei Delegate
  • Keine Public Folder

Cross Tenant

 

EXO

Admin/PowerShell

Die Cross Tenant Migration ist ein Sonderfall der Hybrid Migration. Auch hier werden im Ziel schon MailUser durch ADSync oder per PowerShell angelegt, die aber die gleiche ExchangeMailboxGUID wie die Quelle haben. Zudem müssen Sicherheitsgruppen und AppConsent zur Migration konfiguriert werden, damit das Zielsystem sich die Benutzer aus dem Quell-Tenant abziehen kann.

eigene Lizenz erforderlich

IMAP (nur Mails)

?

IMAP
Notes
GroupWise
Google
Exchange 5.5-2013

Admin/PowerShell

Sie müssen auch hier die Benutzer samt Postfach und Lizenz im Ziel mit der gleichen Mailadresse anlegen, die Quelle als CSV-Datei mit Kennworten vorbereiten und dann über IMAP die Inhalte synchronisieren. Nach der Migration stellen Sie den MX-Record um und konfigurieren vielleicht noch eine Weiterleitung in der Quelle, ehe Sie diese später abschalten. Migriert werden nur Nachrichten. Kontakte, Termine, Aufgaben etc. gibt es bei IMAP nicht. Mails werden in ein bestehendes Postfach addiert. Im Ziel bestehende Mails werden nicht gelöscht.

  1. Anwender mit Postfach anlegen
  2. IMAP4 Replikation (alle 24h, maximal 500.000 Mails, max 35MB Mailgröße)
  3. MX-Record umstellen
  4. User lizenzieren und Client umstellen
  5. IMAP4 Schlussreplikation
  6. Altsystem abschalten
Siehe auch IMAP4 Migration mit Exchange Online. Die OnPremises Migration mit MailMig (Siehe IMAP4 Migration zu Exchange ist nicht mehr vorhanden.

Max 500.000 Mails/User
Max 25 MB /Mail
keine Ordner mit "/" im Namen
Keine Kontakte
Keine Kalender
Keine Tasks

PST-Migration

 

Alles was Export in PST unterstützt

Admin

Benutzer überträgt manuell oder PST Import über Cloud o.ä.

PST Import wird gerne genutzt um Archive ohne Belastung des WAN in Office 365 übertragen.

Third Party

Je Produkt

Notes
GroupWise

Third Party

Je nach Produkt. Siehe auch

  • Kosten
  • Oft eingebautes Provisioning

IMAP, CEM und SEM haben keinen echten "Koexistenz"-Betrieb und sind darauf ausgelegt, möglichst schnell ein komplettes Quellsystem in die Cloud zu übertragen. Nur der Hybridmode ist real dafür geeignet, eine Koexistenz über Monate und länger aufrecht zu erhalten und Gruppen von Postfächern zu migrieren. Übrigens auch in beide Richtungen.

Ignite Webcast – understanding Simple Migrations.pptx
http://community.office365.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/01-06-00-00-00-33-49-84/Ignite-Webcast-_1320_-Understanding-Simple-Migrations.pptx

Ignite Webcast - Cutover and Staged Migrations
https://www.youtube.com/watch?v=toGI1urCR4w

Einen "richtigen Hybrid-Mode" gibt es aber nur mit Exchange und Office 365. Wenn Sie mit diesen Produkten aber sehr viele Postfächer oder große Datenbestände migrieren, dann empfehlen die meisten  3d Party Tools einen von zwei Wegen:

  1. Switch nach 99% Migration
    Sie replizieren alle Postfachdaten erst einmal ins Ziel und wenn die zu 99,9% dort vorliegen, stellen Sie MX-Record und Clients um. Ein letzter Lauf holt die letzten Änderungen noch mal in das Ziel. So haben Sie einen Großteil der Daten schon im Ziel und können die Qualität schon mal abschätzen.
  2. Früher Switch mit Nachmigration
    Hierbei wird z.B. nur eine Teilmenge einmalig in das Ziel repliziert und stellen die User um. Diese haben dann nur eine leere oder teilgefüllte Mailbox. Die fehlenden Mails kommen durch eine Nachmigration hinterher. So können die Anwender ganz schnell die neuen Optionen nutzen und der alte Server ist quasi "Lastfrei" für die Migration

Beide Wege bedeuten aber, dass alle Benutzer entweder auf der alten oder neuen Plattform sind. Ein Mischbetrieb erfordert zumindest ein Routing und die Aktualisierung von Weiterleitungen auf Gegenseitigkeit.

Weitere Links