T2T Exchange Online

Auf dieser Seite sollte es darum gehen, wie können Sie Postfächer von einem Tenant in einen anderen Tenant umziehen können.

Die Funktion ist seit 1. Nov 2022 "general available"
Cross-Renant User Data Migration is Now Generally Available
https://techcommunity.microsoft.com/t5/exchange-team-blog/cross-tenant-user-data-migration-is-now-generally-available/ba-p/3667700

Beachten Sie dazu auch die Seite T2T Exchange Walkthrough

Vorgeschichte

Migrationen von Postfächern zwischen On-Premises Servern oder auch zwischen On-Prem Exchange Servern unterschiedlicher Organisationen sind schon lange möglich und sowohl mit Bordmittel als auch 3rd Party Tools möglich (Siehe Migration in neue Organisation). Auch die Migration von Postfächern von On-Premises zu Exchange Online ist relativ einfach und robust möglich, sei es per Hybrid, Staging, Cutover oder 3rd Party Produkte (Siehe Exchange Online - Migration).

Die Migration zwischen Exchange Online Postfächern war aber zumindest bis Ende 2022 immer eine kleine Herausforderung und das Szenario wird immer häufiger vorkommen. Im Herbst 2022 hatte ich folgende vier Wege zur Auswahl:

  • Manuelle Migration
    Sie legen einfach im Ziel die Postfächer neu an und schwenken den MX-Record. Die Anwender können dann im neuen System erst einmal mit leeren Postfächern starten. Die alten Mails können die Anwender oder ein Admin dann selbst "kopieren", z.B. per Outlook und zwei Profilen oder IMAP4Sync etc. Einfach, günstig aber skaliert nicht gut und es gibt natürlich "Verluste", z.B. Regeln, Stellvertreter und um das Empfängermanagement (z.B. Verteiler) müssen Sie sich auch noch kümmern.
  • 3rd Party Migration
    Daher gibt es schon lange 3rd Party Programme (BinaryTree, Quest, CodeTwo etc.), die für sie die Mails z.B. per EWS aus dem Quellpostfach extrahieren und in das Ziel mehr oder weniger gute kopieren oder sogar synchronisieren. Über Graph oder Exchange PowerShell können diese Tools auch die Empfängerdaten kopieren. Das klingt schon besser aber ist mit Zusatzkosten verbunden.
  • Hybrid On-Premises-Migration
    Wer noch lokale Exchange Server mit genug Platz und Zeit hat, kann natürlich alle Exchange Online Postfächer erst einmal wieder nach On-Premises migrieren und danach in den anderen Tenant weiterschieben. Das ist aber eher eine theoretische Lösung, auch wenn sie vor vielen Jahren mangels Alternativen doch genutzt wurde.
  • Direktmigration
    Seit Herbst 2022 gibt es von Microsoft nun eine Funktion, um Postfächer direkt zwischen Tenants zu migrieren. Technisch ist es ein "Move-Request", bei dem die Inhalte von einem Tenant zum anderen Tenant verschoben werden. Microsoft bewegt also Daten und hängt nicht einfach nur die msExchMailboxGUID an ein anderes AD-Objekt.

Diese Seite fokussiert sich auf die letzte und "neue" Option, wie mit Microsoft Bordmitteln eine Migration von Exchange Postfächern zwischen Tenants umgesetzt werden kann.

Bausteine

