Exchange Hybrid Migration

Die Migration eines Postfachs zwischen Exchange On-Prem und Exchange Online ist über den Hybrid Mode besonders einfach und elegant. Es entspricht fast einem Move innerhalb einer Exchange Umgebungen und erfolgt fast komplett im Hintergrund. Der Anwender kann weiter arbeiten, bis am Ende der Datenreplikation eine kurze Unterbrechung für dieses Postfach erfolgt. In der Zeit friert Exchange das Quellpostfach quasi ein, überträgt die letzten Änderungen und stellt dann das Mailrouting um. Der große Vorteil einer Hybrid Migration ist, dass eine beim Client vorhandene OST-Datei gültig bleibt, d.h. keine neue komplette Replikation erfolgen muss. Die Migration lässt sich per Powershell oder über das Exchange Online Admin Portal ausführen.

Vorarbeiten: Hybrid mit DirSync

Ehe Sie eine Postfachmigration über diesen Weg machen können, müssen Sie natürlich einen korrekt konfigurierten Exchange Hybrid-Mode haben. Das bedeutet für Inhaltsmigration u.a.

  • Exchange Lizenzen
    Damit die neuen Postfächer in der Cloud ihre Inhalte nicht nach 30 Tagen wieder verlieren, sollten Sie spätestens nach der Migration entsprechende Lizenzen zuweisen.
  • Aktivierter Verzeichnisabgleich
    Ansonsten "sieht" die Exchange Online Umgebung nicht, welche Postfächer es On-Prem gibt
  • Veröffentlichter EWS-Service mit MRS-Proxy
    Denn über diesen Zugang holt die Cloud die Inhalte aus der lokalen Umgebung heraus und stellt letztlich auch das Postfach um.
  • Privilegiertes Dienstkonto
    Für die Migration müssen Sie ein Benutzerkonto angeben, welches die Inhalte der Postfächer lesen und am Schluss aus dem lokalen "MailboxUser" eine "RemoteMailbox" macht.
  • Autodiscover
    Damit die Outlooks Clients nach der Migration auch den Weg zum neuen Postfach finden, sollten sie "Autodiscover" korrekt umgesetzt haben
  • Aktuelle Clients
    Für den Betrieb mit Exchange Online sind Mindestvoraussetzungen der verschiedenen Clients zu beachten.

Dies sind die wesentlichen Voraussetzungen, von denen natürlich noch einige andere Voraussetzungen abhängen, z.b. ein gültiges Zertifikat auf ihrem WebServer, entsprechende DNS-Einträge etc.

MRS-Proxy auf On-Prem aktivieren

Die Office 36 Services "ziehen" sich die Mails aus der lokalen Exchange Umgebung über den Mailbox Replication Service. Der Zugriff erfolgt dabei über die EWS-URL, die dazu aus dem Internet mit einem gültigen Zertifikat ohne Peauthentication erreichbar sein muss.

Achtung:
Zwischen Office 365 und diesem Zugangspunkt darf es maximal ein NAT geben. Alles andere ist nicht supportet und führt auch zu Problemen.
Tipp: Definieren Sie einen eigenen Namen für diesen Zugangspunkt und filtern Sie auf die Exchange DataCenter IPs

Aber auch dann müssen Sie auf den virtuellen EWS-Verzeichnissen noch die Funktion MRS-Proxy aktivieren. Das geht einfach über ECP oder per PowerShell.

Diese Einstellung sollte auf allen Exchange Servern erfolgen, von denen Sie Mailboxen migrieren wollen. Daher ist es wohl am einfachsten dies per PowerShell zu machen:

# Aktivieren der Einstellung auf allen EWS-Verzeichnissen
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true

Kontrolle der Einstellung
Get-WebServicesVirtualDirectory | FL Identity,MRSProxyEnabled

Diese Änderung erfolgt technisch im Active Directory und wird von jedem Server regelmäßig ausgelesen und auf die lokale IIS-Konfiguration angewendet. Das kann durchaus etwas dauern. Ob die Änderung schon gewirkt hat, können sie ebenfalls per PowerShell prüfen.

