T2T Exchange Walkthrough

Seit 1 Nov 2022 hat Microsoft in der Cloud einen Weg bereitgestellt, um Postfächer von einem Tenant zum anderen Tenant umzustellen. Die Anleitung ist aber relativ überschaubar und der FAQ-Bereich eher groß und auf viele Aspekte geht die Anleitung gar nicht ein. Insbesondere nicht auf den Zusammenhang von Mailrouting und beim Hybrid-Betrieb mit ADSync. Denn die Cross Tenant Migration in der Cloud kann weder das lokale On-Premises AD beschreiben noch repliziert ADSync die Änderungen der Cloud-Objekte zurück. Hier sind also Zusatzarbeiten erforderlich.

Dies ist die erste Version einer Beschreibung und ich bin sicher, dass Microsoft die Funktion weiter entwickeln wird. Die hier gemachten Angaben können daher schon wieder überholt oder sogar falsch sein. Sie sollten in ihrer Umgebung eigene Tests ausführen.

Diese Seite ist weniger eine "Schritt für Schritt"-Anleitung sondern soll das Verständnis der Zusammenhänge fördern. Später dürfte diese Seite mit T2T Exchange Online Migration zusammengeführt werden.

Fragestellungen

Die Exchange Migration eines Postfachs von einem Tenant zum anderen Tenant bedeutet erst einmal nur, dass Sie die Postfachinhalte umziehen. Aber da gibt es schon noch einige weitere Fragestellungen, die beantwortet werden müssen, wie z.B.:

Thema Beschreibung Check

Empfängermanagement

Das ist aus meiner Sicht das wichtigste Thema, da jeder Tenant entweder mit CloudOnly oder mit ADSync-Konten arbeiten kann. Wenn zwei Tenants über eine gewisse Zeit parallel laufen, dann möchte an schon z.B.: die Empfänger einer Seite im anderen Tenant als "Kontakte" sehen. Für die Cross Tenant Migration ist es sogar zwingend erforderlich, dass vorher im Ziel schon entsprechende Objekte mit entsprechenden Einstellungen angelegt werden, damit die Migration auch das Ziel kennt.

Die Herausforderung ist nun. welche Objekte wie und von wem angelegt werden. Ein per ADSync aus dem lokalen AD repliziertes Objekte ist in Exchange Online "weitgehend" ReadOnly und ADSync kann Änderungen in der Cloud nicht in das lokale AD zurückschreiben.

Absenderdomain

Normalerweise ist eine SMTP-Domain genau einem Tenant zugewiesen. Wenn ich also Benutzer von der Quelle in das Ziel ohne gleichzeitigen Umzug der Domain migriert habe, dann ist nicht nur deren primäre Adresse eine Domain aus dem Ziel sondern es hat auch keine sekundären Adressen.

Eingehende Mails landen noch im Quell-Tenant, der dann diese per Weiterleitung an das neue Postfach senden muss.

Über die Funktion "SMTP-Domain Sharing (Tenant Domain Sharing) (Preview im Nov 2022) kann aber der Quell-Tenant auch dem Zieltenant erlauben, mit der gleichen SMTP-Adresse zu senden.

Domainumzug

Der Umzug der Domain ist ein ganz eigenes Thema. Ich kann eine Domain nur ganz oder gar nicht umziehen. Mit dem Umzug wechselt sich aber auch der Anmeldenamen, die Teams-Adresse, die OneDrive-URL, lokale Windows-Profile und andere Einstellungen. Sie haben also die Wahl, ob sie die Domain vor, während oder nach dem Postfachzuzug umziehen und die Abhängigkeiten der anderen Applikationen klären.

Beim vorherigen Umzug müssen Sie natürlich im Ziel dann schon alle SMTP-Adressen der Quelle als Objekte mit Umleitungen in die Quelle anlegen.

Mailrouting

Für enge Zusammenspiel der beiden Tenants sind passende Connectoren oder SMTP-Domains zu nutzen. Ich nutze in der Quelle eigentlich immer die "<ziel>.mail.onmicrosoft.com"-Adresse und in der Gegenrichtung aus dem Ziel in die Quelle die "<quelle>-mail.onmicrosoft.com" Adressen, da hier der MX-Record durch Microsoft in die Cloud geht. Dennoch sollten Sie prüfen, ob nicht Hybrid Centralized Mail Transport ihnen Ärger macht.

