Mandantenübergreifende Postfachmigration (Vorschau)

Häufig benötigen Sie bei Fusionen oder Veräußerungen die Möglichkeit, das Exchange Online Postfach Ihres Benutzers in einen neuen Mandanten zu verschieben. Die mandantenübergreifende Postfachmigration ermöglicht Mandantenadministratoren die Verwendung bekannter Schnittstellen wie Exchange Online PowerShell und MRS, um Benutzer in ihre neue Organisation zu überführen.

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

Die Migration von Benutzern muss im Zielmandanten Exchange Online System als MailUsers vorhanden sein und mit bestimmten Attributen gekennzeichnet sein, um die mandantenübergreifende Verschiebung zu ermöglichen. Die Verschiebungen des Systems 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 angezeigt) wird mit der Routingadresse an den 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 verschiebungen von Exchange Online Postfachinhalten.

Hinweis

Wir haben kürzlich unsere Setupschritte aktualisiert, um die mandantenübergreifende Postfachmigration so zu aktivieren, dass Azure Key Vault nicht mehr erforderlich ist! Wenn Sie sich zum ersten Mal in diese Vorschau integrieren, ist keine Aktion erforderlich, und Sie können die in diesem Dokument beschriebenen Schritte ausführen. Wenn Sie mit der Konfiguration Ihrer Mandanten mithilfe der vorherigen AKV-Methode begonnen haben, wird dringend empfohlen, diese Konfiguration zu beenden oder zu entfernen, um mit der Verwendung dieser neuen Methode zu beginnen. Wenn Sie postfachmigrationen mit der vorherigen AKV-Methode ausgeführt haben, warten Sie bitte, bis Ihre vorhandenen Migrationen abgeschlossen sind, und führen Sie die folgenden Schritte aus, um die neue vereinfachte Methode zu aktivieren. Azure Key Vault erforderlichen Setupschritte werden archiviert, finden Sie hier jedoch als Referenz.

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, die verschoben werden müssen, einschränken oder festlegen, sodass unbeabsichtigte Benutzer nicht migriert werden können. Geschachtelte Gruppen werden nicht unterstützt.

Sie müssen auch mit Ihrem vertrauenswürdigen Partnerunternehmen (mit dem Sie Postfächer verschieben werden) kommunizieren, um deren Microsoft 365-Mandanten-ID zu erhalten. Diese Mandanten-ID wird im Feld "Organization Relationship DomainName" verwendet.

Um die Mandanten-ID eines Abonnements abzurufen, melden Sie sich bei der 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.

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 weder über die Anmeldeinformationen des Mandantenadministrators für den Quell- als auch den Zielmandanten verfügen oder diese 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 bei Ihrem Azure AD-Portal (https://portal.azure.com) mit ihren Anmeldeinformationen für den Zielmandantenadministrator an

    Azure-Anmeldung

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

    Azure Active Directory-Schaltfläche

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

  4. Neue Registrierung auswählen

    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 – Multitenant) aus. Wählen Sie dann unter Umleitungs-URI (optional) die Option "Web" aus, und geben Sie ein https://office.com. Wählen Sie schließlich "Registrieren" aus.

    Anwendungsregistrierung

  6. In der oberen rechten Ecke der Seite wird ein Benachrichtigungspopup angezeigt, das angibt, dass die App erfolgreich erstellt wurde.

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

  8. Suchen Sie unter "Eigene Anwendungen" die app, die Sie erstellt haben, und klicken Sie darauf.

  9. Unter ^Essentials müssen Sie die Anwendungs-ID (Client-ID) 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 sind der app zugewiesen, die Sie erstellt haben, 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, wählen Sie "Berechtigung hinzufügen" aus.

  13. Wählen Sie im Fenster "API-Berechtigungen anfordern" die von meiner Organisation verwendeten APIs aus, 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", "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 "Zertifikate & geheime Schlüssel" 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 des Migrationsendpunkts verwendet wird. Es ist äußerst wichtig, dass Sie dieses Kennwort in Die Zwischenablage kopieren oder dieses Kennwort an den 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, Geheime & Zertifikate auswählen und einen neuen Geheimschlüssel 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-Startseite, klicken Sie im linken Navigationsbereich auf Enterprise-Anwendungen, suchen Sie Ihre migrations-App, die Sie erstellt haben, wählen Sie sie aus, und wählen Sie im linken Navigationsbereich Berechtigungen aus.

  20. Klicken Sie auf die Schaltfläche "Administratorzustimmung für [Ihren Mandanten] erteilen".

  21. Ein neues Browserfenster wird geöffnet, und wählen Sie "Annehmen" 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/sourcetenant.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 sourcetenant.onmicrosoft.com im obigen Beispiel durch die richtigen Quellmandanten onmicrosoft.com Namen 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 Ziel-Exchange Online-Mandanten 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 (den geheimen Schlüssel), das Sie während dieses Vorgangs konfiguriert haben. Abhängig von der Microsoft 365-Cloudinstanz, die Sie Ihren Endpunkt verwenden, kann dies auch unterschiedlich sein. Bitte lesen Sie die Seite "Microsoft 365-Endpunkte", wählen Sie die richtige Instanz für Ihren Mandanten aus, und überprüfen Sie die Exchange Online "Erforderliche Adresse optimieren", und ersetzen Sie sie nach Bedarf.

    
    # 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 "sourcetenant.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId
    
  3. Erstellen Sie ein neues Organisationsbeziehungsobjekt, oder bearbeiten Sie es in 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
    }
    

