Mandantenübergreifende Postfachmigration

Artikel
03/15/2023
30 Minuten Lesedauer

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 in ihre neue Organisation zu migrieren.

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

Benutzer, die migrieren, müssen im Zielmandanten Exchange Online System als 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 einen MailUser konvertiert, und die targetAddress (in Exchange als ExternalEmailAddress dargestellt) wird mit der Routingadresse zum Zielmandanten gestempelt. Dieser Prozess belässt den Legacy-MailUser im Quellmandanten und ermöglicht koexistenz und E-Mail-Routing. Wenn Geschäftsprozesse dies zulassen, kann der Quellmandant den Quell-MailUser entfernen oder ihn in einen E-Mail-Kontakt konvertieren.

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

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

Wichtig

Postfächer, die sich in einem beliebigen Halteraum befinden, werden nicht migriert, und die Verschiebung für dieses Postfach wird blockiert.

Wenn ein Postfach mit diesem Feature mandantenübergreifend migriert wird, werden nur vom Benutzer sichtbare Inhalte im Postfach (E-Mail, Kontakte, Kalender, Aufgaben und Notizen) zum Ziel (Zielmandanten) migriert. Nach erfolgreicher Migration wird das Quellpostfach gelöscht. Dies bedeutet, dass das Quellpostfach nach der Migration unter keinen Umständen im Quellmandanten verfügbar, auffindbar oder zugänglich ist.

Hinweis

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

Lizenzierung

Wichtig

Diese mandantenübergreifende Funktionalität ist nur für Kunden mit Enterprise Agreements verfügbar. Die Lizenzierung ist derzeit nicht über andere Kaufoptionen verfügbar.

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

Microsoft 365 Business Basic/Business Standard/Business Premium/F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; OneDrive for Business.

Vorbereiten von Quell- und Zielmandanten

Voraussetzungen für Quell- und Zielmandanten

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

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

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

