Mandantenübergreifende Postfachmigration

Häufig benötigen Sie bei Fusionen oder Veräußerungen die Möglichkeit, die Exchange Online Postfächer Ihrer Benutzer in einen neuen Mandanten zu verschieben. Bei der mandantenübergreifenden Postfachmigration können Mandantenadministratoren bekannte Schnittstellen wie Exchange Online PowerShell und MRS verwenden, um Benutzer in ihre neue Organisation zu migrieren.

Administratoren können das Cmdlet New-MigrationBatch verwenden, das über die Verwaltungsrolle Postfächer verschieben verfügbar ist, um mandantenübergreifende Verschiebungen auszuführen.

Benutzer, die migrieren, müssen im Zielmandanten Exchange Online System als MailUsers vorhanden sein, die mit bestimmten Attributen gekennzeichnet sind, um die mandantenübergreifenden Verschiebungen zu ermöglichen. Die Systemverschiebungen für Benutzer, die im Zielmandanten nicht ordnungsgemäß eingerichtet sind, schlagen fehl.

Wenn die Verschiebungen abgeschlossen sind, wird das Quellbenutzerpostfach in einen MailUser konvertiert, und die targetAddress (in Exchange als ExternalEmailAddress dargestellt) wird mit der Routingadresse zum Zielmandanten gestempelt. Dieser Prozess belässt den Legacy-MailUser im Quellmandanten und ermöglicht koexistenz und E-Mail-Routing. Wenn Geschäftsprozesse dies zulassen, kann der Quellmandant den Quell-MailUser entfernen oder ihn in einen E-Mail-Kontakt konvertieren.

Mandantenübergreifende Exchange-Postfachmigrationen werden für Mandanten mit nur Hybrid- oder Cloudumgebungen unterstützt, oder mit einer beliebigen Kombination der beiden.

Dieser Artikel beschreibt den Prozess für mandantenübergreifende Postfachverschiebungen und enthält Anleitungen zum Vorbereiten von Quell- und Zielmandanten für die Exchange Online Postfachinhaltsverschiebungen.

Wichtig

Verwenden Sie dieses Feature nicht, um Postfächer in irgendeinem Halteraum zu migrieren. Das Migrieren von Quellpostfächern für Benutzer im Halteraum wird nicht unterstützt.
Wenn ein Postfach mit diesem Feature mandantenübergreifend migriert wird, werden nur vom Benutzer sichtbare Inhalte im Postfach (E-Mail, Kontakte, Kalender, Aufgaben und Notizen) zum Ziel (Zielmandanten) migriert. Nach erfolgreicher Migration wird das Quellpostfach gelöscht. Dies bedeutet, dass nach der Migration unter keinen Umständen das Quellpostfach im Quellmandanten verfügbar, auffindbar oder zugänglich ist.

Hinweis

Wenn Sie an einer Vorschau unseres neuen Features Domänenfreigabe für E-Mails neben Ihren mandantenübergreifenden Postfachmigrationen interessiert sind, füllen Sie bitte das Formular unter aka.ms/domainsharingpreview aus. Die Domänenfreigabe für E-Mail ermöglicht Benutzern in separaten Microsoft 365-Mandanten das Senden und Empfangen von E-Mails mithilfe von Adressen aus derselben benutzerdefinierten Domäne. Das Feature soll Szenarien lösen, in denen Benutzer in separaten Mandanten eine gemeinsame Unternehmensmarke in ihren E-Mail-Adressen darstellen müssen. Die aktuelle Vorschau unterstützt die unbegrenzte Freigabe von Domänen und freigegebenen Domänen während der mandantenübergreifenden Postfachmigration.

Lizenzierung

Die mandantenübergreifende Benutzerdatenmigration ist als Add-On für die folgenden Microsoft 365-Abonnementpläne für Enterprise Agreement Kunden verfügbar. Benutzerlizenzen gelten pro Migration (einmalige Gebühr). Wenden Sie sich für weitere Informationen an Ihr Microsoft-Team.

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.

Vorbereiten von Quell- und Zielmandanten

Voraussetzungen für Quell- und Zielmandanten

Bevor Sie beginnen, stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen zum Konfigurieren der Anwendung „Postfach verschieben“ in Azure, des EXO-Migrationsendpunkts und der EXO-Organisationsbeziehung verfügen.

Darüber hinaus ist mindestens eine E-Mail-aktivierte Sicherheitsgruppe im Quellmandanten erforderlich. Diese Gruppen werden verwendet, um die Liste der Postfächer zu beschränken, die vom Quellmandanten (oder manchmal auch als Ressourcenmandanten bezeichnet) zum Zielmandanten verschoben werden können. Auf diese Weise kann der Quellmandantenadministrator den spezifischen Satz von Postfächern einschränken oder festlegen, die verschoben werden müssen, um zu verhindern, dass unbeabsichtigte Benutzer migriert werden. Geschachtelte Gruppen werden nicht unterstützt.

Sie müssen auch mit Ihrem vertrauenswürdigen Partnerunternehmen (mit dem Sie Postfächer verschieben) kommunizieren, um dessen Microsoft 365-Mandanten-ID zu erhalten. Diese Mandanten-ID wird im Feld Organisationsbeziehungsdomänenname verwendet.

Um die Mandanten-ID eines Abonnements abzurufen, melden Sie sich beim Microsoft 365 Admin Center an, und wechseln Sie zu https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. Klicken Sie auf das Kopiersymbol für die Eigenschaft Mandanten-ID, um sie in die Zwischenablage zu kopieren.

Stellen Sie sicher, dass alle Benutzer in der Quell- und Zielorganisation mit geeigneten Exchange Online Abonnements lizenziert werden müssen, die für die Organisation gelten. Stellen Sie außerdem sicher, dass die Lizenzen für die mandantenübergreifende Benutzerdatenmigration auch auf alle Benutzer angewendet werden, die auf die Zielseite migriert werden.

Konfigurationsschritte zum Aktivieren Ihrer Mandanten für mandantenübergreifende Postfachmigrationen

Hinweis

Sie müssen zuerst das Ziel konfigurieren. Um diese Schritte auszuführen, müssen Sie nicht über die Mandantenadministratoranmeldeinformationen für den Quell- und Zielmandanten verfügen oder kennen. Die Schritte können für einzeln jeden Mandanten durch verschiedene Administratoren ausgeführt werden.