Bereiten Sie den Quellmandanten (aktuellen Postfachspeicherort) vor, 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/sourcetenant.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 sourcetenant.onmicrosoft.com im obigen Beispiel durch die richtigen Quellmandanten onmicrosoft.com Namen 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 Popup angezeigt wird. Sie können sich auch bei Ihrem Azure Active Directory-Portal anmelden und die Anwendung unter „Unternehmensanwendungen“ suchen.

  3. Erstellen Sie eine neue Organisationsbeziehung, oder bearbeiten Sie Ihr vorhandenes Organisationsbeziehungsobjekt in 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]"
    $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.

Test-MigrationServerAvailability -EndPoint "Migration endpoint for cross-tenant mailbox moves" - TestMailbox "Primary SMTP of MailUser object in target tenant"

Verschieben von Postfächern zurück zur ursprünglichen Quelle

Wenn ein Postfach zum ursprünglichen Quellmandanten zurückwechseln muss, müssen dieselben Schritte und Skripts sowohl in neuen Quellmandanten als auch in neuen Zielmandanten ausgeführt werden. Das vorhandene Organisationsbeziehungenobjekt wird aktualisiert oder angefügt, nicht neu erstellt.

Vorbereiten von Zielbenutzerobjekten für die Migration

Die Migration von Benutzern muss im Zielmandanten und Exchange Online System (als MailUser) vorhanden sein, das mit bestimmten Attributen gekennzeichnet ist, um die mandantenübergreifende Verschiebung zu ermöglichen. Die Verschiebungen des Systems für Benutzer, die im Zielmandanten nicht ordnungsgemäß eingerichtet sind, schlagen fehl. Im folgenden Abschnitt werden die MailUser-Objektanforderungen für den Zielmandanten beschrieben.