Über Einstellungen in "RemoteDomains" können Sie auch Anpassungen zu OOF-Meldungen, Formaten ,Weiterleitungen etc. machen.

Koexistenz

Wenn Sie als Zieladressen die "mail.onmicrosoft.com"-Domains nutzen, dann reicht eine reguläre "OrganizationRelationship", damit während der Koexistenz-Phase weiterhin Informationen zu Frei/Belegt-Seiten, Mailtipps etc. genutzt werden können. Ein Stellvertreter-Zugriff auf Postfächer im anderen Tenant ist aber noch nicht möglich.

Die "OrganizationRelationship" ist auch für die Migration erforderlich.

Migrationsbereitschaft

Damit das Ziel sich die Daten aus dem Quell-Tenant saugen kann, muss das Ziel eine Application einrichten, welche in der Quelle zugelassen wird. Weiterhin muss in dem Ziel die Quelle als Migrationendpunkt addiert werden

Lizenzen

Für eine Übergangszeit müssen Sie in beiden Tenants nicht nur Postfachlizenzen vorhalten, sondern auch die Cross-TenantMigration ist eine AddOn-Lizenz1

.

Cross Tenant User Data Migration is available as an add-on to the following Microsoft 365 subscription plans for Enterprise Agreement customers. User licenses are per migration (onetime fee). Please contact your Microsoft account team for details
Microsoft 365 Business Basic/Business Standard/Business Premium/F1/F3/E3/A3/E5/A5; Office 365 F3/E1/A1/E3/A3/E5/A5; Exchange Online; SharePoint Online; OneDrive for Business.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide#licensing

Das sind nur ein ein paar Fragestellungen und die Liste ist sicher nicht komplett.

Für die weitere Betrachtung der Seite gehe ich davon aus, dass die DNS-Domain während einer Cutover-Migration oder nach der Mailmigration umgestellt wird.

ADSync Szenaren

In Verbindung mit ADSync gibt es eigentlich nur drei Szenarien zu betrachten:

  • Die Quelle nutzt ADSync
    Wenn die Ziel ohne ADSync arbeitet, können dort die Platzhalterkonten für die Migration einfach als "CloudOnly"-Konto angelegt und bei der Migration auch konvertiert werden. Allerdings werden die bereits migrierten Postfächer in der Quelle natürlich zu einem Mailuser und im lokalen AD steht immer noch "RemoteMailbox" mit einer Zieladresse in den Quelltenant drin. Diese Inkonsistenz müssen sie manuell pflegen.
  • Das Ziel nutzt ADSync
    Wenn nur das Ziel mit ADSync arbeitet, dann gibt es zwei Varianten, wie sie die Zielkonten anlegen. Beide Wege sind gültig und haben ihre Pro und Cons. Mein Favorit ist aber Option1:
    • Option1: ADSync Mailuser
      Sie legen die Objekte im lokalen AD an und verwalten dort auch alle Eigenschaften. Die Migration macht aber aus dem MailUser in der Cloud eine Mailbox. Sie müssen dann lokal aus dem MailUser eine "RemoteMailbox" mit der passenden TargetAddress machen, damit das System wieder stimmig ist. Insofern funktioniert diese Option auch mit lokalen Exchange Servern
    • Option2: CloudOnly MailUser
      In dem Fall kann die Migration das Objekt in der Cloud komplett verwalten. Auf Dauer brauchen Sie aber auch lokal den Benutzer und legen diesen später als RemoteMailbox im AD an und lassen ADSync ein "SoftMatch" machen. Diese Option funktioniert nicht mit lokalen Exchange Servern, die erst am Ende der Migration von diesen Benutzern erfahren. Der MX-Record muss für diese Option daher in die Cloud verweisen.
  • Beide Typologien nutzen ADSync
    Wenn sowohl die Quelle als auch das Ziel mit ADSync arbeiten, müssen Sie einfach die beiden vorigen Modelle kombinieren, d.h. die Änderungen in Exchange Online im lokalen Exchange nachhalten, damit ADSync einfach das gleiche "schreibt", was eh schon in der Cloud steht.

Wenn sie überhaupt keinen ADSync haben, dann entfallen natürlich jegliche Änderungen in einem lokalen AD. Allerdings sollten Sie auch andere Provisioning-Komponenten berücksichtigen. Es gibt durchaus Umgebungen, in denen Änderungen im lokalen AD oder auch direkt in im AzureAD über 3rd Tools umgesetzt werden. Hier muss die Änderung durch die Migrationstools natürlich auch irgendwie zurückgeliefert werden.