$Cred = Get-Credential -User admin@msxfaq.com 
Test-MigrationServerAvailability `
   -ExchangeRemoteMove `
   -Autodiscover `
   -EmailAddress admin@msxfaq.com `
   -Credentials $Cred

RunspaceId         : guid
Result             : Success
Message            :
ConnectionSettings : <ExchangeConnectionSettings HasAdminPrivilege="True" HasAutodiscovery="False" HasMrsProxy="True" AutodiscoverUrl=""
                     IncomingEmailAddress="" IncomingRPCProxyServer="owa.msxfaq.com" IncomingExchangeServer="owa.msxfaq.com" IncomingNSPIServer=""
                     IncomingDomain="" IncomingUserName="admin@.msxfaq.com"
                     EncryptedIncomingPassword="rtQzkrSpe5XscA" IncomingAuthentication="Basic"
                     ServerVersion="" TargetDomainName="" SourceMailboxLegDn="" PublicFolderDatabaseServerLegacyDN="" />
SupportsCutover    : False
ErrorDetail        :
IsValid            : True
Identity           :
ObjectState        : New

Für "$cred" müssen Sie einen privilegierten Benutzer verwenden. Für eine Fehlersuche lohnt es sich zuerst mal ein "-verbose" anzuhängen

Dienstkonto anlegen

Damit Exchange Online die Daten von der On-Prem Umgebung extrahieren kann, benötigt es entsprechende Berechtigungen. Microsoft schreibt dazu auf

Demnach muss das Konto eine der folgenden drei Dinge erfüllen:

  • Mitglied von "Domain Administrator"
  • Mitglied von "Exchange Recipient Administratoren"
  • Mitglied der Gruppe "Organization Management" oder "Recipient Management" sein

In kleinen Umgebungen wird man dazu wohl einfach schnell den Domänen Administrator nutzen. Da aber die Anmeldedaten in Office 365 hinterlegt und vielleicht länger genutzt werden, würde ich besser ein Dienstkonto dafür vorschlagen, dessen Kennwort dann auch einige Zeit lang konstant bleibt, bis die Migration abgeschlossen ist. Auf keinen Fall sollten Sie das Konto eines "regulären Administrators" nutzen. 

Migrationsendpunkt definieren

Die zweite Vorarbeit vor dem Verschieben von Postfächern ist die Definition mindestens eines Migrationsendpunkts.

In der Liste Sehen sie schon einen definierten Endpunkt. Es sind durchaus mehrere Endpunkte möglich. Das ist sinnvoll, wenn Sie mehrere Exchange Standorte haben, die unter einem eigenen Namen erreichbar sind.

Wenn Sie einen neuen Endpunkt anlegen, dann haben sie zuerst die Entscheidung zwischen drei Typen zu treffen:

Für den Hybrid Mode ist "Exchange Remote" der richtige Typ. "Outlook Anywhere ist der Endpunkt bei einer CutOver oder Staging-Migration. Eine Migration per IMAP4 ist durchaus für sonstiges Quellen (Notes, Google-Mail, OpenExchange und andere IMAP4-Server nutzbar. Exchange Online braucht einen DienstUser. Die Übersetzung ist etwas irreführend, denn natürlich brauchen wir nicht für jedes Postfach einen eigenen Migrationsendpunkt. Exchange Online braucht diese Informationen um per Autodiscover den Weg zu Exchange On-Prem zu finden und einen privilegierten Benutzer zur Migration zu haben.

Ob ihre Eingaben korrekt waren, sehen Sie gleich nach dem Test durch Exchange Online.

Es ist gar nicht mal so selten, dass Autodiscover vielleicht nicht den richtigen Namen zurück liefert. Sie können dann natürlich hier den korrekten Hostnamen hinterlegen, unter denen Ihr Exchange Server veröffentlich ist.

Postfachmigration planen

Die eigentliche Migration können Sie dann sogar per Browser einstellen. Anders als bei Skype for Business ist bei Exchange Migrationen der Online-Teil aktiv. Sie senden also nicht ihre Daten in die Cloud sondern die Cloud holt sich die Daten von ihrer On-Premises-Umgebung. Dabei bekommt Exchange Online mit jedem Request auch Informationen über die Performance der Quelle und kann entsprechend die Migration drosseln. Das gleiche gilt natürlich auch bei Engpässen in Exchange Online.

