Mandantenübergreifende Postfachmigration
Bei Fusionen oder Veräußerungen benötigen Sie möglicherweise 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 auf ihre neuen organization umzusteigen.
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 MailUser vorhanden sein, der mit bestimmten Attributen gekennzeichnet ist, um die mandantenübergreifenden Verschiebungen zu ermöglichen. Das System kann keine Benutzer verschieben, die im Zielmandanten nicht ordnungsgemäß eingerichtet sind.
Nachdem die Verschiebungen abgeschlossen sind, wird das Quellbenutzerpostfach in ein MailUserkonvertiert, und die targetAddress (in Exchange als ExternalEmailAddress dargestellt) wird mit der Routingadresse zum Zielmandanten gestempelt. Dieser Prozess belässt die Legacy MailUser im Quellmandanten und ermöglicht koexistenz und E-Mail-Routing. Wenn Geschäftsprozesse dies zulassen, kann der Quellmandant den MailUser-Quellbenutzer entfernen oder in einen E-Mail-Kontakt konvertieren.
Mandantenübergreifende Exchange-Postfachmigrationen werden nur für Mandanten in Hybrid- oder Cloudumgebungen oder eine Kombination aus beiden unterstützt.
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
Postfächer, die sich in einem beliebigen Halteraum befinden, werden nicht migriert, und die Verschiebung für diese Postfächer wird blockiert.
Wenn ein Postfach mandantenübergreifend mit diesem Feature migriert wird, werden nur vom Benutzer sichtbare Inhalte im Postfach (E-Mail, Kontakte, Kalender, Aufgaben und Notizen) zum Ziel (Zielmandanten) migriert. Nach einer erfolgreichen Migration wird das Quellpostfach gelöscht. Dieser Löschvorgang bedeutet, dass das Quellpostfach nach der Migration unter keinen Umständen im Quellmandanten verfügbar, auffindbar oder zugänglich ist.
Lizenzierung
Wichtig
Ab November 2022 ist die mandantenübergreifende Benutzerdatenmigration als Add-On für die folgenden Microsoft 365-Abonnementpläne für Enterprise Agreement Kunden verfügbar und für mandantenübergreifende Migrationen erforderlich. Benutzerlizenzen gelten pro Migration (einmalige Gebühr) und können entweder für das Quell- oder Zielbenutzerobjekt zugewiesen werden. Diese Lizenz deckt auch OneDrive for Business Migration ab. Weitere Informationen erhalten Sie von Ihrem Microsoft-Kontoteam.
Das Mandantenübergreifende Benutzerdatenmigrations-Add-On ist als separater Kauf für Microsoft 365 Business Basic, Standard und Premium verfügbar. Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; und OneDrive for Business.
Warnung
Sie müssen vor den nächsten Schritten mandantenübergreifende Benutzerdatenmigrationslizenzen erworben oder sich vergewissert haben, dass Sie sie erwerben können. Migrationen schlagen fehl, wenn dieser Schritt nicht abgeschlossen wurde. Microsoft bietet keine Ausnahmen für diese Lizenzierungsanforderung an.
Wenn Dem migrierten Benutzer nicht die richtige Lizenz zugewiesen ist, schlägt die Migration fehl, und Sie erhalten eine Fehlermeldung, die der folgenden ähnelt:
Error: CrossTenantMigrationWithoutLicensePermanentException: No license was found for the source recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87', or the target recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87'. A Cross-tenant User Data Migration license is required to move a mailbox between tenants.
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 einzuteilen, die vom Quellmandanten (oder manchmal auch als Ressource bezeichnet) zum Zielmandanten verschoben werden können. Dieser Bereich ermöglicht es dem Quellmandantenadministrator, den spezifischen Satz von Postfächern einzuschränken oder festzulegen, die verschoben werden müssen, um zu verhindern, dass unbeabsichtigte Benutzer migriert werden.
Wenn Sie mehr als 10.000 Benutzer migrieren, empfiehlt es sich, mehrere Gruppen zu erstellen, die die Benutzerliste enthalten, um eine optimale Leistung zu erzielen. Geschachtelte Gruppen werden zwar unterstützt, aber nicht empfohlen.
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. Wählen Sie das Kopiersymbol für die Eigenschaft Mandanten-ID aus, um sie in die Zwischenablage zu kopieren.
Alle Benutzer in der Quell- und Zielorganisationen müssen mit den entsprechenden Exchange Online-Abonnements lizenziert werden. Stellen Sie außerdem sicher, dass Sie lizenzen für die mandantenübergreifende Benutzerdatenmigration auf alle Benutzer anwenden, 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
Melden Sie sich bei Ihrem Microsoft Entra Admin Center (https://portal.azure.com) mit den Anmeldeinformationen des Zielmandantenadministrators an.
Wählen Sie unter Microsoft Entra ID verwalten die Option Ansicht aus.
Wählen Sie im Navigationsbereich App-Registrierungen aus.
Wählen Sie Neue Registrierung aus.
Wählen Sie auf der Seite Anwendung registrieren unter Unterstützte Kontotypen die Option Konten in einem beliebigen Organisationsverzeichnis (Beliebiges Microsoft Entra Verzeichnis – Mehrinstanzenfähig) aus. Wählen Sie dann unter Umleitungs-URI (optional)die Option Web aus, und geben Sie dann ein
https://office.com. Wählen Sie dann Registrieren aus.
Sehen Sie sich in der oberen rechten Ecke der Seite das Benachrichtigungsdialogfeld an, in dem angegeben wird, dass die App erfolgreich erstellt wurde.
Zurück zur Startseite, wechseln Sie zu Microsoft Entra ID, und wählen Sie dann App-Registrierungen aus.
Suchen Sie unter Eigene Anwendungen nach der app, die Sie erstellt haben, und wählen Sie sie dann aus.
Kopieren Sie unter Essentials die Anwendungs-ID (Client-ID). Sie benötigen diese Informationen später, um eine URL für den Zielmandanten zu erstellen.
Wählen Sie im Navigationsbereich API-Berechtigungen aus, um Berechtigungen anzuzeigen, die Ihrer App zugewiesen sind.
Standardmäßig werden der von Ihnen erstellten App User.Read-Berechtigungen zugewiesen, aber diese Berechtigungen sind für Postfachmigrationen nicht erforderlich. Sie können diese Berechtigungen entfernen.
Um die Berechtigung für die Postfachmigration hinzuzufügen, wählen Sie Berechtigung hinzufügen aus.
Wählen Sie im Fenster API-Berechtigungen anfordern die APIs aus, die von meinem organization verwendet werden, suchen Sie nach
Office 365 Exchange Online, und wählen Sie sie dann aus.
Wählen Sie Anwendungsberechtigungen aus.
Erweitern Sie unter Berechtigungen auswählenden Knoten Postfach , und wählen Sie Mailbox.Migration aus, und wählen Sie dann unten auf dem Bildschirm Berechtigungen hinzufügen aus.
Wählen Sie nun Zertifikate & Geheimnisse im Navigationsbereich für Ihre Anwendung aus.
Wählen Sie unter Geheime Clientschlüsseldie Option Neuer geheimer Clientschlüssel aus.
Geben Sie im Fenster Geheimen Clientschlüssel hinzufügen eine Beschreibung ein, und konfigurieren Sie dann Ihre Ablaufeinstellungen.
Hinweis
Das Kennwort wird beim Erstellen Ihres Migrationsendpunkts verwendet. Es ist äußerst wichtig, dass Sie dieses Kennwort in Ihre Zwischenablage und/oder an einen sicheren/geheimen Kennwortspeicherort kopieren. Die Geheimniserstellungsphase ist der einzige Zeitpunkt, in dem Sie dieses Kennwort sehen können! Wenn Sie es irgendwie verlieren oder zurücksetzen müssen, können Sie sich wieder beim Azure-Portal anmelden, zu App-Registrierungen wechseln, Ihre Migrations-App suchen, Geheimnisse & Zertifikate auswählen und dann ein neues Geheimnis für Ihre App erstellen.
Nachdem Sie die Migrationsanwendung und das Geheimnis erfolgreich erstellt haben, besteht der nächste Schritt darin, der Anwendung zuzustimmen.
Erteilen der Zustimmung für die Anwendung
Wählen Sie auf der Microsoft Entra ID Angebotsseite im Navigationsbereich Unternehmensanwendungen aus. Suchen Sie dann nach Ihrer von Ihnen erstellten Migrations-App, wählen Sie sie aus, und wählen Sie dann API-Berechtigungen aus.
Wählen Sie Administratoreinwilligung für [Ihren Mandanten] erteilen aus. Ein neues Browserfenster wird geöffnet.
Wählen Sie Annehmen aus.
Zurück zu Ihrem Portalfenster, und wählen Sie Aktualisieren aus, um Ihre Zustimmung zu bestätigen.
Formulieren Sie die URL, die an Ihren vertrauenswürdigen Partner (Quellmandantenadministrator) gesendet werden soll, damit dieser auch die Anwendung akzeptieren kann, um die Postfachmigration zu aktivieren.
Hier sehen Sie ein Beispiel für die URL, die ihnen zur Verfügung gestellt werden soll:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comHinweis
Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App. Sie müssen contoso.onmicrosoft.com im obigen Beispiel durch den richtigen onmicrosoft.com Namen Ihres 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
Stellen Sie eine Verbindung mit Exchange Online PowerShell im Zielmandanten Exchange Online her.
Erstellen Sie einen neuen Migrationsendpunkt für mandantenübergreifende Postfachverschiebungen.
Hinweis
Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App und das Kennwort (Geheimnis), das Sie unter Vorbereiten des Zielmandanten (Zielmandanten) durch Erstellen der Migrationsanwendung und des Geheimnisses konfiguriert haben. Je nachdem, welche Microsoft 365-Cloud-instance Sie verwenden, kann Ihr Endpunkt unterschiedlich sein. Weitere Informationen finden Sie auf der Seite Microsoft 365-Endpunkte. Wählen Sie die richtige instance für Ihren Mandanten aus. Überprüfen Sie dann die Exchange Online Optimieren/Erforderliche Adresse, 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 "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppIdErstellen Sie ein neues organization-Beziehungsobjekt, oder bearbeiten Sie das vorhandene organization-Beziehungsobjekt für Ihren 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 organization Beziehung konfigurieren
Navigieren Sie in Ihrem Browser zum URL-Link, der von Ihrem vertrauenswürdigen Partner bereitgestellt wird, um der Postfachmigrationsanwendung zuzustimmen. Die URL sollte wie folgt aussehen:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comHinweis
Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App. Sie müssen im vorherigen Beispiel durch die URL Ihres Quellmandanten
onmicrosoft.comersetzencontoso.onmicrosoft.com. Außerdem müssen Sie [application_id_of_the_app_you_just_created] durch die Anwendungs-ID der soeben erstellten Postfachmigrations-App ersetzen.Akzeptieren Sie die Anwendung, wenn das Popupfenster angezeigt wird. Sie können sich auch bei Ihrem Microsoft Entra Admin Center anmelden und die Anwendung unter Unternehmensanwendungen suchen.
Stellen Sie eine Verbindung mit Exchange Online PowerShell auf dem Quellmandanten Exchange Online her.
Erstellen Sie ein neues organization-Beziehungsobjekt, oder bearbeiten Sie Ihr vorhandenes organization-Beziehungsobjekt mit Ihrem Zielmandanten in Exchange Online PowerShell:
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $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.
Vorbereiten von Zielbenutzerobjekten für die Migration
Benutzer, die migriert werden, müssen im Zielmandanten vorhanden sein und Exchange Online System (als MailUser) mit bestimmten Attributen gekennzeichnet sein, um mandantenübergreifende Verschiebungen zu ermöglichen. Das System kann keine Benutzer verschieben, die im Zielmandanten nicht ordnungsgemäß eingerichtet sind. Im Abschnitt Voraussetzungen für Zielbenutzerobjekte 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 im Ziel organization festgelegt sind:
Tipp
Microsoft entwickelt ein Feature, um eine sichere automatisierte Methode zum Festlegen vieler Attribute bereitzustellen (siehe unten in diesem Abschnitt). Dieses Feature namens Mandantenübergreifende Identitätszuordnung sucht derzeit nach Kunden, die bereit sind, an einer kleinen privaten Vorschau teilzunehmen. Weitere Informationen zu diesem Vorabfeature und dazu, wie es Ihre mandantenübergreifenden Migrationsprozesse vereinfachen kann, finden Sie unter Mandantenübergreifende Identitätszuordnung.
Für jedes Postfach, das aus einer Quell-organization verschoben wird, müssen Sie ein MailUser-Objekt im Ziel-organization 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 dieses Attribut im Zielobjekt nicht vorhanden ist.
ArchiveGUID (direkter Fluss von der Quelle zum Ziel): Die Archiv-GUID muss übereinstimmen. Der Verschiebungsprozess wird nicht fortgesetzt, wenn dieses Attribut im Zielobjekt nicht vorhanden ist. (Dieses Attribut 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 x500-Adressen nicht im Zielobjekt 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 AutoVervollständigen-Cache in Microsoft Outlook und in Microsoft Outlook Web App (OWA) verwenden den Wert des LegacyExchangeDN-Attributs. Wenn ein Benutzer nicht mit dem LegacyExchangeDN-Wert gefunden werden kann, schlägt die Übermittlung 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. ). Wenn dieser Wert zugewiesen wird, überprüfen Sie, ob 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 Microsoft Entra ID 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=74e5385fce4b46d19006876949855035-Lara 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 X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara 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=d11ec1a2cacd4f81858c81907273f1f9-Lara EmailAddresses Smtp:LaraN@contoso.onmicrosoft.com SMTP:Lara.Newton@contoso.com X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara
Andere Attribute sind möglicherweise bereits im Hybridrückschreiben von Exchange enthalten. Andernfalls sollten sie einbezogen werden.
msExchBlockedSendersHash– Schreibt online blockierte Absenderdaten von Clients in lokales Active Directory zurück.msExchSafeRecipientsHash– Schreibt online sichere Empfängerdaten von Clients in lokales Active Directory zurück.msExchSafeSendersHash– Schreibt online sichere Absenderdaten von Clients in lokales Active Directory zurück.
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 vor dem Anwenden der ExchangeGUID führt zu einem neuen Postfach, das im Ziel organization bereitgestellt wird. Sie müssen auch eine Lizenz für die mandantenübergreifende Benutzerdatenmigration anwenden. Andernfalls wird möglicherweise ein vorübergehender Fehler angezeigt, der beim Lesen der Genehmigung erforderlich ist. Dadurch wird im Verschiebungsbericht eine Warnung angezeigt, dass keine Lizenz auf den Zielbenutzer angewendet wurde.
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.
Sie müssen sicherstellen, dass das Ziel-MailUser keine vorherige ExchangeGUID aufweist, die nicht mit der Quell-ExchangeGUID übereinstimmt. Dieser Konflikt kann auftreten, wenn die Ziel-MEU zuvor für Exchange Online lizenziert und ein Postfach bereitgestellt wurde. Wenn der MailUser-Zielbenutzer zuvor für eine ExchangeGUID lizenziert war oder über eine ExchangeGUID verfügte, die nicht mit der ExchangeGUID-Quelle ü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.
Achtung
Dieser Vorgang ist irreversibel. Wenn das Objekt über ein softDeleted-Postfach verfügt, kann es nach diesem Zeitpunkt 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 objekte, die zuvor Postfächer waren, indem Sie den folgenden Befehl verwenden:
Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize
Hier ist 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 dem folgenden Befehl:
Set-User <identity> -PermanentlyClearPreviousMailboxInfo
Hier ist 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
Woher weiß ich, dass der Vorgang erfolgreich war?
Sie können die Konfiguration der mandantenübergreifenden Postfachmigration überprüfen, indem Sie das Cmdlet Test-MigrationServerAvailability für den 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]"
Hinweis
Darüber hinaus können Sie das Überprüfungsskript für die mandantenübergreifende Postfachmigration nutzen, mit dem Sie überprüfen können, welche Organisationen zwischen ihnen ordnungsgemäß eingerichtet wurden, und die Objekte, die Sie von einem Mandanten zu einem anderen migrieren möchten. Das Skript hilft dabei, Abweichungen zu identifizieren, die für alle Objekte gleichzeitig vorhanden sein können, und reduziert dadurch die für die Anfangsphase aufgewendete Zeit.
Verschieben von Postfächern zurück in die ursprüngliche Quelle
Wenn ein Postfach zurück auf den 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, mit einigen Abweichungen.
Führen Sie nicht die Beispielskripts aus, die zum Erstellen der OrganizationRelationship bereitgestellt werden.
Aktualisieren Sie die folgenden Werte in der vorhandenen OrganizationRelationship, die in jedem Mandanten erstellt wurde:
- MailboxMovesCapability sollte sowohl in Quell- als auch in Zielmandanten über "Inbound" und "RemoteOutbound" verfügen.
- Aktualisieren Sie im neuen Quellmandanten den OAuthApplicationId-Wert mit dem Wert aus der neu erstellten Anwendung im neuen Quellmandanten.
- Aktualisieren Sie im neuen Quellmandanten den Wert MailboxMovePublishedScopes mit der neu erstellten Sicherheitsgruppe im neuen Quellmandanten.
Durchführen von Postfachmigrationen
Mandantenübergreifende Exchange-Postfachmigrationen werden vom Zielmandanten als Migrationsbatches initiiert. Dieser Prozess ähnelt der Funktionsweise von Onboarding-Migrationsbatches bei der Migration von lokalem Exchange zu Microsoft 365.
Erstellen von Migrationsbatches
Hier sehen Sie einen Beispielbefehl zum Initiieren einer Batchmigration:
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. Hier finden Sie einige Csv-Dateiinformationen. Klicken Sie hier.
Ein minimales Beispiel für eine CSV-Datei ist:
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 organization Beziehungen nach der Migration
Verwenden Sie das Cmdlet Remove-MigrationEndpoint , um vorhandene Migrationsendpunkte für Quell- oder Zielserver nach Abschluss der Migration zu entfernen.
Verwenden Sie das Cmdlet Remove-OrganizationRelationship, um vorhandene organization Beziehungen für Quell- oder Zielserver nach Abschluss der Migration zu entfernen.
Häufig gestellte Fragen
Muss ich RemoteMailboxes im lokalen Quellmandanten nach dem Verschieben aktualisieren?
Exchange-Quellorganisation
Sie sollten die targetAddress (RemoteRoutingAddress/ExternalEmailAddress) jedes lokalen Quellbenutzers 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-Lookups für E-Mail-Benutzer auf den Speicherort des Postfachbenutzers ausgerichtet sein .
Exchange-Zielorganisation
Führen Sie nach Abschluss der Migration in einem hybriden organization den folgenden PowerShell-Befehl aus, wenn Sie möchten, dass Ihre Benutzer Remotepostfächer lokal haben sollen:
Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox
Werden Teams-Besprechungen mandantenübergreifend migriert?
Während Teams-Besprechungen verschoben werden, wird die Besprechungs-URL nicht aktualisiert, wenn Elemente mandantenübergreifend migriert werden. Da die URL im Zielmandanten ungültig ist, müssen Sie Teams-Besprechungen entfernen und neu erstellen.
Welche Inhalte werden mandantenübergreifend migriert?
Wenn ein Postfach mandantenübergreifend mit diesem Feature migriert wird, werden nur vom Benutzer sichtbare Inhalte im Postfach, die auch als "Top of Information Store" (E-Mail, Kontakte, Kalender, Aufgaben und Notizen) bezeichnet werden, und die Ordner "Wiederherstellbare Elemente" "Löschungen", "Versionen" und "Bereinigungen" migriert.
Werden Elemente im Postausgang mandantenübergreifend migriert?
Elemente im Postausgang werden nicht mandantenübergreifend migriert, da dieser Ordner ein clientbasierter Ordner ist, der für den Outlook-Client spezifisch ist. Elemente im Postausgang werden lokal gespeichert und nicht mit der Cloud synchronisiert.
Wird der Inhalt des Teams-Chatordners mandantenübergreifend migriert?
Nein, der Inhalt des Teams-Chatordners wird nicht mandantenübergreifend migriert. Nachdem das Postfach jedoch mandantenübergreifend migriert wurde, steht der Inhalt des Teams-Chatordners dem Quellmandantenadministrator zur Verfügung, um mithilfe einer Inhaltssuche zu suchen und zu exportieren.
Wie kann ich nur Verschiebungen anzeigen, die mandantenübergreifende Verschiebungen sind, nicht meine Onboarding- und Offboarding-Verschiebungen?
Verwenden Sie den Parameter Flags :
Get-MoveRequest -Flags "CrossTenant"
Können Sie Beispielskripts zum Kopieren von Attributen bereitstellen, die beim Testen verwendet werden?
Hinweis
BEISPIEL – WIE BEANSTANDEN, KEINE GARANTIE Dieses Skript geht von einer Verbindung mit dem Quellpostfach (zum Abrufen von Quellwerten) und dem zielbasierten lokales Active Directory Domain Services (zum Stempeln des ADUser-Objekts) aus.
# 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
$symbols = '!@#$%^&*'.ToCharArray()
$characterList = @([char[]]([char]'a'..[char]'z'), [char[]]([char]'A'..[char]'Z'), [char[]]([char]'0'..[char]'9') + $symbols)
function GeneratePassword {
param(
[ValidateRange(12, 256)]
[int]
$length = 16
)
do {
$password = -join (0..$length | ForEach-Object { $characterList | Get-Random })
[int]$hasLowerChar = $password -cmatch '[a-z]'
[int]$hasUpperChar = $password -cmatch '[A-Z]'
[int]$hasDigit = $password -match '[0-9]'
[int]$hasSymbol = $password.IndexOfAny($symbols) -ne -1
}
until (($hasLowerChar + $hasUpperChar + $hasDigit + $hasSymbol) -ge 3)
$password | ConvertTo-SecureString -AsPlainText
}
$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
foreach ($m in $mailboxes) {
$organization = "@contoso.onmicrosoft.com"
$mosi = $m.Alias + $organization
$Password = GeneratePassword
$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 | Where-Object { $_ -match "x500" }
$tmpx500 | ForEach-Object { Set-MailUser $m.Alias -EmailAddresses @{add = "$_" } }
}
# Now synchronize 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 ost-Inhalt neu synchronisieren.
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 entschieden. Diese Rolle muss eine neue OrganizationRelationship ändern oder einrichten, die die
-MailboxMoveCapabilityEinstellung mit dem Remote-organization definiert. Nur der organization-Administrator kann die-MailboxMoveCapabilityEinstellung ändern, während andere Attribute in der OrganisationRelationship 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 dem organization 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 verschiebt mithilfe von MRS die targetAddress für das ursprüngliche Quellpostfach, wenn sie in einen MailUser konvertiert wird, indem eine E-Mail-Adresse (proxyAddress) für das Zielobjekt abgleicht. Der Prozess übernimmt den -TargetDeliveryDomain an den Befehl übergebenen Wert 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 Zieladresse, 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, 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 für das Zielpostfach neu stempeln, sobald die Konvertierung von MEU in Mailbox 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 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 das Postfach in TargetCompany.onmicrosoft.com verschoben wurde, 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, is Inherited, 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?
Für die mandantenübergreifende Postfachmigration muss der LegacyExchangeDN-Wert des Quellpostfachobjekts als x500-E-Mail-Adresse im 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. Es ist zwar selten, sie könnten aber auch eine X400-Proxyadresse in einem Postfach verwenden. Es ist zwar nicht erforderlich, dass die Verschiebung abgeschlossen ist, es wird jedoch empfohlen, diese Adresse auch auf dem Zielbenutzerobjekt für E-Mail zu stempeln.
Können Quell- und Zielmandanten denselben Domänennamen verwenden?
Nein, die Domänennamen des Quellmandanten und des Zielmandanten müssen eindeutig sein, z. B. 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 diesem Artikel beschrieben:
Haben Sie Empfehlungen für Batches?
Überschreiten Sie nicht mehr als 2.000 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 dem Microsoft Purview-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:
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 mandantenübergreifende Migrationen keine Bezeichnungen exportieren und es keine Möglichkeit gibt, Bezeichnungen zwischen Mandanten freizugeben, können Sie dieses Ziel 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. Dieser eDiscovery-Fehler liegt daran, dass in der Quelle kein Postfach mehr gesucht werden kann, da das Postfach zum Zielmandanten migriert wurde und nun zum Zielmandanten gehört. eDiscovery nach der Postfachmigration kann nur im Zielmandanten (wo das Postfach jetzt vorhanden ist) durchgeführt werden. Wenn eine Kopie des Quellpostfachs nach der Migration im Quellmandanten beibehalten werden muss, kann der Administrator im Quellmandanten 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?
Diese Lizenzzuweisung 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 die Migration abgeschlossen ist, zu warten und während der 30-tägigen Toleranzperiode Lizenzen zuzuweisen.
Kann ich Microsoft Entra Connect verwenden, um Benutzer mit dem neuen Mandanten zu synchronisieren, wenn ich die lokales Active Directory behalte?
Ja. Es ist möglich, dass zwei Instanzen von Microsoft Entra 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 Microsoft Entra Connect-Konfiguration nicht übereinstimmt.
- Abhängig von Ihrem aktuellen Status von Exchange hybrid 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 auszufü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.
Wie sollte ich Postfächer behandeln, die sich in der Nähe oder über dem Kontingent befinden?
Postfächer, die ihr Kontingent vor der Migration nähern, können vor oder während der eigentlichen Migration das Kontingent überschreiten. In diesem Fall schlägt die Migration dieser Postfächer fehl und muss wiederhergestellt und neu gestartet werden. Um dies zu vermeiden, empfiehlt es sich, dass der Quellmandantenadministrator Postfächer vor der Migration mit oder in der Nähe eines Kontingents identifiziert und die erforderlichen Schritte ausführt, um entweder die Postfachgröße zu reduzieren, ein primäres Archiv bereitzustellen oder in einigen Fällen das automatische Erweitern von Archiven für die Postfächer des Benutzers zu aktivieren.
Hinweis
Stellen Sie nach dem Aktivieren eines Archivs oder automatisch erweiternden Archivs für einen Benutzer sicher, dass die richtigen Archivierungsrichtlinien auf den Benutzer angewendet werden und der Prozess ausgeführt wird, um die Postfachdaten an den neuen Speicherort zu verschieben und Speicherplatz freizugeben.
Werden automatisch erweiterte Archivpostfächer verschoben?
Problem: Automatisch erweiterte Archive können nicht migriert werden. Ja, wenn für den Benutzer in der Quelle automatisch erweiternde Archive aktiviert sind und zusätzliche Hilfsarchive vorhanden sind, funktioniert die mandantenübergreifende Postfachmigration. Wir unterstützen das Verschieben von Benutzern, die nicht mehr als 12 zusätzliche Archivpostfächer haben. Darüber hinaus benötigen Benutzer mit großen primären, großen Standard Archiven und großen zusätzlichen Archivpostfächern zusätzliche Zeit für die Synchronisierung und sollten lange vor dem Stichtag eingereicht werden. Wenn das Quellpostfach während des Postfachmigrationsprozesses erweitert wird, schlägt die Migration fehl, da ein neues Hilfsarchiv in der Quelle, aber nicht im Ziel erstellt wird. In diesem Fall müssen Sie den Benutzer aus dem Batch entfernen und erneut übermitteln.
Kann ich eine cloudübergreifende Migration von Mandant zu Mandant durchführen?
Die Cloudmandanten-zu-Mandanten-übergreifende Migration wird nicht unterstützt. Ein Beispielszenario wäre der Wechsel von Office 365 Worldwide zu Office 365 Government Cloud.
Werden Voicemails mandantenübergreifend migriert?
Ja, Voicemails werden mandantenübergreifend migriert.
- Empfangene Voicemails in E-Mail, da Anlagen im Zielpostfach verfügbar sind.
- Empfangene Voicemails sind in Teams verfügbar, wenn Sie Voicemail anrufen und gespeicherte Nachrichten hören. (In der Quelle empfangene VMs sind als gespeicherte Nachrichten verfügbar.)
- Empfangene Voicemails sind in der Teams-Client-Benutzeroberfläche in der Zielmigration nach der Migration nicht verfügbar.
- Die Voicemail-Begrüßung wird ebenfalls zum Ziel migriert.
Werden Postfachsignaturen mandantenübergreifend migriert?
Postfachsignaturen werden nicht mandantenübergreifend migriert und müssen neu erstellt werden.
Bekannte Probleme
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 mit den Anmeldeinformationen des Quellmandanten bei Teams anmeldet, geht die Funktionalität verloren, z. B. weil das Profilbild nicht aktualisiert werden kann, keine Kalenderanwendung vorhanden ist und es nicht möglich ist, öffentliche Teams zu durchsuchen und diesen beizutreten.
Cloud MailUsers with non-owned smtp proxyAddress block MRS moves.Cloud MailUsers with non-owned smtp proxyAddress block MRS moves. Beim Erstellen von MailUser-Objekten des Zielmandanten müssen Sie sicherstellen, dass alle SMTP-Proxyadressen zum Zielmandanten organization 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 ein Postfach verhindert. Diese Verhinderung 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 Microsoft Entra Connect im Zielmandanten synchronisieren, können Sie lokale MailUser-Objekte mit ExternalEmailAddress bereitstellen, die auf den Quellmandanten verweist, in dem das Postfach vorhanden ist (LaraN@contoso.onmicrosoft.com), und Sie die PrimarySMTPAddress als Domäne stempeln, die sich im Zielmandanten (Lara.Newton@northwindtraders.com) befindet. Diese Werte werden mit dem Mandanten synchronisiert, und ein entsprechender E-Mail-Benutzer wird bereitgestellt und ist 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.
MailUser-Objekte mit "externen" primären SMTP-Adressen werden auf "interne" vom Unternehmen beanspruchte Domänen geändert bzw. 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 Ziel-organization) oder das Zielpostfach (aus der Perspektive der Quell-organization) 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. als 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 Domäne angezeigt wird, die vom lokalen organization (contoso.com) überprüft wird. Es gibt zwei mögliche Gründe:
Wenn ein Exchange-Dienstplan auf einen MailUser angewendet wird, beginnt der Microsoft Entra ID Prozess, Proxybereinigung zu erzwingen, um sicherzustellen, dass der lokale organization keine E-Mails, Spoofs oder 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 vom lokalen organization überprüft wird. Wie im Beispiel wird die northwindtraders.com Domäne nicht vom contoso.onmicrosoft.com Mandanten überprüft. Daher entfernt die Bereinigung diese northwindtraders.com Domäne. Wenn Sie diese externen Domänen vor 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, um keine Auswirkungen auf den E-Mail-Dienst zu haben. Ein Beispielskript zum Entfernen der Dienstpläne für einen MailUser im contoso.onmicrosoft.com Mandanten finden Sie hier.
Hinweis
Das folgende Skript verwendet Microsoft Graph PowerShell. Weitere Informationen finden Sie unter Übersicht über Microsoft Graph PowerShell.
Informationen zur Verwendung verschiedener Methoden zur Authentifizierung Connect-Graph in einem unbeaufsichtigten Skript finden Sie im Artikel Cmdlets für das Authentifizierungsmodul in Microsoft Graph PowerShell.
# Connect to Microsoft Graph
Connect-Graph -Scopes User.ReadWrite.All, Organization.Read.All
# Get licensing plans and include disabled plans
$EmsSku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'ENTERPRISEPREMIUM'
$User = Get-MgUser -UserId LaraN@contoso.onmicrosoft.com
$userLicense = Get-MgUserLicenseDetail -UserId $User.Id
$userDisabledPlans = $userLicense.ServicePlans |
Where ProvisioningStatus -eq "Disabled" |
Select -ExpandProperty ServicePlanId
$newDisabledPlans = $EmsSku.ServicePlans |
Where ServicePlanName -in ("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") |
Select -ExpandProperty ServicePlanId
$disabledPlans = $userDisabledPlans + $newDisabledPlans | Select -Unique
$addLicenses = @(
@{SkuId = $EmsSku.SkuId
DisabledPlans = $disabledPlans
}
)
Set-MgUserLicense -UserId '38955658-c844-4f59-9430-6519430ac89b' -AddLicenses $addLicenses -RemoveLicenses @()
Id DisplayName Mail UserPrincipalName UserType
-- ----------- ---- ----------------- --------
38955658-c844-4f59-9430-6519430ac89b Bianca Pisani BiancaP@contoso.onmicrosoft.com Member
Die Ergebnisse im Satz der zugewiesenen ServicePlans werden hier angezeigt:
$order = @(
@{ Expression = 'ProvisioningStatus'; Ascending = $true }
)
Get-MgUserLicenseDetail -UserId '38955658-c844-4f59-9430-6519430ac89b' | Select-Object -ExpandProperty ServicePlans | sort ProvisioningStatus $order
AppliesTo ProvisioningStatus ServicePlanId ServicePlanName
--------- ------------------ ------------- ---------------
User Success 2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2 ADALLOM_S_STANDALONE
User Success 6c6042f5-6f01-4d67-b8c1-eb99d36eed3e STREAM_O365_E5
User Success e212cbc7-0961-4c40-9825-01117710dcb1 FORMS_PLAN_E5
User Success 07699545-9485-468e-95b6-2fca3738be01 FLOW_O365_P3
User Success 9c0dab89-a30c-4117-86e7-97bda240acd2 POWERAPPS_O365_P3
User Success 871d91ec-ec1a-452b-a83f-bd76c7d770ef WINDEFATP
User Success 21b439ba-a0ca-424f-a6cc-52f954a5b111 WIN10_PRO_ENT_SUB
User Success 57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
User Success 8c7d2df8-86f0-4902-b2ed-a0458298f3b3 Deskless
User Success 8e0c0a52-6a6c-4d40-8370-dd62790dcd70 THREAT_INTELLIGENCE
User Success 4a51bca5-1eff-43f5-878c-177680f191af WHITEBOARD_PLAN3
User Success efb0351d-3b08-4503-993d-383af8de41e3 MIP_S_CLP2
User Success 617b097b-4b93-4ede-83de-5f075bb5fb2f PREMIUM_ENCRYPTION
User Success 8c098270-9dd4-4350-9b30-ba4703f3b36b ADALLOM_S_O365
Company Success 94065c59-bc8e-4e8b-89e5-5138d471eaff MICROSOFT_SEARCH
User Success 14ab5db5-e6c4-4b20-b4bc-13e36fd2227f ATA
User Success 3fb82609-8c27-4f7b-bd51-30634711ee67 BPOS_S_TODO_3
User Success b1188c4c-1b36-4018-b48b-ee07604f6feb PAM_ENTERPRISE
User Success 5136a095-5cf0-4aff-bec3-e84448b38ea5 MIP_S_CLP1
User Success 33c4f319-9bdd-48d6-9c4d-410b750a4a5a MYANALYTICS_P2
User Success 5689bec4-755d-4753-8b61-40975025187c RMS_S_PREMIUM2
User Success 4828c8ec-dc2e-4779-b502-87ac9ce28ab7 MCOEV
User Success 9f431833-0334-42de-a7dc-70aa40db46db LOCKBOX_ENTERPRISE
User Success 3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40 MCOMEETADV
User Success 43de0ff5-c92c-492b-9116-175376d08c38 OFFICESUBSCRIPTION
User Success 0feaeb32-d00e-4d66-bd5a-43b5b83db82c MCOSTANDARD
User Success 70d33638-9c74-4d01-bfd3-562de28bd4ba BI_AZURE_P2
Company Success f20fedf3-f3c3-43c3-8267-2bfdd51c0939 ATP_ENTERPRISE
User Success 4de31727-a228-4ec3-a5bf-8e45b5ca48cc EQUIVIO_ANALYTICS
User Success efb87545-963c-4e0d-99df-69c6916d9eb0 EXCHANGE_S_ENTERPRISE
User Success 34c0d7a0-a70f-4668-9238-47f9fc208882 EXCHANGE_ANALYTICS
User Success 8a256a2b-b617-496d-b51b-e76466e88db0 MFA_PREMIUM
User Success 41781fb2-bc02-4b7c-bd55-b576c07bb09d AAD_PREMIUM
User Success bea4c11e-220a-4e6d-8eb8-8ea15d019f90 RMS_S_ENTERPRISE
User Success eec0eb4f-6444-4f95-aba0-50c24d67f998 AAD_PREMIUM_P2
User Success 6c57d4b6-3b23-47a5-9bc9-69f17b4947b3 RMS_S_PREMIUM
User Success 5dbe027f-2339-4123-9542-606e4d348a72 SHAREPOINTENTERPRISE
User Success b737dad2-2f6c-4c65-90e3-ca563267e8b9 PROJECTWORKMANAGEMENT
User Success e95bec33-7c88-4a70-8e19-b10bd9d0c014 SHAREPOINTWAC
User Success 7547a3fe-08ee-4ccb-b430-5077c5041653 YAMMER_ENTERPRISE
User Success a23b959c-7ce8-4e57-9140-b90eb88a9e97 SWAY
User Success c4801e8a-cb58-4c35-aca6-f2dcc106f287 INFORMATION_BARRIERS
User Success b76fb638-6ba6-402a-b9f9-83d28acb3d86 VIVA_LEARNING_SEEDED
Company Success db4d623d-b514-490b-b7ef-8885eee514de Nucleus
Company Success 6f23d6a9-adbf-481c-8538-b4c095654487 M365_LIGHTHOUSE_CUSTOMER_PLAN1
User Success a82fbf69-b4d7-49f4-83a6-915b2cf354f4 VIVAENGAGE_CORE
User Success 9a6eeb79-0b4b-4bf0-9808-39d99a2cd5a3 Windows_Autopatch
User Success cd31b152-6326-4d1b-ae1b-997b625182e6 MIP_S_Exchange
User Success a413a9ff-720c-4822-98ef-2f37c2a21f4c MICROSOFT_COMMUNICATION_COMPLIANCE
User Success 795f6fe0-cc4d-4773-b050-5dde4dc704c9 UNIVERSAL_PRINT_01
Company Success 2b815d45-56e4-4e3a-b65c-66cb9175b560 ContentExplorer_Standard
User Success 7bf960f6-2cd9-443a-8046-5dbff9558365 WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE
User Success 3ec18638-bd4c-4d3b-8905-479ed636b83e CustomerLockboxA_Enterprise
User Success 3efbd4ed-8958-4824-8389-1321f8730af8 MESH_AVATARS_ADDITIONAL_FOR_TEAMS
User Success 99cd49a9-0e54-4e07-aea1-d8d9f5f704f5 Defender_for_Iot_Enterprise
User Success 0898bdbb-73b0-471a-81e5-20f1fe4dd66e KAIZALA_STANDALONE
User Success c948ea65-2053-4a5a-8a62-9eaaaf11b522 PURVIEW_DISCOVERY
User Success a1ace008-72f3-4ea0-8dac-33b3a23a2472 CLIPCHAMP
User Success f6de4823-28fa-440b-b886-4783fa86ddba M365_AUDIT_PLATFORM
User Success 0d0c0d31-fae7-41f2-b909-eaf4d7f26dba Bing_Chat_Enterprise
User Success dcf9d2f4-772e-4434-b757-77a453cfbc02 MESH_AVATARS_FOR_TEAMS
User Success c4b8c31a-fb44-4c65-9837-a21f55fcabda MICROSOFT_LOOP
User Success a6520331-d7d4-4276-95f5-15c0933bc757 GRAPH_CONNECTORS_SEARCH_INDEX
User Success e26c2fcc-ab91-4a61-b35c-03cdc8dddf66 INFO_GOVERNANCE
User Success 46129a58-a698-46f0-aa5b-17f6586297d9 DATA_INVESTIGATIONS
User Success 9d0c4ee5-e4a1-4625-ab39-d82b619b1a34 INSIDER_RISK_MANAGEMENT
User Success 65cc641f-cccd-4643-97e0-a17e3045e541 RECORDS_MANAGEMENT
User Success d2d51368-76c9-4317-ada2-a12c004c432f ML_CLASSIFICATION
User Success bf6f5520-59e3-4f82-974b-7dbbc4fd27c7 SAFEDOCS
User Success 2f442157-a11c-46b9-ae5b-6e39ff4e5849 M365_ADVANCED_AUDITING
User Success 41fcdd7d-4733-4863-9cf4-c65b83ce2df4 COMMUNICATIONS_COMPLIANCE
User Success 6db1f1db-2b46-403f-be40-e39395f08dbb CUSTOMER_KEY
User Success 6dc145d6-95dd-4191-b9c3-185575ee6f6b COMMUNICATIONS_DLP
User Success 199a5c09-e0ca-4e37-8f7c-b05d533e1ea2 MICROSOFTBOOKINGS
User Success ded3d325-1bdc-453e-8432-5bac26d7a014 POWER_VIRTUAL_AGENTS_O365_P3
Company Success d9fa6af4-e046-4c89-9226-729a0786685d Content_Explorer
User Success afa73018-811e-46e9-988f-f75d2b1b8430 CDS_O365_P3
User Success b21a6b06-1988-436e-a07b-51ec6d9f52ad PROJECT_O365_P3
User Success 64bfac92-2b17-4482-b5e5-a0304429de3e MICROSOFTENDPOINTDLP
User Success bf28f719-7844-4079-9c78-c1307898e192 MTP
User Success 28b0fa46-c39a-4188-89e2-58e979a6b014 DYN365_CDS_O365_P3
User Success d587c7a3-bda9-4f99-8776-9bcf59c84f75 INSIDER_RISK
User Success 531ee2f8-b1cb-453b-9c21-d2180d014ca5 EXCEL_PREMIUM
User PendingProvisioning f0ff6ac6-297d-49cd-be34-6dfef97f0c28 MESH_IMMERSIVE_FOR_TEAMS
User PendingInput c1ec4a95-1f05-45b3-a911-aa3fa01094f5 INTUNE_A
Company PendingActivation 882e1d05-acd1-4ccb-8708-6ee03664b117 INTUNE_O365
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 ist ein Beispiel:
Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
UserPrincipalName PrimarySmtpAddress ExternalEmailAddress ExternalDirectoryObjectId
----------------- ------------------ -------------------- -------------------------
ProxyTest@contoso.com ProxyTest@contoso.com SMTP:ProxyTest@contoso.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 eigene Domänen und setzt die primarySMTP-Instanz auf eine domäne zurück. Wenn msExchRemoteRecipientType im lokalen MailUser gelöscht wird, gilt die Proxybereinigungslogik nicht mehr.
Im Folgenden finden Sie den vollständigen Satz der aktuellen Dienstplä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 |
| Graphconnectors Search 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 |
Migrationsfehler
MailboxNotInCrossTenantMigrationScopeException
Stellen Sie sicher, dass der Migrationsbereich auf dem Quellmandanten ordnungsgemäß eingerichtet ist und dass MailboxMovesPublishedScopes in der organization Beziehung zum Zielmandanten festgelegt ist.
Vergewissern Sie sich, dass das zu migrierende Postfach der Sicherheitsgruppe im Quellmandanten hinzugefügt wurde.
Nachdem Sie einen Benutzer zur richtigen Sicherheitsgruppe hinzugefügt haben, setzen Sie den Migrationsbatch fort.AuxArchiveNotFoundInTargetRecipientException
Dieser Fehler liegt daran, dass sich der Benutzer beim Starten des Batches nicht im Migrationsbereich befand und der Benutzer über AuxArchive für die Quelle verfügt.
Fügen Sie den Benutzer der richtigen Sicherheitsgruppe auf dem Quellziel hinzu.
Entfernen Sie den Migrationsbenutzer aus dem Batch.
Entfernen Sie Benutzer mit dem folgenden Befehl:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFügen Sie einen Benutzer zum neuen Batch hinzu.
MailboxIsNotInExpectedDBException
Dieser Fehler ist auf die interne Microsoft-Wartung zurückzuführen.
Entfernen Sie den Migrationsbenutzer aus dem Batch.
Entfernen Sie Benutzer mit dem folgenden Befehl:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFügen Sie einen Benutzer zum neuen Batch hinzu.
NotAcceptedDomainException
Für den Zielbenutzer ist eine ungültige Proxyadresse gestempelt. Ein Beispiel wäre, wenn ein Benutzer in contoso.onmicrosoft.com über eine Proxyadresse von fabrikam.onmicrosoft.com verfügte, bei der es sich um den Quellmandanten handelt.
Entfernen Sie die ungültige Proxyadresse mit dem folgenden Befehl:Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}Setzen Sie den Migrationsbatch fort.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException
Während der Migration wurde ein neues AuxArchive bereitgestellt.
Entfernen Sie den Migrationsbenutzer aus dem Batch.
Entfernen Sie Benutzer mit dem folgenden Befehl:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFügen Sie einen Benutzer zum neuen Batch hinzu.
UserDuplicateInOtherBatchException
Der Benutzer ist bereits in einem anderen Batch vorhanden.
Entfernen Sie den Migrationsbenutzer aus dem Batch.
Entfernen Sie Benutzer mit dem folgenden Befehl:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFügen Sie einen Benutzer zum neuen Batch hinzu.
MissingExchangeGuidException
Dem mailuser-Zielobjekt fehlt der richtige ExchangeGuid-Wert.
Aktualisieren Sie exchangeGuid mit dem folgenden Befehl:Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8Fortsetzen des Migrationsbatches.
SourceMailboxAlreadyBeingMovedPermanentException
Das Quellpostfach verfügt bereits über eine Verschiebungsanforderung. Untersuchen und entfernen Sie die vorhandene Verschiebung. Es ist möglich, dass dies eine interne Microsoft-Verschiebung ist, und Sie müssen warten, bis die Verschiebung abgeschlossen ist.
Entfernen Sie den Migrationsbenutzer aus dem Batch.
Entfernen Sie Benutzer mit dem folgenden Befehl:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFügen Sie einen Benutzer zum neuen Batch hinzu, nachdem die ursprüngliche Verschiebung entfernt oder abgeschlossen wurde.
UserAlreadyHasDemotedArchiveException
Der Benutzer hatte zuvor ein Archivpostfach, das deaktiviert wurde. Wählen Sie eine der beiden folgenden Optionen aus, um dieses Problem zu beheben.
Löschen Sie das deaktivierte Archivpostfach endgültig, dies ist nicht umsetzbar. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Aktivieren Sie das deaktivierte Archivpostfach mit dem folgenden Befehl erneut:Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.Wenn Sie das deaktivierte Archivpostfach erneut aktivieren, müssen Sie die Archiv-GUID für das Zielobjekt mailuser aktualisieren.
Fortsetzen des Migrationsbatches.
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für