Voraussetzungen für Zielbenutzerobjekte

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

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

    • Der Ziel-MailUser muss über diese Attribute aus dem Quellpostfach verfügen oder dem neuen Benutzerobjekt zugewiesen sein:

      • ExchangeGUID (direkter Fluss von Quelle zu Ziel): Die Postfach-GUID muss übereinstimmen. Der Verschiebungsprozess wird nicht fortgesetzt, wenn dies für das Zielobjekt nicht vorhanden ist.
      • ArchiveGUID (direkter Fluss von Quelle zu Ziel): Die Archiv-GUID muss übereinstimmen. Der Verschiebevorgang wird nicht fortgesetzt, wenn dieser im Zielobjekt nicht vorhanden ist. (Dies ist nur erforderlich, wenn das Quellpostfach "Archiv" aktiviert ist).
      • LegacyExchangeDN (Fluss als proxyAddress, "x500:<LegacyExchangeDN>"): Der LegacyExchangeDN muss für Ziel-MailUser als x500 vorhanden sein: proxyAddress. Darüber hinaus müssen Sie auch alle x500-Adressen aus dem Quellpostfach in den Ziel-E-Mail-Benutzer kopieren. Die Verschiebungsprozesse werden nicht fortgesetzt, wenn diese nicht im Zielobjekt vorhanden sind.
      • UserPrincipalName: 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 das NEUE Unternehmen des Benutzers ausgerichtet (z. B. user@northwind.com).
      • TargetAddress/ExternalEmailAddress: MailUser verweist auf das aktuelle Postfach des Benutzers, das im Quellmandanten gehostet wird (z. B. user@contoso.onmicrosoft.com). Stellen Sie beim Zuweisen dieses Werts sicher, dass Sie auch PrimarySMTPAddress zugewiesen haben/sind. 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 im MEU in fabrikam.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@northwind.com
      ExternalEmailAddress SMTP:LaraN@contoso.onmicrosoft.com
      ExchangeGuid 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=Erste Organisation/ou=Exchange Administrative Group (Interner-Name)/cn=Empfänger/cn=%'Alias'
      (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035Lara
      EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c8190
      7273f1f9-Lara
      smtp:LaraN@northwindtraders.onmicrosoft.com
      SMTP:Lara.Newton@northwind.com

      Beispiel für ein Quellpostfachobjekt :

      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=Erste Organisation/ou=Exchange Administrative Group (Interner-Name)/cn=Empfänger/cn=%'Alias'
      (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara
      EmailAddresses smtp:LaraN@contoso.onmicrosoft.com
      SMTP:Lara.Newton@contoso.com
    • Zusätzliche Attribute können bereits im Exchange-Hybridrückschreiben enthalten sein. Wenn nicht, sollten sie einbezogen werden.

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

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

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

  2. Wenn sich das Quellpostfach auf "LitigationHold" befindet und die Größe des Quellpostfachs "Wiederherstellbare Elemente" größer als die Standarddatenbank ist (30 GB), 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 zum Ziel zu übertragen, wodurch das Zielsystem das Kontingent der MailUser auf 100 GB erweitert, sodass das Verschieben zum Ziel ermöglicht wird. Diese Anweisungen funktionieren nur für hybride Identitäten mit Azure AD Connect, da die Befehle zum Stempeln der ELC-Flags für Mandantenadministratoren nicht verfügbar gemacht werden.

    Hinweis

    BEISPIEL – WIE ES IST, KEINE GARANTIE

    Dieses Skript geht von einer Verbindung mit dem Quellpostfach (zum Abrufen von Quellwerten) und dem Ziel lokales Active Directory (zum Stempeln des ADUser-Objekts) aus. Wenn für die Quelle Rechtsstreitigkeiten oder die Wiederherstellung einzelner Elemente aktiviert sind, legen Sie dies für das Zielkonto fest. Dadurch wird die Dumpstergröße des Zielkontos auf 100 GB erhöht.

    $ELCValue = 0
    if ($source.LitigationHoldEnabled) {$ELCValue = $ELCValue + 8} if ($source.SingleItemRecoveryEnabled) {$ELCValue = $ELCValue + 16} if ($ELCValue -gt 0) {Set-ADUser -Server $domainController -Identity $destination.SamAccountName -Replace @{msExchELCMailboxFlags=$ELCValue}}
    
  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 die Beweissicherung für das MailUser-Objekt zu aktivieren und das Kontingent auf 100 GB zu erhöhen:

    Set-MailUser -Identity <MailUserIdentity> -EnableLitigationHoldForMigration
    

    Beachten Sie, dass dies für Mandanten in hybriden Umgebungen 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 ist. Das Anwenden einer Lizenz vor der Anwendung von ExchangeGUID führt zu einem neuen Postfach, das in der Zielorganisation bereitgestellt 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 der MailUser-Zielbenutzer über kein vorheriges ExchangeGuid verfügt, das nicht mit der ExchangeGuid-Quelle übereinstimmt. Dies kann auftreten, wenn das Ziel-MEU zuvor für Exchange Online lizenziert und ein Postfach bereitgestellt wurde. Wenn der MailUser-Zielbenutzer zuvor für einen ExchangeGuid lizenziert war oder einen ExchangeGuid hatte, der nicht mit der ExchangeGuid-Quelle übereinstimmt, müssen Sie eine Bereinigung des Cloud-MEU durchführen. Für diese Cloud-MEUs können Sie ausführen Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

    Achtung

    Dieser Vorgang ist irreversibel. Wenn das Objekt über ein softDeleted-Postfach verfügt, kann es nach diesem Punkt nicht mehr 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. (Referenz-EHLO-Blog zum neuen Parameter.)

    Mit diesem Befehl können Sie Objekte suchen, bei denen es sich zuvor um Postfächer handelte.

    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 entspricht der Funktionsweise von Migrationsbatches beim Onboarding bei der Migration von exchange lokal zu Microsoft 365.

Erstellen von Migrationsbatches

Hier ist 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 target.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, nicht der Quellmandant.

Weitere Informationen zum Cmdlet finden Sie hier.

Klicken Sie hier, um eine CSV-Beispieldatei anzuzeigen.

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

Aktualisieren lokaler MailUsers

Sobald das Postfach von Quelle zu 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 wird die bei der Verschiebung verwendete targetDeliveryDomain contoso.onmicrosoft.com. Aktualisieren Sie die E-Mail-Benutzer mit dieser targetAddress.

Häufig gestellte Fragen

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

Ja, Sie sollten die targetAddress (RemoteRoutingAddress/ExternalEmailAddress) der lokalen Quellbenutzer aktualisieren, wenn das Quellmandantenpostfach 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-Nachschlagevorgänge für E-Mail-Benutzer auf den Speicherort des Postfachbenutzers ausgerichtet sein. Frei/Gebucht-Nachschlagevorgänge verfolgen nicht mehrere Umleitungen.

Migrieren Teams-Besprechungen mandantenübergreifend?

Die Besprechungen werden verschoben, die Url der Teams-Besprechung 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.

Werden die Inhalte des Teams-Chatordners mandantenübergreifend migriert?

Nein, der Inhalt des Teams-Chatordners wird nicht mandantenübergreifend migriert.

Wie kann ich nur Verschiebungen sehen, bei denen es sich um mandantenübergreifende Verschiebungen handelt, nicht um meine Onboarding- und Off-Boarding-Verschiebungen?

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

BEISPIEL – WIE ES IST, KEINE GARANTIE Dieses Skript geht von einer Verbindung mit dem Quellpostfach (zum Abrufen von Quellwerten) und dem Ziel lokales Active Directory Domain Services (zum Stempeln des ADUser-Objekts) aus. Wenn für die Quelle Rechtsstreitigkeiten oder die Wiederherstellung einzelner Elemente aktiviert sind, legen Sie dies für das Zielkonto fest. Dadurch wird die Dumpstergröße des Zielkontos auf 100 GB erhöht.

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the Northwind org 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 am 1. Tag zu, nachdem das Verwendungspostfach verschoben wurde?

Da nur ein Mandant eine Domäne besitzen kann, wird die ehemalige primäre SMTPAddress dem Benutzer im Zielmandanten nicht zugeordnet, wenn die Postfachverschiebung abgeschlossen ist. nur die Domänen, die dem neuen Mandanten zugeordnet sind. Outlook verwendet den neuen UPN der Benutzer, um sich beim Dienst zu authentifizieren, und das Outlook-Profil erwartet, dass die primäre SMTPAddress-Vorversion gefunden wird, die dem Postfach im Zielsystem entspricht. 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 anfängliche Bereitstellung müssen Benutzer ihr Profil mit ihrem neuen UPN, der primären SMTP-Adresse und dem erneuten Synchronisieren von OST-Inhalten neu erstellen.

Hinweis

Planen Sie entsprechend, während Sie ihre Benutzer für den Abschluss batchen. 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 des Verschiebens von Inhalten in oder außerhalb Ihrer Mandanten-/Organisationsgrenze festlegt. Da das Verschieben von Daten aus ihrer Organisationssteuerung für alle Unternehmen ein wichtiges Anliegen 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 die "-MailboxMoveCapability" mit der Remoteorganisation definiert. Nur das OrgAdmin kann die MailboxMoveCapability-Einstellung ändern, während andere Attribute in "OrganizationRelationship" vom Partnerfreigabeadministrator verwaltet werden können.

  • Die Rolle der Ausführung der eigentlichen Verschiebebefehle kann an eine Funktion auf niedrigerer Ebene delegiert werden. Die Rolle des Verschiebens von Postfächern wird der Funktion zum Verschieben von Postfächern in oder aus der Organisation zugewiesen.

Wie wird festgelegt, welche SMTP-Adresse für "targetAddress" (TargetDeliveryDomain) für das konvertierte Postfach (in die MailUser-Konvertierung) ausgewählt wird?

Exchange-Postfächer werden mithilfe von MRS craft the targetAddress im ursprünglichen Quellpostfach verschoben, wenn sie in einen MailUser konvertiert werden, indem eine E-Mail-Adresse (proxyAddress) für das Zielobjekt abgeglicht wird. Der Prozess übernimmt den -TargetDeliveryDomain-Wert, der an den Verschiebebefehl ü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 werden Postfachberechtigungen umgestellt?

Zu den Postfachberechtigungen gehören "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 als Teil des Postfachübergangs verschoben. Wenn für das Quellpostfach "publicDelegates" festgelegt ist, müssen Sie die publicDelegates für das Zielpostfach erneut anzeigen, sobald die MEU-zu-Postfachkonvertierung in der Zielumgebung abgeschlossen ist, indem Sie ausführen Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.

  • Postfachberechtigungen, die im Postfach gespeichert sind, werden mit dem Postfach verschoben, wenn sowohl der Prinzipal als auch die Stellvertretung in das Zielsystem verschoben werden. Beispielsweise wird dem Benutzer TestUser_7 FullAccess auf das Postfach gewährt, das TestUser_8 im Mandanten-SourceCompany.onmicrosoft.com. Nachdem die Postfachverschiebung in TargetCompany.onmicrosoft.com abgeschlossen ist, werden dieselben 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 entsprechend das Präfix "Quelle" und "Ziel".

Hier ist ein Beispiel für die Ausgabe der Postfachberechtigung vor einer Verschiebung.

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

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

Hier ist ein Beispiel für die Ausgabe der Postfachberechtigung nach der Verschiebung.

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

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

Hinweis

Mandantenübergreifende Postfach- und Kalenderberechtigungen werden NICHT unterstützt. Sie müssen Prinzipale und Stellvertretungen in konsolidierte 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?

Für die mandantenübergreifende Postfachmigration muss der LegacyExchangeDN-Wert des Quellpostfachobjekts als x500-E-Mail-Adresse für das MailUser-Zielobjekt gestempelt werden.

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.

Kann der Quell- und Zielmandant denselben Domänennamen verwenden?

Nein Die Domänennamen der Quell- und Zielmandanten müssen eindeutig sein. Beispielsweise eine Quelldomäne von contoso.com und die Zieldomäne von fourthcoffee.com.

Werden freigegebene Postfächer verschoben und funktionieren weiterhin?

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

Haben Sie Empfehlungen für Batches?

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 crosstenantmigrationpreview@service.microsoft.com an die Engineering Feedback-Verteilerliste wenden.

Was geschieht, wenn ich die Dienstverschlüsselung mit Customer Key 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 .

Was ist die geschätzte Migrationszeit?

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

Denken Sie daran, dass sich dieses Feature derzeit in der Vorschau und der SLA befindet, und alle anwendbaren Servicelevels gelten während des Vorschaustatus dieses Features nicht für Leistungs- oder Verfügbarkeitsprobleme.

Schützen von Dokumenten im Quellmandanten-Verbrauchsartikel durch Benutzer im Zielmandanten.**

Die mandantenübergreifende Migration migriert nur Postfachdaten und nichts anderes. Es gibt mehrere andere Optionen, die im folgenden Blogbeitrag dokumentiert sind, die möglicherweise hilfreich sind: https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

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

Da mandantenübergreifende Migrationen keine Bezeichnungen exportieren 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 für mandantenübergreifende Postfachmigrationen die Migration von Microsoft 365-Gruppen nicht.

Kann ein Quellmandantenadministrator eine eDiscovery-Suche nach einem 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 jetzt 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 in ein alternatives Postfach vor der Migration für zukünftige eDiscovery-Vorgänge mit den Daten kopieren.

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

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

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

Dies kann geschehen, bevor die Migration abgeschlossen ist. 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 mindern, sollten Sie am besten warten, bis die Migration abgeschlossen ist, und während der 30-tägigen Nachfrist Lizenzen zuweisen.

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. die Unfähigkeit, Ihr Profilbild zu aktualisieren, keine Kalenderanwendung und die Unfähigkeit, öffentliche Teams zu durchsuchen und beizutreten.

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

  • Problem: Cloud MailUsers mit nicht im Besitz von SMTP proxyAddress block MRS verschiebt den Hintergrund. Beim Erstellen von MailUser-Zielmandantenobjekten müssen Sie sicherstellen, dass alle SMTP-Proxyadressen zur Zielmandantenorganisation gehören. Wenn eine SMTP-proxyAddress für den Ziel-E-Mail-Benutzer vorhanden ist, der nicht zum lokalen Mandanten gehört, wird die Konvertierung von MailUser in Mailbox verhindert. Dies liegt an unserer Zusicherung, dass Postfachobjekte nur E-Mails von Domänen senden können, für die der Mandant autoritativ ist (vom Mandanten beanspruchte Domänen):

    • Wenn Sie Benutzer lokal mitHilfe von Azure AD Connect synchronisieren, stellen Sie lokale MailUser-Objekte mit ExternalEmailAddress bereit, die auf den Quellmandanten zeigen, in dem das Postfach vorhanden ist (LaraN@contoso.onmicrosoft.com), und Sie stempeln die PrimarySMTPAddress als Domäne, die sich im Zielmandanten (Lara.Newton@northwind.com) befindet. Diese Werte werden mit dem Mandanten synchronisiert, und ein entsprechender E-Mail-Benutzer wird bereitgestellt und kann zur Migration bereit sein. Hier wird ein Beispielobjekt gezeigt.

      Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses
      
      ExternalEmailAddress               EmailAddresses
      --------------------               --------------
      SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwind.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. Im Fall von mandantenübergreifenden Postfachmigrationen verwenden wir MailUser-Objekte, um entweder das Quellpostfach (aus der Perspektive 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@fabrikam.onmicrosoft.com) und die primäreSMTP-Adresse verweist, die die angezeigte SMTP-Adresse des Postfachbenutzers im Verzeichnis darstellt. Einige Organisationen entscheiden sich für die Anzeige der primären SMTP-Adresse als externe SMTP-Adresse, nicht als Adresse, die dem lokalen Mandanten gehört/überprüft wurde (z. B. fabrikam.com statt als contoso.com). Sobald jedoch ein Exchange-Dienstplanobjekt über Lizenzierungsvorgänge auf den MailUser angewendet wurde, wird die primäre SMTP-Adresse so geändert, dass sie von der lokalen Organisation (contoso.com) überprüft wird. Es gibt zwei mögliche Gründe:

    • Wenn ein Exchange-Dienstplan auf einen MailUser angewendet wird, beginnt der Azure AD-Prozess mit der Erzwingung der Proxybereinigung, um sicherzustellen, dass die lokale Organisation keine E-Mails aus einem anderen Mandanten senden, Spoofing oder E-Mails senden kann. Jede SMTP-Adresse für ein Empfängerobjekt mit diesen Dienstplänen wird entfernt, wenn die Adresse von der lokalen Organisation nicht überprüft wird. Wie im Beispiel wird die Fabikam.com Domäne nicht vom contoso.onmicrosoft.com Mandanten überprüft, sodass das Scrubbing diese fabrikam.com Domäne entfernt. Wenn Sie diese externen Domänen auf MailUser beibehalten möchten, entweder vor der Migration oder nach der Migration, müssen Sie Ihre Migrationsprozesse so ändern, dass Lizenzen nach Abschluss der Verschiebung oder vor dem Verschieben entfernt werden, um sicherzustellen, dass die Benutzer das erwartete externe Branding angewendet haben. Sie müssen sicherstellen, dass das Postfachobjekt ordnungsgemäß lizenziert ist, um den E-Mail-Dienst nicht zu beeinträchtigen.

    • Hier wird ein Beispielskript zum Entfernen der Dienstpläne für einen MailUser im contoso.onmicrosoft.com-Mandanten gezeigt.

      $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 in der Gruppe der zugewiesenen 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 fabrikam.com Domäne befindet sich nicht im Besitz des contoso.onmicrosoft.com Mandanten und bleibt als primäre SMTP-Adresse im Verzeichnis erhalten.

      Hier ein Beispiel:

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

        Nachfolgend finden Sie den vollständigen Satz der aktuellen Dienstpläne, die Exchange Online enthalten.

        Name
        eDiscovery (Premium) Speicher (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
        Business Information Barriers
        Information Protection für Office 365 – Premium
        Information Protection für Office 365 – Standard
        Einblicke von MyAnalytics
        Microsoft Purview Audit (Premium)
        Microsoft Bookings
        Microsoft Business Center
        Microsoft MyAnalytics (Vollversion)
        Office 365 eDiscovery (Premium)
        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