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.

Lesen sie vorher auch die Seite Remote Move Request - Kurzfassung

Hinweis: Sie sollten Hybrid immer über den HCW - Hybrid Configuration Wizard einrichten, da er die meisten Prüfungen und Konfigurationen für Sie übernimmt.

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 Preauthentication erreichbar sein muss.

Achtung:
Zwischen Office 365 und diesem Zugangspunkt darf es kein SSL-Offloading geben. Der MRS-Service erwartet eine verschlüsselte Verbindung. Lauf verschiedener Quellen ist SSL-Aufbrechen zwar erlaubt aber wenn der ReverseProxy das nicht richtig macht, funktioniert es nicht. In einem Gespräch in Redmon wurde sogar behauptet, dass nur NAT erlaubt wäre das selbst Header-Veränderungen die Funktion stören. Tipp: Definieren Sie einen eigenen Namen für diesen Zugangspunkt und filtern Sie auf die Exchange DataCenter IPs

Hier noch die verschiedenen Quelle:

„If your firewall requires pre-authentication or you are using a solution that is performing SSL offloading in front of CAS servers, please note that these configurations are not supported in remote moves scenarios, due to the fact the On-Premises MRS expects to receive the incoming traffic over port 443 with SSL encryption and it refuses the connection if these conditions are not met.“
Quelle: https://blogs.technet.microsoft.com/exovoice/2016/09/19/troubleshooting-issues-where-the-migration-endpoint-cannot-be-created-in-hybrid-scenarios/

The Mailbox Replication Service (MRS) proxy service expects the traffic to be signed/encrypted, which means it cannot be offloaded. This service expects traffic to be encrypted throughout the entire process.
https://support.kemptechnologies.com/hc/en-us/articles/115002426723-Migrating-Mailboxes-to-Office-365

"Although the MRSProxy service runs under Exchange Web Services (EWS), it's not supported to configure SSL offloading. The reason for this is that the MRSProxy service expects traffic to be signed/encrypted. Any hardware load balancer or firewall must reencrypt the MRSProxy traffic before sending it to Client Access servers. If this is the case, it is recommended that you configure SSL bridging for offloading to work.
Quelle: https://docs.microsoft.com/de-de/exchange/configuring-ssl-offloading-in-exchange-2013-exchange-2013-help#configuring-ssl-offloading-for-the-mailbox-replication-proxy-service-mrsproxy

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. Der Hybrid Configuration Wizard übernimmt das aber auch für sie.

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.

Mailadressen für Hybrid Migration

Wenn Sie ihre Exchange Empfänger anschauen, dann sollte jeder Empfänger auch eine Mailadresse der Domain "@<tenantname>.mail.onmicrosoft.com" haben, denn dies ist die eindeutige Routing-Adressen die später OnPremiese als "TargetAddress" eingesetzt wird. Der HCW - Hybrid Configuration Wizard passt dazu die lokalen Empfängerrichtlinien an, damit die Empfänger auch diese Adresse bekommen.

Allerdings gibt es immer wieder Firmen, die eben diese Aktualisierung der Mailadressen anhand von Richtlinien absichtlich unterbinden. In dem Fall müssen Sie selbst für die Vergabe der Adressen sorgen. Hier ein paar nützliche PowerShell-Befehle:

#Anzeige der Empfänger ohne RUS
get-mailbox -Filter {EmailAddressPolicyEnabled -eq $true} 


#Abschalten der Policies
get-mailbox `
   -Filter {EmailAddressPolicyEnabled -eq $true} `
| Set-Mailbox -EmailAddressPolicyEnabled $false

 
# Suche nach doppelten Alias-Einträgen, wenn diese gleich als Userpart verwendet werden sollen
Get-Mailbox -ResultSize unlimited | group alias -NoElement | ?{$_.count -gt 1}
 

# Erweitern um mail.onmicrosoft.com
# Achtung: der Tenantname muss angepasst werden
foreach ($mailbox in (get-mailbox -resultsize unlimited)) {
   write-host "Processing $($mailbox.identity)"
   Set-Mailbox `
      -identity $mailbox.identity `
      -EmailAddresses @{add="$($mailbox.alias)@<tenantname>.mail.onmicrosoft.com"}
}

