Remote Move Request - Kurzfassung

Da ich immer wieder gefragt werden, wie die Migration von Exchange On-Premises nach Exchange Online erfolgt, habe ich hier eine "high level"-Kurzfassung geschrieben. Anhand dieser sollten Exchange Administratoren recht einfach verstehen, wie die Migration im Grund abläuft, ohne dass ich jedes einzelne Commandlet mit aufführe.

Auf der Seite RemoteMoveRequest ohne Hybrid gibt es eine Langfassung mit vielen Hintergrundinformationen

Ausgangssituation

Wir starten mit einen On-Premises Exchange Server, der Mails mit dem Internet austauscht. Aus Vereinfachungsgründen haben ich die Firewalls und Spamfilter hier nicht mit eingezeichnet, da dies für die weitere Migration nicht relevant ist.

Lokal gibt es entsprechend einen AD-Benutzer der die Exchange Properties für eine "UserMailbox" hat. Das Objekt hat also neben der Mail-Adresse auch die ProxyAddresses aber das Feld "TargetAddress" ist natürlich leer. Ehe Sie natürlich überhaupt an die Migration gehen, müssen Sie die Themen "Datenschutz", Lizenzen etc. geklärt haben. Fangen sie aber schon früh mit einer Analyse an, ob alle Clients und 3rd Party Produkte "kompatibel" sind. Ich denke da an "Modern Auth" mit Abschaltung von BasicAuth, On-Premises Disclaimer/Archiv-Lösungen, IMAP4/POP3-Zugriffe durch CRM/ERP/Helpdesk/Support-Systeme und Massenmailversender. Hier gibt es in Exchange Online durchaus erreichbare Grenzwerte.

ADSync Abgleich

Ehe Sie überhaupt an eine "Remote Move Request"-Migration denken, müssen Sie einen Tenant kaufen, die Domains addieren, weitere Einstellungen vornehmen und die Verzeichnisse abgleichen. Der einfachste Weg ist dabei der Einsatz von ADSync, so dass ich auf andere Ansätze nicht weiter eingehe. ADSync liest dann die lokalen Benutzerinformationen und legt in der Cloud entsprechende MailUser an. Die Objekte in der Cloud haben aber eine TargetAddress, die Exchange Online verrät, wo das eigentliche Postfach liegt.

ADSync sollte alle für Exchange relevanten Objekte in die Cloud replizieren, d.h. Verteiler, weitere Kontakte, Ressourcen etc. sollten auch repliziert werden, damit die Mailzustellung fehlerfrei funktioniert. Noch gibt es aber keine Postfächer in der Cloud und damit stört auch der Versand vom Tenant in das Internet noch nicht. Dennoch sollten Sie nun schon mal die SPF/DKIM/DMARC-Konfiguration anpassen, so dass die Cloud später ein legitimer Absender ist. In der Produktion kann es auch hier zu Verzögerungen kommen, denn sie müssen Stammdaten korrigieren und sicherstellen, dass die Fehler nicht mehr kommen. Auch beim Provisioning sind erste Vorarbeiten notwendig.

Mailroutung und Migration

Um eine Mailbox in die Cloud zu migrieren, muss ein Migration Endpunkt angelegt werden. Die Anlage von SMTP-Connectoren ist zwar nicht zwingend erforderlich, da auch der MX-Record auf das gleichen Ziel verweist. Ich rate aber immer zu einer expliziten Konfiguration, damit die Mails zuverlässig zugestellt werden. Wenn nämlich eine Mail aus dem Tenant mit der Firmendomain über den MX-Record zum On-Premises-Spamfilter gesendet wird, könnte das als "Phishing" missverstanden werden.

Diese Konfiguration kann und sollte durch den HCW - Hybrid Configuration Wizard erfolgen. Er kann natürlich noch weitere Funktionen (Free/Busy, Mailtipps etc.) einrichten, die hier nicht eingezeichnet wurden.

Der HCW ändert aber auch die lokale Empfängerrichtlinien, damit die Exchange Empfänger im lokalen Active Directory eine Adresse aus der SMTP-Domain "<tenantname>.mail.onmicrosoft.com" bekommen. Diese werden von ADSync in die Cloud repliziert und sind für das spätere Routing von Mails von On-Premises an ein Cloud-Postfach erforderlich.

Wer mag, kann hier natürlich mit Hybrid Centralized Mail Transport alle Mails aus Exchange Online über den lokalen Exchange Server routen. Wenn Sie aber eh die lokale Exchange Umgebung zurückbauen wollen, dann sollten Sie gleich den Versand aus der Cloud richtig konfigurieren, d.h. Disclaimer, Transportregeln, DKIM, SPF, Smarthosts, Routing zu anderen Diensten. Vergessen Sie auch nicht die Einstellungen für die Koexsistenz, wenn Postfächer einige Zeit lange auf beiden Plattformen sind.