Vorbereiten des Zielmandanten durch Erstellen der Migrationsanwendung und des Geheimnisses

  1. Melden Sie sich mit den Administratoranmeldeinformationen ihres Zielmandanten bei Ihrem Azure AD-Portal (https://portal.azure.com) an.

    Azure-Anmeldung

  2. Klicken Sie unter "Azure Active Directory verwalten" auf Anzeigen.

    Azure Active Directory-Schaltfläche

  3. Wählen Sie auf der linken Navigationsleiste "App-Registrierungen" aus.

  4. Wählen Sie "Neue Registrierung" aus.

    Neue Anwendung

  5. Wählen Sie auf der Seite "Anwendung registrieren" unter "Unterstützte Kontotypen" die Option "Konten in einem beliebigen Organisationsverzeichnis (Beliebiges Azure AD-Verzeichnis – mehrinstanzenfähig)" aus. Wählen Sie dann unter "Umleitungs-URI (optional)" die Option Web aus, und geben Sie ein https://office.com. Wählen Sie abschließend Registrieren aus.

    Anwendungsregistrierung

  6. In der oberen rechten Ecke der Seite wird ein Benachrichtigungsfenster angezeigt, in dem angegeben wird, dass die App erfolgreich erstellt wurde.

  7. Zurück zu Start, Azure Active Directory, und klicken Sie auf "App-Registrierungen".

  8. Suchen Sie unter "Eigene Anwendungen" die von Ihnen erstellte App, und klicken Sie darauf.

  9. Unter "Essentials" müssen Sie die "Anwendungs-ID (Client)" kopieren, da Sie sie später benötigen, um eine URL für den Zielmandanten zu erstellen.

  10. Klicken Sie nun auf der linken Navigationsleiste auf "API-Berechtigungen", um Berechtigungen anzuzeigen, die Ihrer App zugewiesen sind.

  11. Standardmäßig Benutzer. Leseberechtigungen werden der von Ihnen erstellten App zugewiesen, aber wir benötigen sie nicht für Postfachmigrationen. Sie können diese Berechtigung entfernen.

    Anwendungsberechtigungen

  12. Jetzt müssen wir die Berechtigung für die Postfachmigration hinzufügen, und wählen Sie "Berechtigung hinzufügen" aus.

  13. Wählen Sie im Fenster "API-Berechtigungen anfordern" die Option "APIs, die meine Organisation verwendet", suchen Sie nach "Office 365 Exchange Online", und wählen Sie sie aus.

    API auswählen

  14. Wählen Sie als Nächstes "Anwendungsberechtigungen" aus.

  15. Erweitern Sie dann unter "Berechtigungen auswählen" postfach, und aktivieren Sie "Mailbox.Migration" und "Berechtigungen hinzufügen" unten auf dem Bildschirm.

    API festlegen

  16. Wählen Sie nun in der linken Navigationsleiste für Ihre Anwendung Zertifikatgeheimnisse & aus.

  17. Wählen Sie unter "Geheime Clientschlüssel" die Option "Neuer geheimer Clientschlüssel" aus.

    Geheime Clientschlüssel

  18. Geben Sie im Fenster Geheimen Clientschlüssel hinzufügen eine Beschreibung ein, und konfigurieren Sie die gewünschten Ablaufeinstellungen.

    Hinweis

    Dies ist das Kennwort, das beim Erstellen Ihres Migrationsendpunkts verwendet wird. Es ist äußerst wichtig, dass Sie dieses Kennwort in Ihre Zwischenablage kopieren und oder dieses Kennwort an einen sicheren/geheimen Kennwortspeicherort kopieren. Dies ist das einzige Mal, dass Sie dieses Kennwort sehen können! Wenn Sie es irgendwie verlieren oder zurücksetzen müssen, können Sie sich wieder bei unserem Azure-Portal anmelden, zu App-Registrierungen wechseln, Ihre Migrations-App suchen, Geheimnisse & Zertifikate auswählen und ein neues Geheimnis für Ihre App erstellen.

  19. Nachdem Sie jetzt die Migrationsanwendung und das Geheimnis erfolgreich erstellt haben, müssen Sie der Anwendung zustimmen. Um der Anwendung zuzustimmen, wechseln Sie zurück zur Azure Active Directory-Angebotsseite, klicken Sie im linken Navigationsbereich auf Unternehmensanwendungen, suchen Sie ihre von Ihnen erstellte Migrations-App, wählen Sie sie aus, und wählen Sie im linken Navigationsbereich Berechtigungen aus.

  20. Klicken Sie auf die Schaltfläche "Erteilen der Administratoreinwilligung für [Ihren Mandanten]".

  21. Ein neues Browserfenster wird geöffnet und wählt "Akzeptieren" aus.

  22. Sie können zu Ihrem Portalfenster zurückkehren und Aktualisieren auswählen, um Ihre Annahme zu bestätigen.

  23. Formulieren Sie die URL, die an Ihren vertrauenswürdigen Partner (Mandantenadministrator der Quelle) gesendet werden soll, damit auch er die Anwendung annehmen kann, um die Postfachmigration zu aktivieren. Im Folgenden finden Sie ein Beispiel für die URL, die ihm bereitgestellt werden soll. Sie benötigen die Anwendungs-ID der App, die Sie erstellt haben:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com
    

    Hinweis

    Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App.

    Sie müssen contoso.onmicrosoft.com im obigen Beispiel durch die richtigen onmicrosoft.com Namen Ihrer Quellmandanten ersetzen.

    Außerdem müssen Sie [application_id_of_the_app_you_just_created] durch die Anwendungs-ID der soeben erstellten Postfachmigrations-App ersetzen.

Vorbereiten des Zielmandanten durch Erstellen des Exchange Online-Migrationsendpunkts und der Organisationsbeziehung

  1. Stellen Sie eine Verbindung mit Exchange Online PowerShell im Zielmandanten Exchange Online her.

  2. Erstellen eines neuen Migrationsendpunkts für mandantenübergreifende Postfachverschiebungen

    Hinweis

    Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App und das Kennwort (das Geheimnis), das Sie während dieses Vorgangs konfiguriert haben. Abhängig von der Microsoft 365-Cloudinstanz, die Sie verwenden, kann Ihr Endpunkt auch unterschiedlich sein. Wählen Sie auf der Seite Microsoft 365-Endpunkte die richtige Instanz für Ihren Mandanten aus, und überprüfen Sie die Exchange Online Erforderliche Adresse optimieren und ggf. ersetzen.

    
    # Enable customization if tenant is dehydrated
    $dehydrated=Get-OrganizationConfig | select isdehydrated
    if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
    $AppId = "[guid copied from the migrations app]"
    $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the previous steps]" -AsPlainText -Force)
    New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId
    
  3. Erstellen Sie ein neues Organisationsbeziehungsobjekt, oder bearbeiten Sie ihr vorhandenes Organisationsbeziehungsobjekt zu Ihrem Quellmandanten.

    $sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]"
    $orgrels=Get-OrganizationRelationship
    $existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
    If ($null -ne $existingOrgRel)
    {
        Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound
    }
    If ($null -eq $existingOrgRel)
    {
        New-OrganizationRelationship "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
    }
    

Vorbereiten des Quellmandanten (aktueller Postfachspeicherort), indem Sie die Migrationsanwendung akzeptieren und die Organisationsbeziehung konfigurieren.

  1. Wechseln Sie in einem Browser zu dem URL-Link, der von Ihrem vertrauenswürdigen Partner bereitgestellt wird, um der Postfachmigrationsanwendung zuzustimmen. Die URL sieht wie folgt aus:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com
    

    Hinweis

    Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App. Sie müssen contoso.onmicrosoft.com im obigen Beispiel durch die richtigen onmicrosoft.com Namen Ihrer Quellmandanten ersetzen. Außerdem müssen Sie [application_id_of_the_app_you_just_created] durch die Anwendungs-ID der soeben erstellten Postfachmigrations-App ersetzen.

  2. Akzeptieren Sie die Anwendung, wenn das Popupfenster angezeigt wird. Sie können sich auch bei Ihrem Azure Active Directory-Portal anmelden und die Anwendung unter „Unternehmensanwendungen“ suchen.

  3. Stellen Sie eine Verbindung mit Exchange Online PowerShell auf dem Quellmandanten Exchange Online her.

  4. Erstellen Sie eine neue Organisationsbeziehung, oder bearbeiten Sie ihr vorhandenes Organisationsbeziehungsobjekt zu Ihrem Zielmandanten (Zielmandanten) in Exchange Online PowerShell:

    $targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]"
    $appId="[application id of the mailbox migration app you consented to]"
    $scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]"
    New-DistributionGroup -Type Security -Name $scope
       $orgrels=Get-OrganizationRelationship
    $existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
    If ($null -ne $existingOrgRel)
    {
        Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
    }
    If ($null -eq $existingOrgRel)
    {
        New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
    }
    