Denn das Postfach keine entsprechende Adresse hat, dann wird Exchange Online zwar die Migration bis 99% durchführen aber am Ende dann den Fehler bemerken und die Migration anhalten.

Achtung Skye Unified Contact Store

Wenn Sie lokal auch Skype for Business installiert haben und entgegen meiner Empfehlung den Unified Contact Store nutzen, dann liegen die Kontakte der Mitarbeiter im Exchange Postfach. Sie können so ein Postfach problemlos in die Cloud migrieren aber die nachträgliche Migration der Benutzer nach Skype for Business Online oder Teams funktioniert dann nicht. Wenn das aber schon passiert ist, dann haben Sie zwei Optionen:

  • Invoke-CsUcsRollback -Force
    Die stellen die Skype for Business On-Premises Benutzer wieder zurück und verzichten auf die Migration der Kontakte. Sie können die Kontakte vorher natürlich manuell auf dem exportieren lassen um sie danach wieder zu importieren.
  • Postfach zurückmigrieren und nach Umstellung wieder migrieren
    Solange der Hybrid-Mode vorhanden ist, können Sie das Postfach wieder auf die lokalen On-Premises Server migrieren. Dann können Sie für den Benutzer auch ganz normal wieder den Unified Contact Store abschalten, nach Skype for Business Online oder Teams migieren und dann das Postfach wieder in die Cloud verschieben

Die zweite Option ist aber sehr aufwändig, da hier größere Datenmengen übertragen werden und ggfls. auch Client-Konfigurationen (Stichwort ActiveSync) etc. verloren gehen. Also läuft es wohl eher auf die ersten Option hinaus.

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".

Technischer Ablauf

Da mich immer wieder Leser frage was denn da im Hintergrund genau passiert, habe ich den Lebenslauf eines Postfachs noch einmal chronologisch aufgeschrieben. Ich gehe davon aus, dass ADSync mit aktiviertem Exchange HybridMode schon eingerichtet sind.

Phase OnPrem EXO

Anlage des Benutzers

AD-Konto erscheint

AzureAD-Konto wird durch ADSync angelegt

Exchange Postfach

AD-Konto bekommt Exchange Properties

  • HomeMDB
  • msexchHomeServer
  • Mail
  • ProxyAddresses
    (inklusive einer Adresse in der Form  user@msxfaq.mail.onmicrosoft.com)

ADSync überträgt die Exchange Informationen, so dass der OnPremi Empfänger in der Cloud als "MailUser" erscheint. Die TargetAddress ist die normale Maildomäne "user@msxfaq.de". Der HybridAssistent hat passend einen "Outbound Connector" zur On-Premises-Umgebung erstellt.

Die Proxy-Addressen u.a. kommen alle von der lokalen Exchange Umgebung

Migration startet

Es ändert sich nicht

In der Cloud legt Exchange ein Postfach an und synchronisiert über den Mailbox Replication Service die Mails des lokalen Postfachs in die Cloud. Neue Mails werden aber weiter über den MailUser zur On-Premises-Umgebung geroutet.

Dieser zustand kann mehrere Tage oder theoretisch auch Wochen anhalten.

Migration wird abgeschossen

Eine Weiterleitung für neue Mails wird an das Postfach über die TargetAddress auf user@msxfaq.mail.onmicrosoft.com eingetragen. Neue Mails landen in der Cloud.

Das Postfach wird wir dem MailUser verbunden. Aus dem Mailuser wird nun ein MailboxUser. Neue Mails an das Cloud Konto kommen im Cloud-Postfach an

Final Replikation

 

Die Migration repliziert noch ein letztes Mal die zwischenzeitlichen Änderungen von On-Premises in die Cloud

Migration wird beendet

Aus der Mailbox wird nun durch den MRSProxy eine "Remote-Mailbox"

ADSync repliziert die Änderungen, die eigentlich keine mehr sind in die Cloud

Eigentlich alles ganz einfach. Sie müssen "nur" das Zusammenspiel zwischen ADSync und MRS/MRSProxy verstanden haben.

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