Wenn Sie ein Postfach oder eine Domain von einem Tenant zu einem anderen Tenant verschieben wollen, dann geht es nicht nur um die reinen Postfachinhalte, sondern es gibt noch einige andere verbundene Themen.

  • Daten-Move
    Zuerst geht es natürlich um die Übertragung der Daten und Mailadressen und ab wann der Anwender mit dem neuen Postfach arbeitet. Die Migration mit Bordmitteln nimmt schon viel Inhalte mit, aber Sie müssen schon einige Randbedingungen erfüllen, damit z.B. Stellvertreterrechte oder Regeln danach wieder funktionieren. Einige Inhalte im Postfach, z.B. SendAs-Rechte, Teams 1:1-Chat-Nachrichten, Labels kommen nicht mit. Auch Verteilergruppen werden durch die Mailbox-Migration nicht kopiert.
  • SMTP-Routing und Sharing
    Wenn der Benutzer im neuen Tenant eh eine neue SMTP-Domain zum Empfang und Versand bekommt, dann ist der Umzug einfach. Eine Erreichbarkeit unter der früheren Adresse ist aber weiter möglich, wenn das Postfach in der Quelle als Kontakt mit Weiterleiterleitung existiert oder Sie die komplette SMTP-Domain in den neuen Tenant umziehen. Dann kann der Anwender im neuen Tenant auch weiter mit der bisherigen Mail senden.
    Es gibt aber auch eine Preview, mit der zwei Tenants zumindest die gleiche SMTP-Domain nutzen können. Diese Funktion erlaubt aber kein UPN-Domainsharing.
    Siehe auch "Domain sharing for email" (https://aka.ms/domainsharingpreview)
  • Empfängerverwaltung
    Hier sind sie als Administrator gefordert. Sie können die Benutzer im Ziel manuell per PowerShell anlegen oder mittels getrennter OUs und ADSync-Konfigurationen über lokale On-Premises-Benutzer verwalten oder die Preview zu "Cross Identity Management" nutzen.
    Siehe auch "Cross-tenant people search" (https://aka.ms/crosstenantpeoplepreview)

Es ist daher nicht allein mit der Migration der Postfachinhalte getan. Nicht nur die Anwender erwarten ein funktionierendes Adressbuch, welche für die korrekte Mailzustellung zwingend erforderlich ist.

Lizenzierung

Solange das Postfach noch im "Quell-Tenant" ist, muss er natürlich eine Exchange Online Lizenz behalten. Das Benutzerkonto im Ziel darf Anfang noch keine Exchange Lizenz bekommen, da sonst Exchange Online dort schon ein Postfach anlegt und die Migration scheitert. Das Zielobjekt muss ein "MailUser" sein. Erst wenn das Ziel schon mit dem Feld "ExchangeGUID" vorbereitet ist, können Sie eine Lizenz zuweisen. Es reicht aber auch, die Lizenz erst nach der Migration innerhalb der 30 Tage "Grace Period" zuzuweisen.

Allerdings benötigen Sie für die Migration mit Microsoft Bordmitteln noch eine "Cross-tenant user Data migration"-Lizenz.

Diese Lizenz kostet im Frühjahr 2023 ca. 10€ und muss im Zieltenant dem Benutzer zugewiesen werden. Wenn Sie im Ziel diese Lizenz nicht zuweisen, dann sehen Sie folgenden Fehler im Migrationsstatus.

MrsLicenseMissing
MrsLicenseMissingTransientException

Funktionsweise

Microsoft hat auf der Seite https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration eine ausführlichere Beschreibung samt der PowerShell-Befehle veröffentlicht. Zudem wurde auf der Ignite 2022 eine Demo aufgezeichnet:

Cross-Tenant User Data Migration in Exchange Online - Demo
https://youtu.be/RGb__c9xhSw?t=1060

Prüfen Sie einfach im Exchange Admin Center einmal, ob es unter "Migration" nun auch den Eintrag "Cross Tenant Migration" gibt:

Ich beschränke mich hier auf die Aufzählung und meinen eigenen Ergänzungen. Wenn Sie eine Rückmigration durchführen müssen, müssen Sie die Schritte in jede Richtung einmal durchführen.

  • Scope in der Quelle einrichten
    Natürlich darf erst einmal nicht ein GlobalAdmin eines Tenant sich mal so eben die Benutzer eines anderen Tenants ziehen. ´Daher benötigen sie in der Quelle eine Mailaktivierte Securitygruppe in der all die Postfächer addiert werden, die später migriert werden dürfen. Prüfen Sie in dem Zuge auch mal die Größe der Postfächer, damit keine Quotas die Verschiebung blockieren.
  • Einrichtungen in dem Ziel
    Dann benötigen wir im Zieltenant eine "Application" mit dem Recht "Mailbox Migration" um dann im Ziel einen Migration Endpoint anzulegen.
  • Berechtigungen in der Quelle zulassen
    Der abgebende Tenant muss dann die Application ebenfalls über ein "New-OrganizationRelationship" eingetragen und auf die schon angelegte Gruppe berechtigt werden.
  • Optional: SMTP-Domain Sharing
    Normalerweise kann ein Postfach in einem Tenant nur mit einer Maildomain senden die dem Tenant gehört. Bei Migration oder Koexistenz ist das natürlich hinderlich und konnte bislang nur noch durch externe Rewrite-Dienste realisiert werden. Mittlerweile ist es aber möglich, dass Sie im besitzenden Tenant eine SMTP-Domain für die Nutzung als "Primary SMTP-Address" in einem anderen Domain als "Internal Relay" einzutragen. Zudem müssen Sie das SMTP-Routing zwischen den Domains einrichten. Sie benötigen dann einem Benutzer im anderen Tenant diese Domain als Absenderadresse eintragen.
    Die Funktion kann in jede der beiden Richtungen interessant sein, z.B. dass Benutzer nach der Migration weiter ihre alte SMTP-Domain im Ziel-Tenant nutzen aber auch vor der Migration könnten Benutzer in der Quelle schon mit der zukünftigen Zieldomain unabhängig vom Zeitpunkt der eigentlichen Migration arbeiten.
  • Zielobjekte anlegen
    Die Migration legt im Ziel keine Objekte an. Es obliegt also ihnen als Administrator im Ziel-Tenant, entsprechenden Benutzer mit den notwendigen Properties (msExchMailboxGUID. msExchArchiveGUID, LegacyExchangeDN, UPN, PrimarySMTPAddress, TargetAddress, ProxyAddresses und ggfls. weitre Felder anzulegen. Das können "CloudOnly-Benutzer" sein, die erst später dann mit ADSync und lokalen Objekten gemached werden (ADSync User Matching) oder sie bekommen die Benutzer schon per ADSync aus einem lokalen AD mit den entsprechenden Feldern
    Die "TargetAddress" verweist bei den Objekten natürlich auf das Postfach in der Quelle (user@<quelle>.mail.onmicrosoft.com), damit eine Erreichbarkeit gewährleistet ist.
  • Lizenzzuweisung planen
    Spätestens, wenn das Postfach umgezogen ist, muss das Zielobjekt auch eine Exchange Lizenz bekommen. Sie können die Lizenz schon vorher zuweisen aber erst, nachdem die Felder "msExchMailboxGUID, msExchArchiveGUID," korrekt provisioniert sind, da ansonsten ein neues Postfach angelegt wird. Die Migration kann leider keine Quelldaten in ein bestehendes Zielpostfach zusammenführen. Notfalls müssen sie das Zielpostfach mit "Set-User <user> -PermanentlyClearPreviousMailboxInfo" bereinigen.
    Siehe dazu auch ADSync und MailUser
  • SMTP-Routing
    Es wird passieren, dass Mails An eine Domain von einem Tenant zum anderen Tenant geroutet werden. Über entsprechende Connectoren sollten Sie sicherstellen, dass dies funktioniert. Es könnte nämlich sein, dass eine externe Mail mit strengen SPF/DKIM/DMARC-Einstellungen über Tenant1 zu Tenant2 gehen muss und im Tenant2 dann als Spam verworfen wird.
  • Migration
    Die Steuerung erfolgt immer durch das aufnehmende Ziel. Ein "New-MigrationBatch" synchronisiert die Elemente aus der Quelle in das Ziel. Der Administrator in der Quelle muss und kann da gar nichts tun. Er hat ja anfangs schon der "App" der Quelle vertraut.
    Die Migration selbst erfolgt nur über einen "Migrationbatch". Eine Migration einzelner Postfächer ist nicht über New-MoveRequest möglich aber Sie können natürlich einen Migrationbatch mit genau einem Benutzer anlegen. Die Migration muss am Ende dann manuell abgeschlossen werden.

Umstellung des Routing durch die Migration: (Achtung in Verbindung mit ADSync)
Exchange mailbox moves using MRS craft the targetAddress on the original source mailbox when converting to a MailUser by matching an email address (proxyAddress) on the target object. The process takes the -TargetDeliveryDomain value passed into the move command, then checks for a matching proxy for that domain on the target side. When we find a match, the matching proxyAddress is used to set the ExternalEmailAddress (targetAddress) on the converted mailbox (now MailUser) object.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide#how-do-we-target-which-smtp-address-is-selected-for-targetaddress-targetdeliverydomain-on-the-converted-mailbox-to-mailuser-conversion

  • Mailrouting anpassen
    Solange das Postfach noch in der Quelle ist, kann der Anwender in der Quelle seine Mails lesen und auch neue Mails versenden. Mails an das Zielpostfach landen bei korrekt gesetzter Targetaddress ebenfalls in der Quelle. Irgendwann aber erfolgt der "Switch", bei dem Sie als Admin in dem Ziel die Weiterleitung in die Quelle über das Feld "TargetAddress" entfernen und idealerweise in der Quelle eine Weiterleitung in das Ziel aktivieren.
    In dem Zuge ist auch zu prüfen, ob und wann der MX-Record ggfls. angepasst wird oder der Benutzer seine alte Mailadresse einfach verliert. Wenn er die alte Adresse hingegen als primäre Adresse auch im neuen Tenant genutzt werden soll, dann müssen Sie zeitgleich auch die SMTP-Domain in den neuen Tenant umziehen, das "DomainSharing"-Feature (Preview) nutzen oder einen externen Rewrite-Service nutzen, der alle ausgehende Mails entsprechend umschreibt.
  • Client-Migration
    Vergessen Sie nicht die wichtigste Gruppe: Die Anwender. Bei einer Migration von Tenant zu Tenant bleiben die Hostnamen für OWA, ActiveSync, Outlook zwar gleich aber durch den Tenant-Wechsel sind die Benutzer selbst bei Beibehaltung des UPN im Grund neue Benutzer mit eigener AzureAD ObjectGUID. Hier kann eine Neueinrichtung des Profile samt OST-Resync und eine Verteilung eines Mobile Profils erforderlich werden.

Nacharbeiten mit ADSync/Hybrid

Mit dem Abschluss der Migration eines Postfachs verändert die Migration auch die Objekte in der Cloud. Der Mailuser im Ziel wird zu einer Mailbox und in der Quelle wird aus der Mailbox ein Mailuser. Das funktioniert problemlos, wenn auf beiden Seiten "CloudOnly"-Konten sind. Kniffliger wird es in Verbindung mit ADSync und dem Exchange Hybrid-Mode. Interessanterweise kann die Cross Forest Migration den Typ der Objekte und die ExternalEmailAddress (TargetAddress) verändern, obwohl diese Felder eigentlich durch ADSync gesperrt sein sollte. Die Cloud-Migration kann aber keine Felder im lokalen Active Directory verändern. Das müssen noch nachholen, damit ihr Hybrid-Mode fehlerfrei läuft.

Umgebung Quellobjekt Aktivitäten

Quelle

CloudOnly

Wenn die Quell im Hybrid Mode war, dann sollte diese Konfiguration eigentlich nicht genutzt werden. Denn schon vor der Migration wusste ihr lokaler Exchange Server nicht von dem Objekt. Sie könnte aber dennoch nun im lokalen AD einen passenden Mailuser anlegen, der durch ADSync auf das vorhanden Cloud-Konto gematched wird.

Quelle

ADSync

Die Migration hat aus der Quellmailbox einen MailUser gemacht. Der lokale Exchange Server aber hat immer noch eine "RemoteMaibox" und deren TargetAddress verweist in den Quelltenant, wo dann die nächste TargetAddress in den Zieltenant verweist.

Hier sollten Sie das lokale AD-Konto vom Typ "RemoteMailbox" auf "MailUser" mit einer TargetAddress in die Ziel-Cloud konfigurieren. Ansonsten besteht das Risiko, dass bei einer lokalen Änderung durch ADSync in der Cloud die TargetAddress überschrieben wird.

Ziel

CloudOnly

Wenn Sie zur Migration in das Ziel noch keine Konten per ADSync angelegt hatte, dann ist es spätestens nach der Migration erforderlich, das lokale Exchange über den Cloud Empfänger zu informieren. Sie sollten daher im lokalen Exchange einen AD-Benutzer anlegen und als Exchange "RemoteMailbox" einrichten. Dabei sollten sie zumindest alle ProxyAddresses übertragen, damit auch hier zukünftig einen lokale Verwaltung der Exchange Online Mailbox möglich ist.

Ziel

ADSync

War das Konto in der Cloud schon vor der Migration des Postfachs vorhanden, dann wurde es beim Abschluss der Migration von einem "MailUser" zu einer "Mailbox" konvertiert. Davon hat das lokale Exchange noch nichts mitbekommen. Sie sollten daher im lokalen Exchange aus dem MailUser eine "RemoteMailbox" machen.

Beachten sie dazu auch die Seite T2T Exchange Walkthrough

Einschätzung

Wie so oft gibt es lachendes und weinendes Auge. Auf der einen Seite ist es wichtig, dass Microsoft auch für das Cross-Tenant-Szenario eine Lösung anbietet aber auf der anderen Seite gibt es schon noch die ein oder andere Einschränkung, die den Markt für Drittanbieter offen lässt. Zumindest in der ersten Phase werden Firmen doch ihre Probleme mit dem Provisioning der Benutzer, dem Umstellen des Mailroutings und der Profile haben. Vielleicht erweiterte Microsoft (oder ein MVP) hier aber noch das AdminUI mit einem Assistenten oder geführten Einrichtung.

Ich hatte zuerst vermutet, dass die Migration gar nicht über eine Verschiebung der einzelnen Mails erfolgt, sondern vielleicht einfach ein Datenbankeintrag (msExchMailboxGUID) z.B. umgehängt oder sogar an zwei Benutzer gebunden werden könnte. Dann wäre sogar eine parallele Nutzung denkbar. Das geht aber genauso wenig wie ein Sync in bestehende Postfächer.

Die Microsoft-Lösung funktioniert aber im Grunde schon problemlos, auch wenn Sie als Administrator einige Schritte von Hand per PowerShell durchführen müssen.

Weitere Links