Um die Mandanten-ID eines Abonnements abzurufen, melden Sie sich beim Microsoft 365 Admin Center an, und wechseln Sie zu https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. Wählen Sie das Symbol „Kopieren“ für die Mandanten-ID-Eigenschaft 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 mit den Administratoranmeldeinformationen ihres Zielmandanten bei Ihrem Azure AD-Portal (https://portal.azure.com) an.
Wählen Sie unter "Azure Active Directory verwalten" die Option Ansicht aus.
Wählen Sie auf der linken Navigationsleiste "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 Azure AD-Verzeichnis – mehrinstanzenfähig) aus. Wählen Sie dann unter "Umleitungs-URI (optional)" die Option Web aus, und geben Sie ein https://office.com. Wählen Sie abschließend Registrieren aus.
In der oberen rechten Ecke der Seite wird ein Benachrichtigungsfenster angezeigt, in dem angegeben wird, dass die App erfolgreich erstellt wurde.
Zurück zu Start, Azure Active Directory, und wählen Sie "App-Registrierungen" aus.
Suchen Sie unter "Eigene Anwendungen" die app, die Sie erstellt haben, und wählen Sie sie aus.
Unter "Essentials" müssen Sie die "Anwendungs-ID (Client)" kopieren, da Sie sie später benötigen, um eine URL für den Zielmandanten zu erstellen.
Wählen Sie nun auf der linken Navigationsleiste "API-Berechtigungen" aus, um Berechtigungen anzuzeigen, die Ihrer App zugewiesen sind.
Standardmäßig Benutzer. Leseberechtigungen werden der von Ihnen erstellten App zugewiesen, aber wir benötigen sie nicht für Postfachmigrationen. Sie können diese Berechtigung entfernen.
Nun müssen wir die Berechtigung für die Postfachmigration hinzufügen und "Berechtigung hinzufügen" auswählen.
Wählen Sie im Fenster "API-Berechtigungen anfordern" die Option "APIs, die meine Organisation verwendet", suchen Sie nach "Office 365 Exchange Online", und wählen Sie sie aus.
Wählen Sie als Nächstes "Anwendungsberechtigungen" aus.
Erweitern Sie dann unter "Berechtigungen auswählen" postfach, und aktivieren Sie "Mailbox.Migration" und "Berechtigungen hinzufügen" unten auf dem Bildschirm.
Wählen Sie nun in der linken Navigationsleiste für Ihre Anwendung Zertifikatgeheimnisse & aus.
Wählen Sie unter "Geheime Clientschlüssel" die Option "Neuer geheimer Clientschlüssel" aus.
Geben Sie im Fenster Geheimen Clientschlüssel hinzufügen eine Beschreibung ein, und konfigurieren Sie die gewünschten Ablaufeinstellungen.

Hinweis

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

Nachdem Sie jetzt die Migrationsanwendung und das Geheimnis erfolgreich erstellt haben, müssen Sie der Anwendung zustimmen. So stimmen Sie der Anwendung zu:

Zurück zur Azure Active Directory-Angebotsseite, wählen Sie im linken Navigationsbereich Unternehmensanwendungen aus, suchen Sie ihre von Ihnen erstellte Migrations-App, wählen Sie sie aus, und wählen Sie im linken Navigationsbereich Berechtigungen aus.
Wählen Sie die Schaltfläche "Erteilen der Administratoreinwilligung für [Ihren Mandanten]" aus.
Ein neues Browserfenster wird geöffnet und wählt "Akzeptieren" aus.
Sie können zu Ihrem Portalfenster zurückkehren und Aktualisieren auswählen, um Ihre Annahme zu bestätigen.
Formulieren Sie die URL, die an Ihren vertrauenswürdigen Partner (Mandantenadministrator der Quelle) gesendet werden soll, damit auch er die Anwendung annehmen kann, um die Postfachmigration zu aktivieren. Im Folgenden finden Sie ein Beispiel für die URL, die ihm bereitgestellt werden soll. Sie benötigen die Anwendungs-ID der App, die Sie erstellt haben:

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

Hinweis

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

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

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 während dieses Vorgangs konfiguriert haben. Je nachdem, welche Microsoft 365-Cloudinstanz Sie verwenden, kann Ihr Endpunkt unterschiedlich sein. Weitere Informationen finden Sie auf der Seite Microsoft 365-Endpunkte, wählen Sie die richtige Instanz für Ihren Mandanten aus, und überprüfen Sie 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 $AppId

Erstellen Sie ein neues Organisationsbeziehungsobjekt, oder bearbeiten Sie ihr vorhandenes Organisationsbeziehungsobjekt zu Ihrem Quellmandanten.

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

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

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

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

Hinweis

Sie benötigen die Anwendungs-ID der soeben erstellten Postfachmigrations-App. Sie müssen contoso.onmicrosoft.com im obigen Beispiel durch die onmicrosoft.com-URL 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.

Akzeptieren Sie die Anwendung, wenn das Popupfenster angezeigt wird. Sie können sich auch bei Ihrem Azure Active Directory-Portal anmelden und die Anwendung unter „Unternehmensanwendungen“ suchen.
Stellen Sie eine Verbindung mit Exchange Online PowerShell auf dem Quellmandanten Exchange Online her.
Erstellen Sie eine neue Organisationsbeziehung, oder bearbeiten Sie ihr vorhandenes Organisationsbeziehungsobjekt zu Ihrem Zielmandanten (Zielmandanten) in Exchange Online PowerShell:

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

Hinweis

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

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 folgenden Abschnitt werden die Anforderungen des MailUser-Objekts für den Zielmandanten ausführlich erläutert.

Voraussetzungen für Zielbenutzerobjekte

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

Tipp

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

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

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

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

Beispiel für das Mailbox-Quellobjekt :

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

Andere Attribute sind möglicherweise bereits im Hybridrückschreiben von Exchange enthalten. Andernfalls sollten sie einbezogen werden.
1. msExchBlockedSendersHash: Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.
2. msExchSafeRecipientsHash: Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.
3. msExchSafeSendersHash : Schreibt online sichere und blockierte Absenderdaten von Clients zurück in lokales Active Directory.
Wenn die Größe der wiederherstellbaren Elemente des Quellpostfachs größer als unsere Datenbankstandardgröße (30 GB) ist, werden die Verschiebungen nicht fortgesetzt, da das Zielkontingent kleiner als die Größe des Quellpostfachs ist. Sie können das MailUser-Zielobjekt aktualisieren, um die ELC-Postfachflags von der Quellumgebung auf das Ziel zu übertragen, wodurch das Zielsystem das Kontingent des MailUser auf 100 GB erhöht, wodurch die Verschiebung zum Ziel ermöglicht wird. In einer Hybridumgebung müssen Sie die entsprechenden msExchELCMailboxFlags auf dem Ziel-ADUser festlegen.
Nicht hybride Zielmandanten können das Kontingent im Ordner "Wiederherstellbare Elemente" für die MailUsers vor der Migration ändern, indem sie den folgenden Befehl ausführen, um das Beweissicherungsverfahren für das MailUser-Zielobjekt zu aktivieren und das Kontingent auf 100 GB zu erhöhen:

Set-MailUser -Identity <MailUserIdentity> -EnableLitigationHoldForMigration

Dies funktioniert nicht für Mandanten in einer Hybridkonfiguration.

Benutzer in der Zielorganisation müssen mit entsprechenden Exchange Online-Abonnements lizenziert sein, die für die Organisation gelten. Sie können eine Lizenz vor dem Verschieben eines Postfachs anwenden, aber NUR, wenn der MailUser-Zielbenutzer ordnungsgemäß mit ExchangeGUID und Proxyadressen eingerichtet wurde. Das Anwenden einer Lizenz, bevor exchangeGUID angewendet wird, führt zu einem neuen Postfach, das in der Zielorganisation bereitgestellt wird. Außerdem müssen Sie eine lizenzübergreifende Benutzerdatenmigration anwenden. Andernfalls wird möglicherweise ein vorübergehender Fehler mit dem Hinweis "Genehmigung erforderlich" angezeigt, der eine Warnung im Verschiebungsbericht meldet, 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 MailUser-Ziel keine vorherige ExchangeGuid aufweist, die nicht mit der ExchangeGuid-Quelle übereinstimmt. Dies kann vorkommen, wenn die Ziel-MEU zuvor für Exchange Online lizenziert und ein Postfach bereitgestellt wurde. Wenn der MailUser-Zielbenutzer zuvor für lizenziert war oder über eine ExchangeGuid verfügte, die nicht mit der Quell-ExchangeGuid übereinstimmt, müssen Sie eine Bereinigung der Cloud-MEU durchführen. Für diese Cloud-MEUs können Sie ausführen Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Achtung

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

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

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

Hier 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 diesem 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]"

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

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