Für die weitere Betrachtung gehe ich davon aus, dass Quelle und Ziel jeweils ADSync mit einem eigenen lokalen AD betreiben. Hier gibt es natürlich noch besondere Varianten, z.B. wenn nur die Tenants migriert werden aber es das gleiche Active Directory bleibt oder es gibt parallel noch eine AD-Kontenmigration mit ADMT -Active Directory Migration Toolkit.

Cutover oder Koexistenz

Ob die Migration sich über mehrere Wochen erstreckt oder an einem Wochenende erfolgt ist für AD und AzureAD-Objekte nicht wirklich relevant. Bei einer Cutover-Migration sparen Sie sich allerdings die Einrichtung einer Koexistenz samt Mailrouting, Frei/Beleg-Zeiten und Einrichtung und Umstellungen von Weiterleitungen. Eine "Stichtagsumstellung mit Fokus auf Exchange Postfächer könnte wie folgt ablaufen.

Zeitraum Aktivitäten

T-30d
  • IT-Fachkräfte informieren
  • Lizenzbeschaffung klären
  • Cross Tenant Migration Lizenz im Ziel kaufen und zuweisen
  • Anwender informieren über Auswirkungen (OneDrive URL, Anmeldung

T-14d
  • Migrationsumgebung einrichten
  • Benutzer im Ziel mit Targetadress und ExchangeGUID anlegen
  • Alle Postfächer bis 99% migrieren
  • Auswertung, wer die DNS-Domain z.B. in Apps nutzt

T-7d
  • Benutzer an Umschalttermin erinnern

T-1d
  • TTL des MX-Record auf 5 Min (300) reduzieren
  • DKIM-Eintrag addieren (Bei SMTP Sharing schon früher)
  • Benutzer an Umschalttermin erinnern

T-1h
  • MX-Record auf einen Host umstellen, die keine Mails annimmt
  • Andere direkte Mailsender an den alten Tenant pausieren

T-0
  • Migration abschließen und auf Ende warten
    ca. 1 Stunde sollte bei <100 Usern ausreichen

T+1h
  • Domain in der Quelle entfernen
    Kann durchaus länger dauern, wenn die Domain als UPN und in Apps verwendet wird

T+2h
  • Eintragen der neue Domain im Ziel
    Achtung: Es kann bis zu 24h dauern, bis alle Backend-Systeme, insbesondere OneDrive etc. korrekt reagieren
  • Update der Empfänger mit ADSync, damit die bisherige SMTP-Adresse und die UPN-Domain passt

T+3h
  • Eingehendes Mailrouting testen
  • MX-Record, DKIM-Eintrag aktualisieren
  • Kontrolle Messagetracking

T+n
  • Willkommensmail an Anwender
    Info, wie sie ggfls. an die alten Daten kommen (onmicrosoft.com-Adresse nach Reaktivierung)
  • Update der Outlook Profile und MDM-Profile und automatische Prozesse
  • Update der Teams Verbindung, auch Teams Room Systems
  • Update der OneDrive Verbindungen
  • Intune-Umstellung der Clients
  • Nachmigration weiterer Daten

Diese Zeitschätzung ist natürlich abhängig von der Menge der Postfächer und Domains. Prüfen Sie vielleicht vorher mit ein paar Testpostfächern und Test-Domains, dass ihre Umstellung wie erwartet funktioniert. Das ist natürlich nur die Kurzfassung, denn natürlich müssen Sie noch die Migration von Mobilgeräten, ggfls. neue Outlook-Profile und die Information an die Mitarbeiter über das neue Konto mit neuem Kennwort übermitteln. Von all den anderen Punkten, z.B. Migration von OneDrive-Dateien, SharePoint-Bibliotheken, Azure Subscriptions, DevOps-Instanzen, Desktop-Mitgliedschaften (Intune) etc. werde ich auf dieser Seite nichts schreiben.

Für die weitere Beschreibung lege ich den Schwerpunkt auf die Exchange Eigenschaften einer Migration am Beispiel einer einzelnen Mailbox. Sie können die Schritte natürlich dann auch für mehrere Postfächer als Batches erweitern.

Ausgangssituation

Wir haben zuerst einmal zwei Tenants mit zwei SMTP-Domains und zwei AD-Forests, die jeweils per ADSync abgeglichen werden. Jede Topologie hat seinen eigenen SMTP-Adressraum und die Quelle wird in das Ziel migriert.

Zur Vereinfachung habe ich nur das eine Postfach eingezeichnet, welches auch migriert wird. Das Postfach ist ein Exchange Online Postfach, welches im lokalen Exchange als "Remote Mailbox" mit einer Weiterleitung zur tenant1.mail.onmicrosoft.com-Adresse ausgestattet ist.

Tenants verbinden

Damit die Migration über einige Wochen möglichst reibungslos verläuft, sollte ich die beiden Domains und Tenants miteinander "verbinden".

Schritt Erledigt

Applikation

Zuerst muss ich eine Application im Ziel-AzureAD anlegen, die ich später im Migration Endpunkt verwende. Mit dieser "AppID" greift dann der MRS als aktiver Part auf den Quelltenant zu. Die App muss ein "ClientSecret" in Form eines Kennworts bekommen und Sie müssen die erforderlichen Berechtigungen eintragen

Migration Endpoint

Mit der AppID und dem ClientSecret lege ich nun einen Migration-Endpunkt im Ziel an, damit der MRS im Ziel weiß, wie er die Quelle erreicht.

if (((Get-OrganizationConfig).isdehydrated) -eq $true) {
    Enable-OrganizationCustomization
}

 Now you can create a new Migration Endpoint with the AzureAD AppId and the ClientSecret as Password.
 #New MigrationEndpoint
$AppId = "<guid der Application>
$ClientSecret = "YourClientSecret"
$Credential = New-Object `
               -TypeName System.Management.Automation.PSCredential `
               -ArgumentList $AppId, (ConvertTo-SecureString -String $ClientSecret -AsPlainText -Force)

New-MigrationEndpoint `
   -RemoteServer outlook.office.com `
   -RemoteTenant "uclabor.onmicrosoft.com" `
   -Credentials $Credential `
   -ExchangeRemoteMove:$true `
   -Name "T2TUCLABOR-MigrationEndpoint" `
   -ApplicationId $AppId

Migrationsberechtigungen

Damit die Cross Tenant Migration möglich ist, muss natürlich das Ziel eine App anlegen und die Quelle diese zulassen. Das Detailvorgehen hat Microsoft beschrieben. Zusätzlich würde ich aber prüfen, ob der migrierende Admin vielleicht auch die Rechte in beiden Umgebungen zum Verwalten der Empfänger bekommt. Zumindest wäre ein "Leserecht" interessant, um die eigenen Objekte mit der anderen Seite abgleichen zu können.

OrganizationRelationship

Das Mailrouting zwischen den Tenants erfolgt über die <tenant>.mail.onmicrosoft.com-Adresse und wenn zwischen den Tenants eine Koexistenz für Frei/Belegzeiten etc. erforderlich ist, dann sollten sie entsprechend "OrganizationRelationships anlegen. Das hat aber weniger mit der Migration an sich zu tun, sondern ist ein Prozess den auch Multi-Tenant-Firmen häufig zum Dauerbetrieb einrichten.

Migrationsendpunkt

Im Ziel definieren Sie, wie die Daten von der Quelle abgerufen werden.

Mailrouting

Wenn Sie keine Connectoren in Exchange Online eingerichtet haben, dann sollte die Zustellung zwischen den Tenants anhand der <tenantname>.mail.onmicrosoft.com-Domain über den MX-Record problemlos funktionieren. Aber mit eigenen OutboundConnectoren, Transportregeln zum Rerouting oder dem Hybrid Centralized Mail Transport kann dies gestört werden. Hier müssen Sie prüfen und ggfls. Connectoren anlegen oder Transportregeln anpassen.

Remote Domains

Neben den Connectoren können Sie über die Einrichtung von "RemoteDomains" weitere Funktionen zwischen den Tenants freischalten, z.B. dass an den anderen Tenant interne OOF-Meldungen gesendet werden und Automatische Weiterleitungen erlaubt sind. Auch kann ein "Trustlevel" über die Parameter "TrustedMailInboundEnabled" und "TrustedMailOutboundEnabled" konfiguriert werden.

SMTP-Sharing

Es gibt mittlerweile die Funktion, dass ein Tenant eine Domain mit einem anderen Tenant teilen kann. Diese Funktion ist wichtig, wenn Anwender in einem Tenant, der die Domain eigentlich nicht besitzt, dennoch mit einer Adresse aus dieser Domain senden können. Dies kann wichtig sein, wenn die Koexistenz länger besteht und die Benutzer auch nach der Migration mit ihrer alten Domain senden sollen.

Je länger und intensiver die Koexistenz-Phase ist, desto mehr Aufwand sollten Sie hier für Konfiguration und Test investieren.

Objekte im Ziel anlegen

Für mein Beispiel starte ich damit, dass die zukünftigen Empfänger im Ziel angelegt werden. In der Quelle sind die Benutzer ja klassische Exchange Online Postfächer, die entweder ein "CloudOnly"-Postfach oder ein per ADSync Objekte haben und im lokalen AD als "RemoteMailbox". Für diese Objekte brauche ich nun im Ziel ein MailUser, der auf die Quelle verweist. Wer also pfiffig ist, besorgt sich aus der Quelle eine Liste der zu migrierenden Benutzer aus Exchange Online mit Get-Mailbox in der Quelle und legt diese im lokalen Exchange Server als MailUser an.

New-Mailuser t2tuser1 -ExternalEmailAddress t2tuser1@source.msxfaq.de

Der Kontakt wird im lokalen AD und dank ADSync auch in der Cloud angelegt und die Zieladresse verweist auf das Quellpostfach im Quell-Tenant.

Rein technisch könnten sie auch jede andere SMTP-Adresse des aktuellen Postfachs nutzen, solange Mails nur passende geroutet werden. Die mail.onmicrosoft.com-Adresse sorgt aber für eine direkte Zustellung in die Cloud.

Der Benutzer im Ziel-AD hat schon einige Properties:

[PS] C:\>get-mailuser t2tuser1 | fl *email*,recipienttype*

ExternalEmailAddress : SMTP:t2tuser1@source.msxfaq.de
EmailAddresses : {smtp:t2tuser1@msxfaqlab.mail.onmicrosoft.com, smtp:t2tuser1@uclabor.de,
SMTP:t2tuser1@source.msxfaq.de}
EmailAddressPolicyEnabled : True
WindowsEmailAddress : t2tuser1@source.msxfaq.de
RecipientType : MailUser
RecipientTypeDetails : MailUser

Allerdings reicht dies noch nicht für die Migration aus. Laut Microsoft muss man im Ziel noch folgende Felder aus der Quelle übertragen:

PrimarySMTPAddress
MailboxGUID
LegacyExchangeDN
Alle X500 EmailAdresses

Aus meiner Sicht sollten Sie aus der Exchange Online Quelle einfach eine Liste der zu migrierenden Benutzer mit den Felder exportieren und im Ziel anlegen:

Microsoft stellt für die Neuanlage von Benutzer ein Musterskript auf bereit

Postfach Migration

Wir legen dann einen Migrationbatch an, um das Postfach in den Ziel-Tenant zu migrieren. Das geht per PowerShell oder einfach im Exchange Admin Center des Ziel-Tenants. Während der Migration ändert sich an den Objekten und den Weiterleitungen erst einmal nichts. Nur das Zielkonto in der Cloud bekommt nun ein Postfach, in welches alle Mails aus der Quelle durch dem Exchange Online MRS repliziert werden.

Diese Migration kann durchaus länger dauern und sie können mehrere Postfächer in einem Migrationbatch zusammenfassen. Denken Sie daran, dass Sie am Ende nur den kompletten Batch abschließen können. Sie sollten also die entsprechenden Personengruppen in einem Batch zusammenfassen. Theoretisch könnten Sie auch für jedes Postfach einen eigenen MigrationBatch anlegen oder alle Postfächer in einem Batch zusammenfassen.

Abschluss

Wenn Sie die Benutzer umschalten wollten, dann beenden Sie den Migrationbatch. Dieser Schritt verändert gleich mehrere Dinge:

  • Ziel: Aus dem MailUser wird eine MailboxUser
    Das ist die notwendige Vorbereitung des Ziels auch neue Nachrichten anzunehmen
  • Ziel: Entfernen der Umleitung zur Quelle
    Damit wird sichergestellt, das keine Mails aus dem Ziel noch in die Quelle zurückgesendet werden
  • Quelle: Eintragen einer Weiterleitung
    Damit das Postfach in der Quelle keine Mails mehr bekommt, wird eine Weiterleitung zum Ziel eingerichtet
  • Quelle: Postfach Schlussreplikation und Rückbau
    Dann wird der Migrationbatch den Zugriff auf die Quelle unterbinden, einmal alle letzten Änderungen ins Ziel übertragen und das Postfach in der Quelle entfernen.

Interessanterweise kann der Migrationbatch die Objekte sowohl im Quell- und Ziel-Exchange Online verändern, obwohl diese durch den ADSync eigentlich gelockt sein sollten.

Die Änderungen im lokalen Active Directory sollten Sie natürlich nun nachholen. Hier gibt es nun zwei Aufgaben:

  • Quelle: RemoteMailbox->MailUser
    Im Exchange der Quelle ist das frühere Postfach in der Cloud immer noch als "RemoteMailbox" definiert. Genau genommen müssen Sie nun aus dem AD-Objekt den RecipientType ändern. Leider habe ich keinen offiziellen Weg gefunden, wie dies einfach möglich ist. Die "mutigen" Administratoren halten nun den ADSync kurz an, löschen die RemoteMailbox um sie als MailUser neu mit der neuen Zieladresse anzulegen. Die ProxyAddresses könnte man sich auch noch merken, wenn sie nicht anhand der Empfängerrichtlinien nicht eh wieder gesetzt werden.
    Wichtig ist in dem Zuge, dass die Zieladresse nun nicht mehr zu der Mailbox im alten Tenant verweist.
# RemoteMailbox entfernen, das Userkonto bleibt natürlich bestehen
Disable-Remotemailbox -identity <id>

# Bestehendes Benutzerkonto als MailUser mit der neuen Zieladresse aktivieren
Enable-MailUser -identity <id> -ExternalEmailAddress user@<zieltenant>.mail.onmicrosoft.com
  • Ziel: MailUser -> RemoteMailbox
    Auch im Ziel sollten Sie aus dem "MailUser" im lokalen Exchange nun eine "RemoteMailbox" machen. Hierfür habe ich aber einen einfachen Weg gefunden. Sie müssen natürlich die Zieladresse korrekt auf den Benutzer im Zieltenant verweisen lassen und nicht auf die alte Zieladresse des Kontakts.
[PS] C:\>get-mailuser t2tuser1 | Enable-RemoteMailbox -RemoteRoutingAddress <user>@<ziel>.mail.onmicrosoft.com

Name            RecipientTypeDetails       RemoteRecipientType
----            --------------------       -------------------
t2tuser1        RemoteUserMailbox          ProvisionMailbox

Nacharbeiten

Der Umzug der Postfächer ist relativ einfach, wenn die Anwender im Ziel eine neue Domain verwenden. Wenn Sie aber mit dem Umzug auch die SMTP-Domain in den anderen Tenant umziehen müssen oder zusätzlich auch noch Microsoft Teams, SharePoint Bibliotheken und OneDrive-Laufwerke zu übernehmen sind, dann steigt der Aufwand und die Komplexität. Denken Sie auch daran, dass Sie die Anwender nach dem Umzug den Anmeldenamen zum Postfach im neuen Tenant verwenden müssen und ActiveSync-Profile auf IOS/Android ebenso angepasst werden müssen, wie Outlook Profile.

For this initial deployment, users will need to rebuild their profile with their new UPN, primary SMTP address and resync OST content.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide#how-do-we-access-outlook-on-day-1-after-the-user-mailbox-is-moved

Microsoft Teams und der OneDrive-Client nutzen im Hintergrund nach der ersten Anmeldung die GUID des Tenants und des Benutzers zur weiteren Anmeldung. Selbst nach dem Umzug der Domain in den anderen Tenant haben sich die Anwender immer noch am alten Tenant angemeldet und als Benutzername wurde dann <userpart>@<alttenant>.onmicrosoft.com als Anmeldename angezeigt. Hier hat es dann auch nur geholfen, die OneDrive-Verbindung zu kappen und neu einzurichten. Auch das Teams-Profil musste komplett neu eingerichtet werden. Hier fehlt also komplett eine Logik, bei der ein migrierter Client auf den neuen Tenant umgeleitet wird.

Weitere Links

Cross-Tenant User Data Migration in Exchange Online
https://www.youtube.com/watch?v=RGb__c9xhSw

Microsoft 365 Cross Tenant Migration- Office 365 Tenant to Tenant Migration Step-by-Step Guide[2023]
https://www.youtube.com/watch?v=x0etGrlWjzE