Hinweis

Die Mandanten-ID, die Sie als $sourceTenantId und $targetTenantId eingeben, ist die GUID und nicht der Domänenname des Mandanten. Ein Beispiel für eine Mandanten-ID und Informationen zum Suchen Ihrer Mandanten-ID finden Sie unter Suchen Ihrer Microsoft 365-Mandanten-ID.

Woher weiß ich, dass der Vorgang erfolgreich war?

Sie können die mandantenübergreifende Postfachmigrationskonfiguration verifizieren, indem Sie das Cmdlet Test-MigrationServerAvailability auf dem mandantenübergreifenden Migrationsendpunkt ausführen, den Sie auf Ihrem Zielmandanten erstellt haben. Führen Sie das folgende Cmdlet über den Zielmandanten aus:

Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"

Verschieben von Postfächern zurück in die ursprüngliche Quelle

Wenn ein Postfach zurück zum ursprünglichen Quellmandanten verschoben werden muss, müssen die gleichen Schritte und Skripts sowohl in neuen Quell- als auch in neuen Zielmandanten ausgeführt werden. Das vorhandene Organisationsbeziehungsobjekt wird aktualisiert oder angefügt und nicht neu erstellt. Die Migration kann nicht auf beide Arten gleichzeitig erfolgen.

Vorbereiten von Zielbenutzerobjekten für die Migration

Benutzer, die migrieren, müssen im Zielmandanten vorhanden sein und Exchange Online System (als MailUsers) mit bestimmten Attributen gekennzeichnet sein, um die mandantenübergreifenden Verschiebungen zu ermöglichen. Die Systemverschiebungen für Benutzer, die im Zielmandanten nicht ordnungsgemäß eingerichtet sind, schlagen fehl. Im folgenden Abschnitt werden die Anforderungen des MailUser-Objekts für den Zielmandanten ausführlich erläutert.

Voraussetzungen für Zielbenutzerobjekte

Stellen Sie sicher, dass die folgenden Objekte und Attribute in der Zielorganisation festgelegt sind.

Tipp