Durchführen von Postfachmigrationen

Mandantenübergreifende Exchange-Postfachmigrationen werden vom Zielmandanten als Migrationsbatches initiiert. Dies ähnelt der Funktionsweise von Onboarding-Migrationsbatches bei der Migration von lokalen Exchange-Instanzen 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.

Es folgt eine minimale BEISPIEL-CSV-Datei:

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

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

Aktualisieren lokaler MailUsers

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

Entfernen von Endpunkten und Organisationsbeziehungen nach der Migration

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

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

Häufig gestellte Fragen

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 einer Hybridorganisation 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.

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

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

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

Verwenden Sie den Parameter Flags :

Get-MoveRequest -Flags "CrossTenant"

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

Hinweis

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

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the northwindtraders tenant
$outFileUsers = "$home\desktop\UsersToMigrate.txt"
$outFileUsersXML = "$home\desktop\UsersToMigrate.xml"
Get-Mailbox -Filter "CustomAttribute1 -like 'Cross-Tenant-Project'" -ResultSize Unlimited | Select-Object -ExpandProperty  Alias | Out-File $outFileUsers
$mailboxes = Get-Content $outFileUsers
$mailboxes | ForEach-Object {Get-Mailbox $_} | Select-Object PrimarySMTPAddress,Alias,SamAccountName,FirstName,LastName,DisplayName,Name,ExchangeGuid,ArchiveGuid,LegacyExchangeDn,EmailAddresses | Export-Clixml $outFileUsersXML