Die konfigurieren nicht für jedes einzelne Postfach eine Migration sondern fassen mehrere Postfächer in Gruppen (Batches) zusammen. Zuerst müssen Sie aber auswählen, welche Art der Migration dieser Batch ausführen soll.

Allein die Konfiguration eines Migrationsendpunkts für eine "Remoteverschiebungsmigration" verbietet nicht alle anderen Wege. Die CutOver-Migration ist aber blockiert, da Sie mit dem DirSync in Konflikt steht.

Im nächsten Fenster wähle ich dann die Benutzer aus.

Der Server, welcher die Daten bereit stellt, wurde hier automatisch ausgewählt. Wenn Sie mehrere Migrationsendpunkte definiert haben, bekommen Sie natürlich eine Auswahl angezeigt:

Das Kind muss einen Namen bekommen. Hier definieren Sie auch den Umfang der Migration und welche Target-Domain nach der Migration an die von Mailbox nach MailUser konvertierten Objekte in der Quelle verwendet wird. Die Office365 Domäne, welche auf "onmicrosoft.com" endet, ist hier meist die richtige Antwort.

Die letzte Option bestimmt, wie nach dem Ende der Replikation verfahren werden soll. Sie können den Batch auf "Pending" stehen lassen, d.h. Exchange synchronisiert weiter Elemente aber das Postfach bleibt noch in der Quelle bis sie als Administrator die Blockade lösen. Das ist interessant, wenn Sie auf den Client auch Anpassungen vornehmen und die Migration mit dem Client-Team zeitlich abstimmen müssen. Gerade auch Mobilgeräte-Provisioning ist hier ein Thema.

Sie können natürlich auch einstellen, dass nach der erfolgreichen Synchronisation aller Postfächer in dem Migration-Batch diese automatisch auch umgestellt werden.

Gerade wenn sie viele Postfächer umziehen, die auch noch unterschiedlich groß sind, ist die Option "Batch manuell abschießen" interessant. Dadurch repliziert Exchange Online schon 99,9% der Mails in die Cloud und aktualisierte die Differenz alle 24h. Wenn dann alle Postfächer des Batch in der Cloud sind, können Sie den Zeitpunkt selbst bestimmen, wann alle Postfächer final umgezogen werden sollen. So können Sie Rücksicht auf die Arbeitszeiten nehmen und den Umzug z.B.: in der Nacht abschließen.

In der Übersicht sehen Sie den Status der einzelnen Batches.

Postfachmigration abschließen

Wenn Sie bei der Einrichtung des Batch nicht gleich den automatischen Abschluss eingestellt haben, dann liegen am Ende alle Postfächer des Batch auf "Wartestellung", d.h. die Daten sind zu fast 100% schon im Ziel und es fehlt nur noch ein finaler Sync und der Wechsel des "Homeservers".

Zusammenfassung

Der Umzug von Postfächern über einen Exchange Hybrid Mode und einer Hybrid Migration ist in den meisten Fällen eine sehr einfache und problemlose Lösung. Sie müssen natürlich sinnvolle Gruppen von Benutzern in Batches zusammenfassen. Orientieren Sie sich dabei am besten an logischen Team, die auch intern sehr stark interagieren, z.B. Stellvertreter nutzen. Synchron müssen Sie dazu die Umstellung auf den Client begleiten (SmartPhone, Outlook), denn selbst wenn Autodiscover vieles alleine übernimmt, ändert sich für Anwender schon etwas, z.B. die URL für Outlook im Browser.

Natürlich müssen Sie ein Auge auf ihre AADConnect-Instanz und ihr Provisioning haben, die auch weiterhin für die Verwaltung der Empfänger im lokalen Active Directory zuständig sind.

Beachten Sie auch die Bandbreite, da die übertragene Datenmenge durchaus beachtlich sein kann und größere Postfächer auch mehrere Stunden die Leitung belegen können. Wohl dem, der über ein Monitoring nicht nur die Auslastung der Leitung per SNMP überwacht, sondern auch den Durchsatz über Ende zu Ende Monitoring und vielleicht auch die Migrationsstatistik ausliest.

Weitere Links