Microsoft entwickelt ein Feature, um eine sichere automatisierte Methode zum Festlegen vieler Attribute im folgenden Abschnitt bereitzustellen. Dieses Feature namens Mandantenübergreifende Identitätszuordnung sucht derzeit nach Kunden, die bereit sind, an einer kleinen privaten Vorschau teilzunehmen. Weitere Informationen zu dieser Vorabversionsfunktion und wie es Ihre mandantenübergreifenden Migrationsprozesse vereinfachen kann, finden Sie im Artikel Mandantenübergreifende Identitätszuordnung.

  1. Für jedes Postfach, das aus einer Quellorganisation verschoben wird, müssen Sie ein MailUser-Objekt in der Zielorganisation bereitstellen:

    • Target MailUser muss über die folgenden Attribute aus dem Quellpostfach verfügen oder dem neuen User-Objekt zugewiesen sein:

      • ExchangeGUID (direkter Fluss von der Quelle zum Ziel): Die Postfach-GUID muss übereinstimmen. Der Verschiebungsprozess wird nicht fortgesetzt, wenn dies im Zielobjekt nicht vorhanden ist.
      • ArchiveGUID (direkter Fluss von der Quelle zum Ziel): Die Archiv-GUID muss übereinstimmen. Der Verschiebungsprozess wird nicht fortgesetzt, wenn dies im Zielobjekt nicht vorhanden ist. (Dies ist nur erforderlich, wenn das Quellpostfach Archiv aktiviert ist.)
      • LegacyExchangeDN (Flow als proxyAddress, "x500:<LegacyExchangeDN"): Der LegacyExchangeDN> muss auf dem Ziel-MailUser als x500: proxyAddress vorhanden sein. Darüber hinaus müssen Sie auch alle x500-Adressen aus dem Quellpostfach auf den Ziel-E-Mail-Benutzer kopieren. Die Verschiebungsprozesse werden nicht fortgesetzt, wenn diese im Zielobjekt nicht vorhanden sind. Außerdem ist dieser Schritt wichtig, um die Antwortfähigkeit für E-Mails zu ermöglichen, die vor der Migration gesendet werden. Die Absender-/Empfängeradresse in jedem E-Mail-Element und der Cache für die automatische Vervollständigung in Microsoft Outlook und in Microsoft Outlook Web App (OWA) verwenden den Wert des LegacyExchangeDN-Attributs. Wenn ein Benutzer nicht mithilfe des LegacyExchangeDN-Werts gefunden werden kann, schlägt die Zustellung von E-Mail-Nachrichten möglicherweise mit einem NDR 5.1.1 fehl.
      • UserPrincipalName: DER UPN wird an der NEUEN Identität oder dem Zielunternehmen des Benutzers ausgerichtet (z. B user@northwindtraders.onmicrosoft.com. ).
      • Primäre SMTPAddress: Die primäre SMTP-Adresse wird an der NEUEN Firma des Benutzers ausgerichtet (z. B user@northwindtraders.com. ).
      • TargetAddress/ExternalEmailAddress: MailUser verweist auf das aktuelle Postfach des Benutzers, das im Quellmandanten gehostet wird (z. B user@contoso.onmicrosoft.com. ). Vergewissern Sie sich beim Zuweisen dieses Werts, dass Sie auch PrimarySMTPAddress zuweisen. Andernfalls legt dieser Wert die PrimarySMTPAddress fest, was zu Verschiebungsfehlern führt.
      • Sie können keine Legacy-SMTP-Proxyadressen aus dem Quellpostfach zum MailUser-Ziel hinzufügen. Sie können z. B. keine contoso.com auf der MEU in northwindtraders.onmicrosoft.com Mandantenobjekten) verwalten. Domänen sind nur einem Azure AD- oder Exchange Online-Mandanten zugeordnet.

      Beispiel für ein MailUser-Zielobjekt :

      Attribut Wert
      Alias LaraN
      RecipientType MailUser
      RecipientTypeDetails MailUser
      UserPrincipalName LaraN@northwintraders.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@northwindtraders.com
      ExternalEmailAddress SMTP:LaraN@contoso.onmicrosoft.com
      ExchangeGuid 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035Lara
      EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
      Smtp:LaraN@northwindtraders.onmicrosoft.com
      SMTP:Lara.Newton@northwindtraders.com

      Beispiel für das Mailbox-Quellobjekt :

      Attribut Wert
      Alias LaraN
      RecipientType UserMailbox
      RecipientTypeDetails UserMailbox
      UserPrincipalName LaraN@contoso.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@contoso.com
      ExchangeGuid 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara
      EmailAddresses Smtp:LaraN@contoso.onmicrosoft.com
      SMTP:Lara.Newton@contoso.com
    • Möglicherweise sind bereits zusätzliche Attribute im Hybridrückschreiben von Exchange enthalten. Andernfalls sollten sie einbezogen werden.

    • msExchBlockedSendersHash: Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.

    • msExchSafeRecipientsHash: Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.

    • msExchSafeSendersHash : Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.

  2. Wenn die Größe der wiederherstellbaren Elemente des Quellpostfachs größer als unsere Datenbankstandardgröße (30 GB) ist, werden Verschiebungen nicht fortgesetzt, da das Zielkontingent kleiner als die Größe des Quellpostfachs ist. Sie können das MailUser-Zielobjekt aktualisieren, um die ELC-Postfachflags von der Quellumgebung auf das Ziel zu übertragen, wodurch das Zielsystem das Kontingent des MailUser auf 100 GB erhöht, wodurch die Verschiebung zum Ziel ermöglicht wird. In einer Hybridumgebung müssen Sie die entsprechenden msExchELCMailboxFlags auf dem Ziel-ADUser festlegen.

  3. Nicht hybride Zielmandanten können das Kontingent im Ordner "Wiederherstellbare Elemente" für die MailUsers vor der Migration ändern, indem sie den folgenden Befehl ausführen, um das Beweissicherungsverfahren für das MailUser-Zielobjekt zu aktivieren und das Kontingent auf 100 GB zu erhöhen:

    Set-MailUser -Identity <MailUserIdentity> -EnableLitigationHoldForMigration
    

    Beachten Sie, dass dies für Mandanten in Hybridumgebungen nicht funktioniert.

  4. Benutzer in der Zielorganisation müssen mit entsprechenden Exchange Online-Abonnements lizenziert sein, die für die Organisation gelten. Sie können eine Lizenz vor dem Verschieben eines Postfachs anwenden, aber NUR, wenn der MailUser-Zielbenutzer ordnungsgemäß mit ExchangeGUID und Proxyadressen eingerichtet wurde. Das Anwenden einer Lizenz, bevor exchangeGUID angewendet wird, führt zu einem neuen Postfach, das in der Zielorganisation bereitgestellt wird. Außerdem müssen Sie eine mandantenübergreifende Lizenz für die Benutzerdatenmigration anwenden. Andernfalls wird möglicherweise ein vorübergehender Fehler angezeigt, der besagt, dass eine Genehmigung erforderlich ist und im Verschiebungsbericht eine Warnung meldet, dass keine Lizenz auf den Zielbenutzer angewendet wird.

    Hinweis

    Wenn Sie eine Lizenz auf ein Mailbox- oder MailUser-Objekt anwenden, werden alle SMTP-ProxyAddresses bereinigt, um sicherzustellen, dass nur verifizierte Domänen in das Exchange EmailAddresses-Array aufgenommen werden.

  5. Sie müssen sicherstellen, dass das MailUser-Ziel keine vorherige ExchangeGuid aufweist, die nicht mit der Quell-ExchangeGuid übereinstimmt. Dies kann vorkommen, wenn die Ziel-MEU zuvor für Exchange Online lizenziert und ein Postfach bereitgestellt wurde. Wenn der MailUser-Zielbenutzer zuvor für lizenziert war oder über eine ExchangeGuid verfügte, die nicht mit der Quell-ExchangeGuid übereinstimmt, müssen Sie eine Bereinigung der Cloud-MEU durchführen. Für diese Cloud-MEUs können Sie ausführen Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

    Vorsicht

    Dieser Vorgang ist irreversibel. Wenn das Objekt über ein softDeleted-Postfach verfügt, kann es nach diesem Punkt nicht wiederhergestellt werden. Nach dem Löschen können Sie jedoch die richtige ExchangeGuid mit dem Zielobjekt synchronisieren, und MRS verbindet das Quellpostfach mit dem neu erstellten Zielpostfach. (Verweisen Sie auf den EHLO-Blog zum neuen Parameter.)

    Suchen Sie mit diesem Befehl nach Objekten, die zuvor Postfächer waren.

    Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize
    

    Hier ein Beispiel:

    Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize
    
    Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
    ----       ---------------------------- ------------- --------------------
    John       UserMailbox                  MailUser      MailUser
    

    Löschen Sie das vorläufig gelöschte Postfach mit diesem Befehl.

    Set-User <identity> -PermanentlyClearPreviousMailboxInfo
    

    Hier ein Beispiel:

    Set-User John@northwindtraders.com -PermanentlyClearPreviousMailboxInfo -Confirm
    
    Are you sure you want to perform this action?
    Delete all existing information about user "John@northwindtraders.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY.
    Do you want to continue?
    [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y
    

Durchführen von Postfachmigrationen

Mandantenübergreifende Exchange-Postfachmigrationen werden vom Zielmandanten als Migrationsbatches initiiert. Dies ist mit der Funktionsweise von Onboarding-Migrationsbatches bei der Migration von exchange lokal zu Microsoft 365 vergleichbar.

Erstellen von Migrationsbatches

Hier sehen Sie ein Beispiel für ein Migrationsbatch-Cmdlet zum Starten von Verschiebungen.

New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com

Identity                   Status  Type               TotalCount
--------                   ------  ----               ----------
T2Tbatch                   Syncing ExchangeRemoteMove 1

Hinweis

Die E-Mail-Adresse in der CSV-Datei muss die im Zielmandanten angegebene sein (z. B userA@northwindtraders.onmicrosoft.com. ), nicht die E-Mail-Adresse im Quellmandanten.

Weitere Informationen zum Cmdlet finden Sie hier.

Klicken Sie hier, um ein Beispiel für CSV-Dateiinformationen zu erhalten.

Es folgt eine minimale BEISPIEL-CSV-Datei:

EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com

Die Übermittlung von Migrationsbatches wird auch über das neue Exchange Admin Center unterstützt, wenn Sie die mandantenübergreifende Option auswählen.

Aktualisieren lokaler MailUsers

Sobald das Postfach von der Quelle zum Ziel verschoben wird, sollten Sie sicherstellen, dass die lokalen E-Mail-Benutzer sowohl in der Quelle als auch im Ziel mit der neuen targetAddress aktualisiert werden. In den Beispielen ist die bei der Verschiebung verwendete targetDeliveryDomain northwindtraders.onmicrosoft.com. Aktualisieren Sie die E-Mail-Benutzer mit dieser targetAddress.

Entfernen von Endpunkten und Organisationsbeziehungen nach der Migration

Verwenden Sie das Cmdlet Remove-MigrationEndpoint(/powershell/module/exchange/remove-migrationendpoint), um vorhandene Migrationsendpunkte für Quell- oder Zielserver nach Abschluss der Migration zu entfernen.

Verwenden Sie das Cmdlet Remove-OrganizationRelationship (/exchange/sharing/organization-relationships/remove-an-organization-relationship#use-exchange-online-powershell-to-remove-an-organization-relationship), um vorhandene Organisationsbeziehungen für Quell- oder Zielserver nach Abschluss der Migration zu entfernen.

Häufig gestellte Fragen

Müssen remoteMailboxes in der lokalen Quelle nach dem Verschieben aktualisiert werden?

Ja, Sie sollten targetAddress (RemoteRoutingAddress/ExternalEmailAddress) der lokalen Quellbenutzer aktualisieren, wenn das Postfach des Quellmandanten in den Zielmandanten verschoben wird. Während das E-Mail-Routing den Empfehlungen für mehrere E-Mail-Benutzer mit unterschiedlichen targetAddresses folgen kann, müssen Frei/Gebucht-Lookups für E-Mail-Benutzer auf den Speicherort des Postfachbenutzers ausgerichtet sein. Frei/Gebucht-Lookups verfolgen nicht mehrere Umleitungen.

Werden Teams-Besprechungen mandantenübergreifend migriert?

Die Besprechungen werden verschoben, die Teams-Besprechungs-URL wird jedoch nicht aktualisiert, wenn Elemente mandantenübergreifend migriert werden. Da die URL im Zielmandanten ungültig ist, müssen Sie die Teams-Besprechungen entfernen und neu erstellen.

Wird der Inhalt des Teams-Chatordners mandantenübergreifend migriert?

Nein, der Inhalt des Teams-Chatordners wird nicht mandantenübergreifend migriert. Wenn ein Postfach mandantenübergreifend mit diesem Feature migriert wird, werden nur benutzerseitig sichtbare Inhalte im Postfach (E-Mail, Kontakte, Kalender, Aufgaben und Notizen) migriert.

Wie kann ich nur Umzüge sehen, die mandantenübergreifende Verschiebungen sind, nicht meine Onboarding- und Offboarding-Umzüge?

Verwenden Sie den Flags-Parameter . Hier ein Beispiel:

Get-MoveRequest -Flags "CrossTenant"

Können Sie Beispielskripts zum Kopieren von Attributen bereitstellen, die beim Testen verwendet werden?

Hinweis

SAMPLE – AS IS, NO WARRANTY Dieses Skript setzt eine Verbindung mit dem Quellpostfach (zum Abrufen von Quellwerten) und dem Ziel lokales Active Directory Domain Services (zum Stempeln des ADUser-Objekts) voraus.

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the northwindtraders tenant
$outFileUsers = "$home\desktop\UsersToMigrate.txt"
$outFileUsersXML = "$home\desktop\UsersToMigrate.xml"
Get-Mailbox -Filter "CustomAttribute1 -like 'Cross-Tenant-Project'" -ResultSize Unlimited | Select-Object -ExpandProperty  Alias | Out-File $outFileUsers
$mailboxes = Get-Content $outFileUsers
$mailboxes | ForEach-Object {Get-Mailbox $_} | Select-Object PrimarySMTPAddress,Alias,SamAccountName,FirstName,LastName,DisplayName,Name,ExchangeGuid,ArchiveGuid,LegacyExchangeDn,EmailAddresses | Export-Clixml $outFileUsersXML
# Copy the file $outfile to the desktop of the target on-premises then run the below to create MEU in Target
$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
add-type -AssemblyName System.Web
foreach ($m in $mailboxes) {
    $organization = "@contoso.onmicrosoft.com"
    $mosi = $m.Alias+$organization
    $Password = [System.Web.Security.Membership]::GeneratePassword(16,4) | ConvertTo-SecureString -AsPlainText -Force
    $x500 = "x500:" +$m.LegacyExchangeDn
    $tmpUser = New-MailUser -MicrosoftOnlineServicesID $mosi -PrimarySmtpAddress $mosi -ExternalEmailAddress $m.PrimarySmtpAddress -FirstName $m.FirstName -LastName $m.LastName -Name $m.Name -DisplayName $m.DisplayName -Alias $m.Alias -Password $Password
    $tmpUser | Set-MailUser -EmailAddresses @{add=$x500} -ExchangeGuid $m.ExchangeGuid -ArchiveGuid $m.ArchiveGuid -CustomAttribute1 "Cross-Tenant-Project"
    $tmpx500 = $m.EmailAddresses | ?{$_ -match "x500"}
    $tmpx500 | %{Set-MailUser $m.Alias -EmailAddresses @{add="$_"}}
    }
# Now sync the changes from On-Premises to Azure and Exchange Online in the Target tenant
# This action should create the target mail enabled users (MEUs) in the Target tenant
Start-ADSyncSyncCycle

Wie greifen wir auf Outlook an Tag 1 zu, nachdem das Benutzerpostfach verschoben wurde?

Da nur ein Mandant eine Domäne besitzen kann, wird die frühere primäre SMTPAddress nicht dem Benutzer im Zielmandanten zugeordnet, wenn die Postfachverschiebung abgeschlossen ist. nur die Domänen, die dem neuen Mandanten zugeordnet sind. Outlook verwendet den neuen UPN des Benutzers, um sich beim Dienst zu authentifizieren, und das Outlook-Profil erwartet, dass die ältere primäre SMTPAddress gefunden wird, die mit dem Postfach im Zielsystem übereinstimmt. Da sich die Legacyadresse nicht im Zielsystem befindet, stellt das Outlook-Profil keine Verbindung her, um das neu verschobene Postfach zu finden.

Für diese erste Bereitstellung müssen Benutzer ihr Profil mit ihrem neuen UPN, der primären SMTP-Adresse und dem neu synchronisierten OST-Inhalt neu erstellen.

Hinweis

Planen Sie entsprechend, während Sie Ihre Benutzer für die Fertigstellung in Batches stapeln. Sie müssen die Netzwerkauslastung und -kapazität berücksichtigen, wenn Outlook-Clientprofile erstellt und nachfolgende OST- und OAB-Dateien auf Clients heruntergeladen werden.

In welchen Exchange RBAC-Rollen muss ich Mitglied sein, um eine mandantenübergreifende Verschiebung einzurichten oder abzuschließen?

Es gibt eine Matrix von Rollen, die auf der Annahme delegierter Aufgaben beim Ausführen einer Postfachverschiebung basiert. Derzeit sind zwei Rollen erforderlich:

  • Die erste Rolle ist für eine einmalige Einrichtungsaufgabe, die die Autorisierung zum Verschieben von Inhalten in oder aus Ihrer Mandanten-/Organisationsgrenze festlegt. Da das Verschieben von Daten aus der Kontrolle Ihrer Organisation ein wichtiges Anliegen für alle Unternehmen ist, haben wir uns für die höchste zugewiesene Rolle des Organisationsadministrators (OrgAdmin) entschieden. Diese Rolle muss eine neue OrganizationRelationship ändern oder einrichten, die -MailboxMoveCapability mit der Remoteorganisation definiert. Nur der OrgAdmin kann die Einstellung MailboxMoveCapability ändern, während andere Attribute in der OrganizationRelationship vom Verbundfreigabeadministrator verwaltet werden können.

  • Die Rolle der Ausführung der tatsächlichen Verschiebungsbefehle kann an eine Funktion auf niedrigerer Ebene delegiert werden. Die Rolle von Postfächer verschieben wird der Funktion zum Verschieben von Postfächern in oder aus der Organisation zugewiesen.

Wie legen wir fest, welche SMTP-Adresse für targetAddress (TargetDeliveryDomain) für das konvertierte Postfach ausgewählt ist (in MailUser-Konvertierung)?

Exchange-Postfach wird mithilfe von MRS verschoben, um die targetAddress für das ursprüngliche Quellpostfach zu erstellen, wenn Sie in einen MailUser konvertieren, indem Sie eine E-Mail-Adresse (proxyAddress) für das Zielobjekt abgleichen. Der Prozess verwendet den -TargetDeliveryDomain-Wert, der an den Move-Befehl übergeben wird, und sucht dann auf der Zielseite nach einem übereinstimmenden Proxy für diese Domäne. Wenn wir eine Übereinstimmung finden, wird die übereinstimmende proxyAddress verwendet, um die ExternalEmailAddress (targetAddress) für das konvertierte Postfachobjekt (jetzt MailUser) festzulegen.

Wie funktioniert der Nachrichtenfluss nach der Migration?

Der mandantenübergreifende E-Mail-Fluss nach der Migration funktioniert ähnlich wie der Exchange-Hybrid-E-Mail-Fluss. Jedes migrierte Postfach benötigt den MailUser-Quellbenutzer mit der richtigen targetaddress, um eingehende E-Mails vom Quellmandanten an Postfächer im Zielmandanten weiterzuleiten. Transportregeln, Sicherheits- und Konformitätsfeatures werden in jedem Mandanten, den die E-Mail durchläuft, wie konfiguriert ausgeführt. Für eingehende E-Mails werden Features wie Antispam, Antischadsoftware, Quarantäne sowie Transportregeln und Journalregeln zuerst im Quellmandanten und dann im Zielmandanten ausgeführt.

Wie werden Postfachberechtigungen übergangen?

Postfachberechtigungen umfassen Senden im Auftrag von und Postfachzugriff:

  • Send On Behalf Of (AD:publicDelegates) speichert den DN von Empfängern mit Zugriff auf das Postfach eines Benutzers als Stellvertretung. Dieser Wert wird in Active Directory gespeichert und wird derzeit nicht im Rahmen des Postfachübergangs verschoben. Wenn für das Quellpostfach publicDelegates festgelegt ist, müssen Sie die publicDelegates im Zielpostfach neu stempeln, sobald die Konvertierung von MEU in Mailbox in der Zielumgebung durch Ausführen Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>von abgeschlossen ist.

  • Postfachberechtigungen, die im Postfach gespeichert sind, werden mit dem Postfach verschoben, wenn sowohl der Prinzipal als auch der Delegat in das Zielsystem verschoben werden. Dem Benutzer TestUser7 wird beispielsweise FullAccess auf das Postfach gewährt, das im Mandanten TestUser_8 SourceCompany.onmicrosoft.com. Nachdem die Postfachverschiebung in TargetCompany.onmicrosoft.com abgeschlossen ist, werden die gleichen Berechtigungen im Zielverzeichnis eingerichtet. Beispiele für die Verwendung von _Get-MailboxPermission für TestUser_7 in Quell- und Zielmandanten sind unten dargestellt. Exchange-Cmdlets erhalten das Präfix quelle und ziel entsprechend.

Hier sehen Sie ein Beispiel für die Ausgabe der Postfachberechtigung vor einer Verschiebung von der Quellseite.

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@contoso.onmicrosoft.com               {FullAccess}                         False       False

Hier sehen Sie ein Beispiel für die Ausgabe der Postfachberechtigung nach dem Verschieben von der Zielseite.

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@northwindtraders.onmicrosoft.com      {FullAccess}                         False       False

Hinweis

Mandantenübergreifende Postfach- und Kalenderberechtigungen werden NICHT unterstützt. Sie müssen Prinzipale und Delegaten in konsolidierten Verschiebungsbatches organisieren, damit diese verbundenen Postfächer gleichzeitig vom Quellmandanten übertragen werden.

Welcher X500-Proxy sollte den MailUser-Zielproxyadressen hinzugefügt werden, um die Migration zu ermöglichen?

Die mandantenübergreifende Postfachmigration erfordert, dass der LegacyExchangeDN-Wert des Quellpostfachobjekts als x500-E-Mail-Adresse im MailUser-Zielobjekt gestempelt wird.

Beispiel:

LegacyExchangeDN value on source mailbox is:
/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara

so, the x500 email address to be added to target MailUser object would be:
x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara

Hinweis

Zusätzlich zu diesem X500-Proxy müssen Sie alle X500-Proxys aus dem Postfach in der Quelle in das Postfach im Ziel kopieren.

Können Quell- und Zielmandanten denselben Domänennamen verwenden?

Nein, die Domänennamen des Quellmandanten und des Zielmandanten müssen eindeutig sein. Beispielsweise eine Quelldomäne von contoso.com und die Zieldomäne von northwindtraders.com.

Werden freigegebene Postfächer verschoben und funktionieren sie weiterhin?

Ja, wir behalten jedoch nur die Store-Berechtigungen, wie in diesen Artikeln beschrieben:

Haben Sie Empfehlungen für Batches?

Überschreiten Sie nicht mehr als 2000 Postfächer pro Batch. Es wird dringend empfohlen, Batches zwei Wochen vor dem Übernahmedatum zu übermitteln, da es während der Synchronisierung keine Auswirkungen auf die Endbenutzer gibt. Wenn Sie Anleitungen für Postfachmengen über 50.000 benötigen, können Sie sich unter an die Verteilerliste für Technisches Feedback wenden crosstenantmigrationpreview@service.microsoft.com.

Was geschieht, wenn ich die Dienstverschlüsselung mit Kundenschlüssel verwende?

Das Postfach wird vor dem Verschieben entschlüsselt. Stellen Sie sicher, dass der Kundenschlüssel im Zielmandanten konfiguriert ist, wenn er noch erforderlich ist. Weitere Informationen finden Sie hier .

Wie lange wird die Migration geschätzt?

Um Ihnen bei der Planung Ihrer Migration zu helfen, enthält die hier gezeigte Tabelle die Richtlinien dazu, wann Massenpostfachmigrationen oder einzelne Migrationen zu erwarten sind. Diese Schätzungen basieren auf einer Datenanalyse früherer Kundenmigrationen. Da jede Umgebung einzigartig ist, kann ihre genaue Migrationsgeschwindigkeit variieren.

Schützen von Dokumenten im Quellmandanten, die von Benutzern im Zielmandanten genutzt werden können.**

Bei der mandantenübergreifenden Migration werden nur Postfachdaten und nichts anderes migriert. Es gibt mehrere weitere Optionen, die im folgenden Blogbeitrag dokumentiert sind und hilfreich sein können: https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

Kann ich im Zielmandanten dieselben Bezeichnungen wie im Quellmandanten verwenden, entweder als einziger Satz von Bezeichnungen oder als zusätzlicher Satz von Bezeichnungen für die migrierten Benutzer je nach Ausrichtung zwischen den Organisationen.**

Da bei mandantenübergreifenden Migrationen keine Bezeichnungen exportiert werden und es keine Möglichkeit gibt, Bezeichnungen zwischen Mandanten freizugeben, können Sie dies nur erreichen, indem Sie die Bezeichnungen im Zielmandanten neu erstellen.

Unterstützen Sie das Verschieben von Microsoft 365-Gruppen?

Derzeit unterstützt das Feature mandantenübergreifende Postfachmigrationen die Migration von Microsoft 365-Gruppen nicht.

Kann ein Quellmandantenadministrator eine eDiscovery-Suche für ein Postfach durchführen, nachdem das Postfach zum neuen/Zielmandanten migriert wurde?

Nein, nach einer mandantenübergreifenden Postfachmigration funktioniert eDiscovery für das Postfach des migrierten Benutzers in der Quelle nicht. Dies liegt daran, dass in der Quelle kein Postfach mehr vorhanden ist, nach dem gesucht werden kann, da das Postfach zum Zielmandanten migriert wurde und nun zum Zielmandanten gehört. eDiscovery, post mailbox migration can only be done in the target tenant (where the mailbox now exists). Wenn eine Kopie des Quellpostfachs nach der Migration im Quellmandanten beibehalten werden muss, kann der Administrator in der Quelle den Inhalt vor der Migration in ein alternatives Postfach kopieren, um zukünftige eDiscovery-Vorgänge anhand der Daten durchzuführen.

An welchem Punkt wird der MailUser-Zielbenutzer in ein Zielpostfach und das Quellpostfach in einen MailUser-Quellpostfach konvertiert?

Diese Konvertierungen erfolgen automatisch während des Migrationsprozesses. Es sind keine manuellen Schritte erforderlich.

In welchem Schritt sollte ich die Exchange Online-Lizenz ziel-MailUsers zuweisen?

Dies kann vor Abschluss der Migration erfolgen. Sie sollten jedoch vor dem Stempeln des ExchangeGuid-Attributs keine Lizenz zuweisen. Andernfalls schlägt die Konvertierung des MailUser-Objekts in das Postfach fehl, und stattdessen wird ein neues Postfach erstellt. Um dieses Risiko zu minimieren, ist es am besten, bis nach Abschluss der Migration zu warten und Lizenzen während der 30-tägigen Toleranzperiode zuzuweisen.

Kann ich Azure AD Connect verwenden, um Benutzer mit dem neuen Mandanten zu synchronisieren, wenn ich das lokale Active Directory behalte?

Ja. Es ist möglich, dass zwei Instanzen von Azure AD Connect mit verschiedenen Mandanten synchronisiert werden. Es gibt jedoch einige Dinge, die Sie beachten müssen.

  • Die Vorabbereitstellung der Benutzerkonten mit dem in diesem Artikel bereitgestellten Skript sollte nicht erfolgen. Stattdessen kann eine selektive OE-Synchronisierung der Benutzer im Bereich der Migration durchgeführt werden, um den Zielmandanten aufzufüllen. Sie erhalten eine Warnung, dass der UPN während der Azure AD Connect-Konfiguration nicht übereinstimmt.
  • Abhängig von Ihrem aktuellen Status von Hybrid Exchange müssen Sie überprüfen, ob die lokalen Verzeichnisobjekte die erforderlichen Attribute (z. B. msExchMailboxGUID und proxyAddresses) ordnungsgemäß aufgefüllt haben, bevor Sie versuchen, eine Synchronisierung mit einem anderen Mandanten durchzuführen. Andernfalls treten Probleme mit doppelten Postfächern und Migrationsfehlern auf.
  • Sie müssen einige zusätzliche Schritte ausführen, um den UPN-Übergang zu verwalten und ihn lokal zu ändern, nachdem die Migration für einen Benutzer abgeschlossen wurde, es sei denn, Sie verschieben auch die benutzerdefinierte Domäne während einer Übernahmemigration.

Bekannte Probleme

  • Problem: Die Funktionen von Teams nach der Migration im Quellmandanten sind eingeschränkt. Nachdem das Postfach zum Zielmandanten migriert wurde, hat Teams im Quellmandanten keinen Zugriff mehr auf das Postfach des Benutzers. Wenn sich ein Benutzer also mit den Anmeldeinformationen des Quellmandanten bei Teams anmeldet, geht die Funktionalität verloren, z. B. weil sie ihr Profilbild nicht aktualisieren können, keine Kalenderanwendung und die Unfähigkeit, öffentliche Teams zu durchsuchen und diesen beizutreten.

  • Problem: Automatisch erweiterte Archive können nicht migriert werden. Das feature für die mandantenübergreifende Migration unterstützt Migrationen des primären Postfachs und des Archivpostfachs für einen bestimmten Benutzer. Wenn der Benutzer in der Quelle jedoch über ein automatisch erweitertes Archiv verfügt , d. h. mehr als ein Archivpostfach, kann das Feature die zusätzlichen Archive nicht migrieren und sollte fehlschlagen.

  • Problem: Cloud MailUsers with non-owned smtp proxyAddress block MRS verschiebt hintergrund. Beim Erstellen von MailUser-Objekten des Zielmandanten müssen Sie sicherstellen, dass alle SMTP-Proxyadressen zur Organisation des Zielmandanten gehören. Wenn eine SMTP-proxyAddress für den E-Mail-Zielbenutzer vorhanden ist, der nicht zum lokalen Mandanten gehört, wird die Konvertierung von MailUser in Mailbox verhindert. Dies ist auf unsere Zusicherung zurückzuführen, dass Postfachobjekte E-Mails nur von Domänen senden können, für die der Mandant autoritativ ist (Domänen, die vom Mandanten beansprucht werden):

    • Wenn Sie Benutzer aus der lokalen Umgebung mithilfe von Azure AD Connect synchronisieren, stellen Sie lokale MailUser-Objekte mit ExternalEmailAddress bereit, die auf den Quellmandanten verweist, in dem das Postfach vorhanden ist (LaraN@contoso.onmicrosoft.com), und Sie stempeln die PrimarySMTPAddress als Domäne, die sich im Zielmandanten befindet (Lara.Newton@northwindtraders.com). Diese Werte werden mit dem Mandanten synchronisiert, und ein entsprechender E-Mail-Benutzer wird bereitgestellt und bereit für die Migration. Ein Beispielobjekt wird hier gezeigt.

      Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses
      
      ExternalEmailAddress               EmailAddresses
      --------------------               --------------
      SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}
      

    Hinweis

    Die contoso.onmicrosoft.com Adresse ist im Array EmailAddresses/proxyAddresses nicht vorhanden.

  • Problem: MailUser-Objekte mit "externen" primären SMTP-Adressen werden geändert/auf "interne" vom Unternehmen beanspruchte Domänen zurückgesetzt

    MailUser-Objekte sind Zeiger auf nicht lokale Postfächer. Bei mandantenübergreifenden Postfachmigrationen verwenden wir MailUser-Objekte, um entweder das Quellpostfach (aus sicht der Zielorganisation) oder das Zielpostfach (aus der Perspektive der Quellorganisation) darzustellen. Die MailUsers verfügen über eine ExternalEmailAddress (targetAddress), die auf die SMTP-Adresse des tatsächlichen Postfachs (ProxyTest@northwindtraders.onmicrosoft.com) verweist, und die primäreSMTP-Adresse, die die angezeigte SMTP-Adresse des Postfachbenutzers im Verzeichnis darstellt. Einige Organisationen entscheiden sich dafür, die primäre SMTP-Adresse als externe SMTP-Adresse anzuzeigen, nicht als Adresse im Besitz des lokalen Mandanten (z. B. northwindtraders.com und nicht als contoso.com). Sobald jedoch ein Exchange-Dienstplanobjekt über Lizenzierungsvorgänge auf mailUser angewendet wird, wird die primäre SMTP-Adresse so geändert, dass sie als von der lokalen Organisation überprüfte Domäne angezeigt wird (contoso.com). Es gibt zwei mögliche Gründe:

    • Wenn ein Exchange-Dienstplan auf einen MailUser angewendet wird, beginnt der Azure AD-Prozess, proxybereinigung zu erzwingen, um sicherzustellen, dass die lokale Organisation keine E-Mails von einem anderen Mandanten senden kann. Jede SMTP-Adresse in einem Empfängerobjekt mit diesen Serviceplänen wird entfernt, wenn die Adresse nicht von der lokalen Organisation überprüft wird. Wie im Beispiel wird die Fabikam.com Domäne NICHT vom contoso.onmicrosoft.com Mandanten überprüft, sodass diese northwindtraders.com Domäne durch die Bereinigung entfernt wird. Wenn Sie diese externen Domänen entweder vor der Migration oder nach der Migration auf MailUser beibehalten möchten, müssen Sie Ihre Migrationsprozesse so ändern, dass lizenzen nach Abschluss der Verschiebung oder vor der Verschiebung entfernt werden, um sicherzustellen, dass für die Benutzer das erwartete externe Branding angewendet wird. Sie müssen sicherstellen, dass das Postfachobjekt ordnungsgemäß lizenziert ist, damit es sich nicht auf den E-Mail-Dienst auswirkt.

    • Ein Beispielskript zum Entfernen der Dienstpläne für einen MailUser im contoso.onmicrosoft.com Mandanten finden Sie hier.

      $LO = New-MsolLicenseOptions -AccountSkuId "contoso:ENTERPRISEPREMIUM" DisabledPlans "LOCKBOX_ENTERPRISE","EXCHANGE_S_ENTERPRISE","INFORMATION_BARRIERS","MIP_S_CLP2","MIP_S_CLP1","MYANALYTICS_P2","EXCHANGE_ANALYTICS","EQUIVIO_ANALYTICS","THREAT_INTELLIGENCE","PAM_ENTERPRISE","PREMIUM_ENCRYPTION"
      Set-MsolUserLicense -UserPrincipalName ProxyTest@contoso.com LicenseOptions $lo
      

      Die Ergebnisse im Satz zugewiesener ServicePlans werden hier angezeigt.

      (Get-MsolUser -UserPrincipalName ProxyTest@contoso.com).licenses | Select-Object -ExpandProperty ServiceStatus |sort ProvisioningStatus -Descending
      
      ServicePlan           ProvisioningStatus
      -----------           ------------------
      ATP_ENTERPRISE        PendingProvisioning
      MICROSOFT_SEARCH      PendingProvisioning
      INTUNE_O365           PendingActivation
      PAM_ENTERPRISE        Disabled
      EXCHANGE_ANALYTICS    Disabled
      EQUIVIO_ANALYTICS     Disabled
      THREAT_INTELLIGENCE   Disabled
      LOCKBOX_ENTERPRISE    Disabled
      PREMIUM_ENCRYPTION    Disabled
      EXCHANGE_S_ENTERPRISE Disabled
      INFORMATION_BARRIERS  Disabled
      MYANALYTICS_P2        Disabled
      MIP_S_CLP1            Disabled
      MIP_S_CLP2            Disabled
      ADALLOM_S_O365        PendingInput
      RMS_S_ENTERPRISE      Success
      YAMMER_ENTERPRISE     Success
      PROJECTWORKMANAGEMENT Success
      BI_AZURE_P2           Success
      WHITEBOARD_PLAN3      Success
      SHAREPOINTENTERPRISE  Success
      SHAREPOINTWAC         Success
      KAIZALA_STANDALONE    Success
      OFFICESUBSCRIPTION    Success
      MCOSTANDARD           Success
      Deskless              Success
      STREAM_O365_E5        Success
      FLOW_O365_P3          Success
      POWERAPPS_O365_P3     Success
      TEAMS1                Success
      MCOEV                 Success
      MCOMEETADV            Success
      BPOS_S_TODO_3         Success
      FORMS_PLAN_E5         Success
      SWAY                  Success
      

      Die PrimarySMTPAddress des Benutzers wird nicht mehr bereinigt. Die northwindtraders.com Domäne ist nicht im Besitz des contoso.onmicrosoft.com Mandanten und wird als primäre SMTP-Adresse beibehalten, die im Verzeichnis angezeigt wird.

      Hier ein Beispiel:

      Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
      UserPrincipalName               PrimarySmtpAddress              ExternalEmailAddress                 ExternalDirectoryObjectId
      -----------------               ------------------              --------------------                 -------------------------
      ProxyTest@northwindtraders.com          ProxyTest@northwindtraders.com          SMTP:ProxyTest@northwindtraders.com          e2513482-1d5b-4066-936a-cbc7f8f6f817
      
      • Wenn msExchRemoteRecipientType auf 8 (DeprovisionMailbox) festgelegt ist, entfernt die Proxybereinigungslogik in Azure für lokale MailUsers, die zum Zielmandanten migriert werden, nicht im Besitz befindliche Domänen und setzt die primarySMTP auf eine domäne zurück. Durch das Löschen von msExchRemoteRecipientType im lokalen MailUser wird die Proxybereinigungslogik nicht mehr angewendet.

        Im Folgenden finden Sie den vollständigen Satz der aktuellen Servicepläne, die Exchange Online enthalten.

        Name
        eDiscovery Storage (Premium) (500 GB)
        Kunden-Lockbox
        Verhinderung von Datenverlust
        Exchange Enterprise CAL Services (EOP, DLP)
        Exchange Essentials
        Exchange Foundation
        Exchange Online (P1)
        Exchange Online (Plan 1)
        Exchange Online (Plan 2)
        Exchange Online-Archivierung für Exchange Online
        Exchange Online-Archivierung für Exchange Server
        Exchange Online Inaktives Benutzer-Add-On
        Exchange Online-Kiosk
        Exchange Online Multi-Geo
        Exchange Online Plan 1
        Exchange Online-POP
        Exchange Online Protection
        Suche nach Graphconnectors mit Index
        Business Information Barriers
        Information Protection für Office 365 – Premium
        Information Protection für Office 365 – Standard
        Erkenntnisse von MyAnalytics
        Microsoft Information Governance
        Microsoft Purview Audit (Premium)
        Microsoft Bookings
        Microsoft Business Center
        Microsoft-Datenuntersuchungen
        Microsoft MyAnalytics (Vollversion)
        Microsoft Communications Compliance
        Microsoft Communications DLP
        Microsoft-Kundenschlüssel
        Erweiterte Überwachung von Microsoft 365
        Microsoft-Datensatzverwaltung
        Office 365 eDiscovery (Premium)
        Office 365 Advanced eDiscovery
        Microsoft Defender for Office 365 (Plan 1)
        Microsoft Defender for Office 365 (Plan 2)
        Office 365 Privileged Access Management
        Premium-Verschlüsselung in Office 365