# Copy the file $outfile to the desktop of the target on-premises then run the below to create MEU in Target
$symbols = '!@#$%^&*'.ToCharArray()
@([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 neu synchronisierten OST-Inhalt neu erstellen.

Hinweis

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

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

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

Die erste Rolle ist für eine einmalige Einrichtungsaufgabe, die die Autorisierung zum Verschieben von Inhalten in oder aus Ihrer Mandanten-/Organisationsgrenze festlegt. Da das Verschieben von Daten aus der Kontrolle Ihrer Organisation ein kritisches 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 -MailboxMoveCapability mit der Remoteorganisation definiert. Nur die Organisations-Admin kann die Einstellung MailboxMoveCapability ändern, während andere Attribute in der OrganizationRelationship vom Verbundfreigabeadministrator verwaltet werden können.
Die Rolle der Ausführung der tatsächlichen Verschiebungsbefehle kann an eine Funktion auf niedrigerer Ebene delegiert werden. Die Rolle von Postfächer verschieben wird der Funktion zum Verschieben von Postfächern in oder aus der Organisation zugewiesen.

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

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

Wie funktioniert der Nachrichtenfluss nach der Migration?

Der mandantenübergreifende E-Mail-Fluss nach der Migration funktioniert ähnlich wie der Exchange-Hybrid-E-Mail-Fluss. Jedes migrierte Postfach benötigt den MailUser-Quellbenutzer mit der richtigen 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- und 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?

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

Beispiel:

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

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

Hinweis

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

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

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

Werden freigegebene Postfächer verschoben und funktionieren sie weiterhin?

Ja. Wir behalten jedoch nur die Store-Berechtigungen wie in den folgenden Artikeln 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: https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

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

Da 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 mandantenübergreifende Postfachmigrationen die Migration von Microsoft 365-Gruppen nicht.

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

Nein, nach einer mandantenübergreifenden Postfachmigration funktioniert eDiscovery für das Postfach des migrierten Benutzers in der Quelle nicht. Dies liegt daran, dass es in der Quelle kein Postfach mehr gibt, nach dem 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 in der Quelle den Inhalt vor der Migration in ein alternatives Postfach kopieren, um zukünftige eDiscovery-Vorgänge anhand der Daten durchzuführen.

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

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

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

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

Kann ich Azure AD 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 Azure AD Connect mit verschiedenen Mandanten synchronisiert werden. Es gibt jedoch einige Dinge, die Sie beachten müssen:

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

Werden automatisch erweiterte Archivpostfächer verschoben?

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 Hauptarchiven und großen zusätzlichen Archivpostfächern zusätzliche Zeit für die Synchronisierung und sollten lange vor dem Übernahmedatum eingereicht werden. Beachten Sie außerdem, dass die Migration fehlschlägt, wenn das Quellpostfach während des Postfachmigrationsprozesses erweitert wird, 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.

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 mit nicht im Besitz befindlichem SMTP-ProxyAddress blockieren MRS-Verschiebungen. Beim Erstellen von MailUser-Objekten des Zielmandanten müssen Sie sicherstellen, dass alle SMTP-Proxyadressen zur Organisation des Zielmandanten gehören. Wenn eine SMTP-proxyAddress für den E-Mail-Zielbenutzer vorhanden ist, der nicht zum lokalen Mandanten gehört, wird die Konvertierung von MailUser in ein Postfach verhindert. Dies ist auf unsere Zusicherung zurückzuführen, dass Postfachobjekte E-Mails nur von Domänen senden können, für die der Mandant autoritativ ist (Domänen, die vom Mandanten beansprucht werden).
- Wenn Sie Benutzer aus der lokalen Umgebung mithilfe von Azure AD Connect 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 befindet (Lara.Newton@northwindtraders.com). Diese Werte werden mit dem Mandanten synchronisiert, und ein entsprechender E-Mail-Benutzer wird bereitgestellt und bereit für die Migration. Ein Beispielobjekt wird hier gezeigt.

Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

ExternalEmailAddress               EmailAddresses
--------------------               --------------
SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}

Hinweis

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

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

MailUser-Objekte sind Zeiger auf nicht lokale Postfächer. Bei mandantenübergreifenden Postfachmigrationen verwenden wir MailUser-Objekte, um entweder das Quellpostfach (aus sicht der Zielorganisation) oder das Zielpostfach (aus der Perspektive der Quellorganisation) darzustellen. Die MailUsers verfügen über eine ExternalEmailAddress (targetAddress), die auf die SMTP-Adresse des tatsächlichen Postfachs (ProxyTest@northwindtraders.onmicrosoft.com) verweist, und die primäreSMTP-Adresse, die die angezeigte SMTP-Adresse des Postfachbenutzers im Verzeichnis darstellt. Einige Organisationen entscheiden sich dafür, die primäre SMTP-Adresse als externe SMTP-Adresse anzuzeigen, nicht als Adresse im Besitz des lokalen Mandanten (z. B. northwindtraders.com und nicht als contoso.com). Sobald jedoch ein Exchange-Dienstplanobjekt über Lizenzierungsvorgänge auf mailUser angewendet wird, wird die primäre SMTP-Adresse so geändert, dass sie als von der lokalen Organisation überprüfte Domäne angezeigt wird (contoso.com). Es gibt zwei mögliche Gründe:
- Wenn ein Exchange-Dienstplan auf einen MailUser angewendet wird, beginnt der Azure AD-Prozess, proxybereinigung zu erzwingen, um sicherzustellen, dass die lokale Organisation keine E-Mails, 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 von der lokalen Organisation überprüft wird. Wie im Beispiel wird die northwindtraders.com Domäne nicht vom contoso.onmicrosoft.com Mandanten überprüft, sodass die Bereinigung diese northwindtraders.com Domäne entfernt. Wenn Sie diese externen Domänen entweder vor der Migration oder nach der Migration auf MailUser beibehalten möchten, müssen Sie Ihre Migrationsprozesse so ändern, dass lizenzen nach Abschluss der Verschiebung oder vor der Verschiebung entfernt werden, um sicherzustellen, dass für die Benutzer das erwartete externe Branding angewendet wird. Sie müssen sicherstellen, dass das Postfachobjekt ordnungsgemäß lizenziert ist, 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.

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

Die Ergebnisse im Satz 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 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 im Besitz befindliche Domänen und setzt die primarySMTP auf eine domäne zurück. Durch das Löschen von msExchRemoteRecipientType im lokalen MailUser wird die Proxybereinigungslogik nicht mehr angewendet.

Im Folgenden finden Sie den vollständigen Satz der aktuellen 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
Suche nach Graphconnectors mit Index
Business Information Barriers
Information Protection für Office 365 – Premium
Information Protection für Office 365 – Standard
Erkenntnisse von MyAnalytics
Microsoft Information Governance
Microsoft Purview Audit (Premium)
Microsoft Bookings
Microsoft Business Center
Microsoft-Datenuntersuchungen
Microsoft MyAnalytics (Vollversion)
Microsoft Communications Compliance
Microsoft Communications DLP
Microsoft-Kundenschlüssel
Erweiterte Überwachung von Microsoft 365
Microsoft-Datensatzverwaltung
Office 365 eDiscovery (Premium)
Office 365 Advanced eDiscovery
Microsoft Defender for Office 365 (Plan 1)
Microsoft Defender for Office 365 (Plan 2)
Office 365 Privileged Access Management
Premium-Verschlüsselung in Office 365

Mandantenübergreifende Postfachmigration

Lizenzierung

Vorbereiten von Quell- und Zielmandanten

Voraussetzungen für Quell- und Zielmandanten

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

Vorbereiten des Zielmandanten durch Erstellen der Migrationsanwendung und des Geheimnisses

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

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

Vorbereiten von Zielbenutzerobjekten für die Migration

Voraussetzungen für Zielbenutzerobjekte

Woher weiß ich, dass der Vorgang erfolgreich war?

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

Durchführen von Postfachmigrationen

Erstellen von Migrationsbatches

Aktualisieren lokaler MailUsers

Entfernen von Endpunkten und Organisationsbeziehungen nach der Migration

Häufig gestellte Fragen

Muss ich RemoteMailboxes im lokalen Quellmandanten nach dem Verschieben aktualisieren?

Exchange-Quellorganisation

Exchange-Zielorganisation

Werden Teams-Besprechungen mandantenübergreifend migriert?

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

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

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

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

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

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

Wie funktioniert der Nachrichtenfluss nach der Migration?

Wie werden Postfachberechtigungen übergangen?

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

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

Werden freigegebene Postfächer verschoben und funktionieren sie weiterhin?

Haben Sie Empfehlungen für Batches?

Was geschieht, wenn ich die Dienstverschlüsselung mit dem Microsoft Purview-Kundenschlüssel verwende?

Wie lange wird die Migration geschätzt?

Schützen von Dokumenten im Quellmandanten, die von Benutzern im Zielmandanten genutzt werden 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.**

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

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

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

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

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

Werden automatisch erweiterte Archivpostfächer verschoben?

Bekannte Probleme

Zusätzliche Ressourcen

Zusätzliche Ressourcen