Migration und MX-Umstellung

Nun beginnt die Zeit der eigentlichen Migration, bei der Postfächer in "Batches" in die Cloud verschoben werden. Dabei liest die Cloud über den lokalen MRSProxy die Mails aus der Quelle und überträgt diese in das Ziel. Nachdem das Postfach fast komplett übertragen wurde, wir der Job angehalten und dann immer mal wieder eine Aktualisierung gestartet. Es kann also etwas dauern, bis alle Postfächer in einem Batch alle auf dem Status "99%" sind.

Im gleichen Zeitraum sollten Sie auch das Mailrouting überdenken. Wenn Sie den lokalen Exchange Server oder ihren lokalen Spamfilter abschalten wollen, müssen Sie den MX-Record irgendwann auf Exchange Online Protection umstellen. Da Exchange Online alle Empfänger kennt, können Sie dies auch schon am Anfang machen, während der Migration oder auch erst vor der Abschaltung des lokalen Exchange Servers. Allerdings wird es immer uninteressanter, Mails erst durch die On-Premises-Systeme zu zwingen, wenn die finalen Empfänger doch in Exchange Online liegen.

Denken Sie aber auch an andere "On-Premises"-Lösungen, die nun immer auf die Cloud zugreifen. So könnte ein lokaler MDM-Service ebenfalls in die Cloud verschoben oder durch Intune abgelöst werden.

Migrationsabschuss

Wenn Sie einen Migrationsbatch abschließen, dann werden im Grunde folgende Schritte durchlaufen. Aktiver Part ist dabei der Migrationscode in der Cloud, welcher über den MRSProxy auch die lokalen Änderungen steuert.

  • Aktivierung des Zielpostfachs und Entfernen der Weiterleitung in Exchange Online
    Neue Mails landen nun im Exchange Online Postfach und werde nicht mehr On-Premises weiter geleitet
  • Aktivieren der Weiterleitung in Exchange On-Premises
    Alle Mails, die noch zum On-Premises-Postfach unterwegs sind, werden über die "username@<tenant>.mail.onmicrosoft.com" zu Exchange Online umgeroutet. Zudem werden damit auch Autodiscover-Anfragen der Client ebenfalls umgeleitet (Autodiscover Redirect)
  • Aussperren des Zugriffs auf das Postfach in der Quelle
    Zusammen mit der Weiterleitung ist das Quellpostfach damit quasi eingefroren
  • Letzte Deltamigration
    Exchange Online holt sich ein letztes Mal die Änderung aus der Quelle
  • Konvertierung der Quelle Mailbox -> RemoteMailbox
    Damit können Sie nun On-Premises mit *-RemoteMailbox" das Exchange Online Postfach verwalten.

Damit ist vom Backend die Migration für dieses Postfach abgeschlossen. Allerdings kann es natürlich auf dem Client noch zu Nacharbeiten kommen. Outlook sollte alleine beim nächsten Start bemerken, dass das Postfach nicht mehr erreichbar ist und über Autodiscover eine neue Konfiguration erhalten. Etwas anders sieht es bei mobilen Clients aus die meist ein neues ActiveSync-Profil benötigen, welches der Benutzer neu einrichtet oder per MDM verteilt wird. Auch andere Clients wie Thunderbird aber auch Archiv-Lösungen, Faxserver, UM-Server müssen ggfls. auf die neue Umgebung angepasst werden.

Rückbau OnPremise

Wenn dann irgendwann alle Postfächer zu Exchange Online migriert wurden und das Mailrouting allein über Exchange Online läuft, dann ist der lokale Exchange Server vielleicht überflüssig. Da sie aber aufgrund von ADSync die Exchange Eigenschaften ihrer Empfänger nicht in der Cloud sondern nur lokal verwalten können, haben Sie zwei offizielle Optionen:

In beiden Fällen repliziert ADSync dann die Änderungen zu Exchange Online. Eine direkte Bearbeitung der AD-Felder per LDAP/ADSI etc. ist technisch natürlich möglich aber nicht offiziell "supportet"

Sie können natürlich mit der Exchange Management Rolle weiterhin einen anderen SMTP-Service (PostFix, SendMail, hMailServer, Windows SMTP-Server) einsetzen, wenn interne System per SMTP Mails an ihren Tenant senden wollen. Das ist dann natürlich kein" Hybrid" mehr und sie sollten mit der Deinstallation des letzten lokalen Exchange Server auch die Hybrid-Bereitstellung abschalten.

Weitere Links