Migration de boîtes aux lettres inter-clients

Article
02/01/2024

Pendant les fusions ou les cessions, vous devrez peut-être déplacer les boîtes aux lettres Exchange Online de vos utilisateurs dans un nouveau locataire. La migration de boîtes aux lettres interlocataires permet aux administrateurs locataires d’utiliser des interfaces connues telles que Exchange Online PowerShell et MRS pour effectuer la transition des utilisateurs vers leur nouvelle organization.

Les administrateurs peuvent utiliser l’applet de commande New-MigrationBatch , disponible via le rôle de gestion Déplacer les boîtes aux lettres , pour effectuer des déplacements entre locataires.

Les utilisateurs qui migrent doivent être présents dans le système Exchange Online client cible en tant que MailUser, marqué avec des attributs spécifiques pour permettre les déplacements entre locataires. Le système ne parvient pas à déplacer les utilisateurs qui ne sont pas correctement configurés dans le locataire cible.

Une fois les déplacements terminés, la boîte aux lettres de l’utilisateur source est convertie MailUseren , et le targetAddress (indiqué comme ExternalEmailAddress dans Exchange) est horodaté avec l’adresse de routage vers le locataire de destination. Ce processus laisse l’héritage MailUser dans le locataire source et permet la coexistence et le routage du courrier. Lorsque les processus métier l’autorisent, le locataire source peut supprimer l’utilisateur MailUser source ou le convertir en contact de messagerie.

Les migrations de boîtes aux lettres Exchange interlocataires sont prises en charge pour les locataires dans un environnement hybride ou cloud uniquement, ou une combinaison des deux.

Cet article décrit le processus de déplacement de boîtes aux lettres interlocataires et fournit des conseils sur la façon de préparer les locataires sources et cibles pour les déplacements de contenu de boîte aux lettres Exchange Online.

Importante

Les boîtes aux lettres qui se trouvent sur n’importe quel type de mise en attente ne sont pas migrées et le déplacement de ces boîtes aux lettres est bloqué.

Lorsqu’une boîte aux lettres est migrée entre locataires avec cette fonctionnalité, seul le contenu visible par l’utilisateur dans la boîte aux lettres (e-mail, contacts, calendrier, tâches et notes) est migré vers la cible (locataire de destination). Après une migration réussie, la boîte aux lettres source est supprimée. Cette suppression signifie qu’après la migration, la boîte aux lettres source n’est en aucun cas disponible, détectable ou accessible dans le locataire source.

Licences

Importante

À compter de novembre 2022, la migration des données utilisateur interlocataires est disponible en tant que module complémentaire pour les plans d’abonnement Microsoft 365 suivants pour les clients Accord Entreprise, et est requise pour les migrations entre locataires. Les licences utilisateur sont par migration (frais ponctuels) et peuvent être attribuées sur l’objet utilisateur source ou cible. Cette licence couvre également OneDrive Entreprise migration. Pour plus d’informations, contactez votre équipe de compte Microsoft.

Le module complémentaire de migration des données utilisateur inter-locataires est disponible en tant qu’achat distinct pour Microsoft 365 Business Basic, Standard et Premium. Microsoft 365 F1/F3/E3/E5/ ; Office 365 F3/E1/E3/E5 ; Exchange Online ; SharePoint Online ; et OneDrive Entreprise.

Avertissement

Vous devez avoir acheté ou vérifié que vous pouvez acheter des licences de migration de données utilisateur interlocataires avant les étapes suivantes. Les migrations échouent si cette étape n’a pas été effectuée. Microsoft n’offre pas d’exceptions pour cette exigence de licence.

Si vous n’avez pas la licence appropriée affectée à l’utilisateur en cours de migration, la migration échoue et vous recevez une erreur similaire à ce qui suit :

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.

Préparation des locataires source et cible

Conditions préalables pour les locataires source et cible

Avant de commencer, vérifiez que vous disposez des autorisations nécessaires pour configurer l’application Déplacer la boîte aux lettres dans Azure, le point de terminaison de migration EXO et la relation d’organisation EXO.

En outre, au moins un groupe de sécurité compatible avec la messagerie dans le client source est requis. Ces groupes sont utilisés pour définir l’étendue de la liste des boîtes aux lettres qui peuvent passer du locataire source (ou parfois appelé ressource) au locataire cible. Cette étendue permet à l’administrateur du locataire source de restreindre ou d’étendre l’ensemble spécifique de boîtes aux lettres qui doivent être déplacées, empêchant ainsi la migration d’utilisateurs involontaires.

Si vous migrez plus de 10 000 utilisateurs, nous vous recommandons de créer plusieurs groupes pour contenir la liste des utilisateurs pour des performances optimales. Bien que les groupes imbriqués soient pris en charge, ils ne sont pas recommandés.

Vous devez également communiquer avec votre entreprise partenaire de confiance (avec laquelle vous allez déplacer des boîtes aux lettres) pour obtenir leur ID de locataire Microsoft 365. Cet ID de locataire est utilisé dans le champ Nom de domaine de la relation d’organisation .

Pour obtenir l’ID de locataire d’un abonnement, connectez-vous au Centre d’administration Microsoft 365 et accédez à https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Sélectionnez l’icône de copie pour la propriété ID de locataire pour la copier dans le Presse-papiers.

Tous les utilisateurs des organisations source et cible doivent disposer d’une licence avec les abonnements Exchange Online appropriés. Veillez également à appliquer des licences de migration de données utilisateur inter-locataires à tous les utilisateurs qui seront migrés vers le côté cible.

Étapes de configuration pour activer vos locataires pour les migrations de boîtes aux lettres interlocataires

Remarque

Vous devez d’abord configurer la cible (destination). Pour effectuer ces étapes, vous n’avez pas besoin d’avoir ou de connaître les informations d’identification de l’administrateur client pour le locataire source et le locataire cible. Les étapes peuvent être effectuées individuellement pour chaque client par différents administrateurs.

Préparer le client cible (destination) en créant l’application de migration et le secret

Connectez-vous à votre centre d’administration Microsoft Entra (https://portal.azure.com) avec vos informations d’identification d’administrateur de locataire cible.
Sous Gérer Microsoft Entra ID, sélectionnez Afficher.
Dans le volet de navigation, sélectionnez inscriptions d'applications.
Sélectionnez Nouvelle inscription.
Dans la page Inscrire une application, sous Types de comptes pris en charge, sélectionnez Comptes dans n’importe quel annuaire d’organisation (n’importe quel annuaire Microsoft Entra - Multilocataire). Ensuite, sous URI de redirection (facultatif), sélectionnez Web, puis tapez https://office.com. Ensuite, sélectionnez Inscrire.

En haut à droite de la page, consultez la boîte de dialogue de notification qui indique que l’application a été créée avec succès.
Retour à la page Accueil, accédez à Microsoft Entra ID, puis sélectionnez inscriptions d'applications.
Sous Applications détenues, recherchez l’application que vous avez créée, puis sélectionnez-la.
Sous Essentials, copiez l’ID d’application (client). Vous aurez besoin de ces informations ultérieurement pour créer une URL pour le locataire cible.
Dans le volet de navigation, sélectionnez Autorisations d’API pour afficher les autorisations attribuées à votre application.
Par défaut, les autorisations User.Read sont attribuées à l’application que vous avez créée, mais ces autorisations ne sont pas requises pour les migrations de boîtes aux lettres. Vous pouvez supprimer ces autorisations.
Pour ajouter une autorisation pour la migration de boîte aux lettres, sélectionnez Ajouter une autorisation.
Dans la fenêtre Demander des autorisations d’API, sélectionnez API que mon organization utilise, recherchez Office 365 Exchange Online, puis sélectionnez-la.
Sélectionnez Autorisations d’application.
Sous Sélectionner les autorisations, développez Boîte aux lettres , sélectionnez Mailbox.Migration, puis sélectionnez Ajouter des autorisations en bas de l’écran.
Sélectionnez maintenant Certificats & secrets dans le volet de navigation de votre application.
Sous Clés secrètes client, sélectionnez Nouvelle clé secrète client.
Dans la fenêtre Ajouter une clé secrète client , tapez une description, puis configurez vos paramètres d’expiration.

Remarque

Le mot de passe est utilisé lors de la création de votre point de terminaison de migration. Il est extrêmement important que vous copiez ce mot de passe dans le Presse-papiers et/ou dans un emplacement sécurisé/secret de mot de passe. L’étape de création du secret est la seule fois pendant laquelle vous pouvez voir ce mot de passe ! Si vous le perdez ou que vous devez le réinitialiser, vous pouvez vous reconnecter à la Portail Azure, accéder à inscriptions d'applications, rechercher votre application de migration, sélectionner Secrets & certificats, puis créer un secret pour votre application.

Maintenant que vous avez créé l’application de migration et le secret, l’étape suivante consiste à donner votre consentement à l’application.

Dans la page d’accueil Microsoft Entra ID, sélectionnez Applications d’entreprise dans le volet de navigation, recherchez l’application de migration que vous avez créée, sélectionnez-la, puis sélectionnez Autorisations d’API.
Sélectionnez Accorder le consentement administrateur pour [votre locataire]. Une nouvelle fenêtre de navigateur s’ouvre.
Sélectionnez Accepter.
Retour à la fenêtre de votre portail et sélectionnez Actualiser pour confirmer votre acceptation.
Formulez l’URL à envoyer à votre partenaire approuvé (administrateur du locataire source) afin qu’il puisse également accepter l’application pour activer la migration de boîtes aux lettres.

Voici un exemple d’URL à leur fournir :

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

Remarque

Vous aurez besoin de l’ID d’application de l’application de migration de boîte aux lettres que vous venez de créer. Vous devez remplacer contoso.onmicrosoft.com dans l’exemple ci-dessus par le nom de onmicrosoft.com correct de votre locataire source. Vous devez également remplacer [application_id_of_the_app_you_just_created] par l’ID d’application de l’application de migration de boîte aux lettres que vous venez de créer.

Préparez le client cible en créant le point de terminaison de la migration vers Exchange Online et la relation avec l'organisation.

Connectez-vous à Exchange Online PowerShell dans le locataire Exchange Online cible.

Créez un point de terminaison de migration pour les déplacements de boîtes aux lettres interlocataires.

Remarque

Vous aurez besoin de l’ID d’application de l’application de migration de boîtes aux lettres que vous venez de créer et du mot de passe (secret) que vous avez configuré dans Préparer le locataire cible (destination) en créant l’application de migration et le secret. Selon les instance cloud Microsoft 365 que vous utilisez, votre point de terminaison peut être différent. Consultez la page points de terminaison Microsoft 365 ; Sélectionnez la instance appropriée pour votre locataire, puis passez en revue l’adresse Exchange Online Optimiser/Obligatoire, puis remplacez le cas échéant.

$AppId = "[Guid copied from the migrations app]"
$name = "[the name of your new migration endpoint]"
$remote = "<contoso>.onmicrosoft.com"
$secret = "[this is your secret password you saved in the previous steps]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String $secret -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant $remote -Credentials $Credential -ExchangeRemoteMove:$true -Name $name -ApplicationId $AppId

Créez un objet de relation organization ou modifiez votre objet de relation organization existant sur votre locataire source.

$sourceTenantId = "[tenant ID of your trusted partner, where the source mailboxes are]"
$orgrelname = "[name of your new organization relationship]"
$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 $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

Préparez le locataire source (emplacement actuel de la boîte aux lettres) en acceptant l’application de migration et en configurant la relation organization

À l’aide de votre navigateur, accédez au lien URL fourni par votre partenaire de confiance pour donner son consentement à l’application de migration de boîte aux lettres. L’URL doit ressembler à ceci :

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

Remarque

Vous aurez besoin de l’ID d’application de l’application de migration de boîte aux lettres que vous venez de créer. Dans l’exemple précédent, vous devez remplacer contoso.onmicrosoft.com par l’URL de onmicrosoft.com votre locataire source. Vous devez également remplacer [application_id_of_the_app_you_just_created] par l’ID d’application de l’application de migration de boîte aux lettres que vous venez de créer.
Acceptez l’application lorsque la fenêtre contextuelle s’affiche. Vous pouvez également vous connecter à votre centre d’administration Microsoft Entra et rechercher l’application sous Applications d’entreprise.
Connectez-vous à Exchange Online PowerShell sur le locataire source Exchange Online.

Créez un objet de relation organization ou modifiez votre objet de relation organization existant sur votre locataire cible (de destination) dans 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]"
$orgrelname = "[name of your new organization relationship]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host "Group already exists." }
$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 $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

Remarque

L’ID client que vous entrez en tant que $sourceTenantId et $targetTenantId est le GUID et non le nom de domaine du client. Pour obtenir un exemple d’ID client et des informations sur la recherche de votre ID client, consultez Rechercher votre ID client Microsoft 365.

Préparer les objets utilisateur cibles pour la migration

Les utilisateurs qui migrent doivent être présents dans le locataire cible et Exchange Online système (en tant que MailUser) marqués avec des attributs spécifiques pour permettre les déplacements inter-locataires. Le système ne parvient pas à déplacer les utilisateurs qui ne sont pas correctement configurés dans le locataire cible. La section Prérequis pour les objets utilisateur cible détaille la configuration requise de l’objet MailUser pour le locataire cible.

Prérequis pour les objets utilisateur cibles

Vérifiez que les objets et attributs suivants sont définis dans le organization cible :

Conseil

Microsoft développe une fonctionnalité pour fournir une méthode automatisée sécurisée pour définir la plupart des attributs (spécifiés ci-dessous, dans cette section). Cette fonctionnalité, nommée Cross-Tenant Identity Mapping, est actuellement à la recherche de clients désireux de participer à une petite préversion privée. Pour plus d’informations sur cette fonctionnalité en préversion et sur la façon dont elle peut simplifier vos processus de migration interlocataires, consultez Mappage d’identités entre locataires.

Pour toute boîte aux lettres déplacée à partir d’un organization source, vous devez provisionner un objet MailUser dans le organization cible :

Target MailUser doit avoir les attributs suivants de la boîte aux lettres source ou attribués avec le nouvel objet User :

ExchangeGUID (flux direct de la source vers la cible) : le GUID de boîte aux lettres doit correspondre. Le processus de déplacement ne se poursuit pas si cet attribut n’est pas présent sur l’objet cible.
ArchiveGUID (flux direct de la source vers la cible) : le GUID d’archive doit correspondre. Le processus de déplacement ne se poursuit pas si cet attribut n’est pas présent sur l’objet cible. (Cet attribut n’est requis que si la boîte aux lettres source est activée pour l’archivage).
LegacyExchangeDN (flux en tant que proxyAddress, « x500 :<LegacyExchangeDN> ») : Le legacyExchangeDN doit être présent sur la cible MailUser sous la forme x500 : proxyAddress. En outre, vous devez également copier toutes les adresses x500 de la boîte aux lettres source vers l’utilisateur de messagerie cible. Les processus de déplacement ne se poursuivent pas si ces adresses x500 ne sont pas présentes sur l’objet cible. En outre, cette étape est importante pour activer la capacité de réponse pour les e-mails envoyés avant la migration. L’adresse de l’expéditeur/destinataire dans chaque élément de courrier électronique et le cache de saisie semi-automatique dans Microsoft Outlook et dans Microsoft Outlook Web App (OWA) utilisent la valeur de l’attribut LegacyExchangeDN. Si un utilisateur ne peut pas être localisé à l’aide de la valeur LegacyExchangeDN, la remise des messages électroniques peut échouer avec une remise 5.1.1 NDR.
UserPrincipalName : l’UPN s’aligne sur la NOUVELLE identité ou la société cible de l’utilisateur (par exemple, user@northwindtraders.onmicrosoft.com).
Adresse SMTP principale : l’adresse SMTP principale s’aligne sur la NOUVELLE entreprise de l’utilisateur (par exemple, user@northwindtraders.com).
TargetAddress/ExternalEmailAddress : MailUser fait référence à la boîte aux lettres actuelle de l’utilisateur hébergée dans le locataire source (par exemple user@contoso.onmicrosoft.com). Lorsque cette valeur est affectée, vérifiez que vous avez ou que vous affectez également PrimarySMTPAddress ; Sinon, cette valeur définit primarySMTPAddress, ce qui entraîne des échecs de déplacement.

Vous ne pouvez pas ajouter d’adresses proxy smtp héritées de la boîte aux lettres source à MailUser cible. Par exemple, vous ne pouvez pas conserver contoso.com sur le meU dans northwindtraders.onmicrosoft.com objets de locataire. Les domaines sont associés à un seul locataire Microsoft Entra ID ou Exchange Online.

Exemple d’objet MailUser cible :

Attribut	Valeur
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

Exemple d’objet Mailbox source :

Attribut	Valeur
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

D’autres attributs peuvent déjà être inclus dans l’écriture différée hybride Exchange. Si ce n’est pas le cas, ils doivent être inclus.
1. msExchBlockedSendersHash: réécrit en ligne les données de l’expéditeur bloqué des clients dans Active Directory local.
2. msExchSafeRecipientsHash: réécrit les données des destinataires sécurisés en ligne des clients dans Active Directory local.
3. msExchSafeSendersHash: réécrit les données de l’expéditeur sécurisé en ligne des clients dans Active Directory local.
Les utilisateurs de l’organisation cible doivent disposer d’une licence avec les abonnements Exchange Online appropriés applicables à l’organisation. Vous pouvez appliquer une licence avant le déplacement d’une boîte aux lettres, mais uniquement une fois que l’utilisateur MailUser cible est correctement configuré avec ExchangeGUID et les adresses proxy. L’application d’une licence avant l’application d’ExchangeGUID entraîne l’approvisionnement d’une nouvelle boîte aux lettres dans les organization cibles. Vous devez également appliquer une licence de migration de données utilisateur interlocataire ; Sinon, vous pouvez voir une erreur temporaire de lecture doit être approuvée, ce qui signale un avertissement dans le rapport de déplacement indiquant qu’une licence n’a pas été appliquée à l’utilisateur cible.

Remarque

Lorsque vous appliquez une licence sur une boîte aux lettres ou un objet MailUser, toutes les adresses proxy de type SMTP sont nettoyées pour garantir que seuls les domaines vérifiés sont inclus dans le tableau Exchange EmailAddresses.
Vous devez vous assurer que l’objet MailUser cible n’a pas de code ExchangeGUID précédent qui ne correspond pas à l’objet ExchangeGUID source. Cette incompatibilité peut se produire si l’utilisateur MEU cible était précédemment concédé sous licence pour Exchange Online et approvisionnait une boîte aux lettres. Si le MailUser cible était précédemment sous licence pour ou avait un ExchangeGUID qui ne correspond pas à la source ExchangeGUID, vous devez effectuer un nettoyage de l’MEU cloud. Pour ces MEU cloud, vous pouvez exécuter Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Attention

Ce processus est irréversible. Si l’objet a une boîte aux lettres supprimée de manière réversible, il ne peut pas être restauré après ce point. Une fois effacé, toutefois, vous pouvez synchroniser le bon ExchangeGUID avec l’objet cible, et MRS connecte la boîte aux lettres source à la boîte aux lettres cible nouvellement créée. (Consultez le blog EHLO sur le nouveau paramètre.)

Recherchez des objets qui étaient auparavant des boîtes aux lettres à l’aide de la commande suivante :

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

Voici un exemple :

Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize

Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
----       ---------------------------- ------------- --------------------
John       UserMailbox                  MailUser      MailUser

Effacez la boîte aux lettres supprimée de manière réversible à l’aide de la commande suivante :

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Voici un exemple :

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

Comment savoir si cela a fonctionné ?

Vous pouvez vérifier la configuration de la migration de boîte aux lettres interlocataire en exécutant l’applet de commande Test-MigrationServerAvailability sur le point de terminaison de migration interlocataire que vous avez créé sur votre locataire cible. Exécutez l’applet de commande suivante à partir du locataire cible :

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

Remarque

En outre, vous souhaiterez peut-être tirer parti du script de validation de la migration de boîte aux lettres interlocataire, qui vous permettra de valider les organisations correctement configurées entre elles et les objets que vous envisagez de migrer d’un locataire à un autre. Le script permet d’identifier les écarts qui peuvent être présents sur tous les objets à la fois et, par conséquent, il réduit le temps consacré à la phase initiale.

Déplacer les boîtes aux lettres vers la source d’origine

Si une boîte aux lettres est nécessaire pour revenir au locataire source d’origine, le même ensemble d’étapes et de scripts doit être exécuté dans les nouveaux locataires source et cible, avec une certaine variation.

N’exécutez pas les exemples de scripts fournis pour créer l’OrganizationRelationship.

Mettez à jour les valeurs suivantes dans le OrganizationRelationship existant créé dans chaque locataire :

MailboxMovesCapability doit avoir des fonctionnalités entrantes et sortantes comme fonctionnalités dans les locataires source et cible.
Dans le nouveau locataire source, mettez à jour la valeur OAuthApplicationId avec la valeur de l’application nouvellement créée dans le nouveau locataire source.
Dans le nouveau locataire source, mettez à jour la valeur MailboxMovePublishedScopes avec le groupe de sécurité nouvellement créé dans le nouveau locataire source.

Effectuer des migrations de boîtes aux lettres

Les migrations de boîtes aux lettres Exchange interlocataires sont lancées à partir du locataire cible en tant que lots de migration. Ce processus est similaire à la façon dont les lots de migration d’intégration fonctionnent lors de la migration d’Exchange local vers Microsoft 365.

Créer des lots de migration

Voici un exemple de commande pour lancer une migration par lots :

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

Remarque

L’adresse e-mail dans le fichier CSV doit être celle spécifiée dans le locataire cible (par exemple, userA@northwindtraders.onmicrosoft.com), et non celle du locataire source. Pour plus d’informations sur l’applet de commande, cliquez ici Pour obtenir des exemples d’informations de fichier CSV, cliquez ici

Voici un exemple minimal de fichier CSV :

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

La soumission par lots de migration est également prise en charge à partir du nouveau centre d’administration Exchange lors de la sélection de l’option inter-locataires.

Mettre à jour mailUsers local

Une fois que la boîte aux lettres passe de la source à la cible, vous devez vous assurer que les utilisateurs de messagerie locaux, à la fois dans la source et la cible, sont mis à jour avec la nouvelle adresse targetAddress. Dans les exemples, le targetDeliveryDomain utilisé dans le déplacement est northwindtraders.onmicrosoft.com. Mettez à jour les utilisateurs de messagerie avec cette adresse cible.

Supprimer les points de terminaison et les relations organization après la migration

Utilisez l’applet de commande Remove-MigrationEndpoint pour supprimer les points de terminaison de migration existants pour les serveurs source ou de destination une fois la migration terminée.

Utilisez l’applet de commande Remove-OrganizationRelationship pour supprimer les relations organization existantes pour les serveurs source ou de destination une fois la migration terminée.

Foire aux questions

Dois-je mettre à jour remoteMailboxes dans le locataire local source après le déplacement ?

Organisation Exchange source

Vous devez mettre à jour targetAddress (RemoteRoutingAddress/ExternalEmailAddress) de chaque utilisateur local source lorsque la boîte aux lettres du locataire source se déplace vers le locataire cible. Bien que le routage du courrier puisse suivre les références entre plusieurs utilisateurs de messagerie avec des adresses cibles différentes, les recherches de disponibilité pour les utilisateurs de messagerie doivent cibler l’emplacement de l’utilisateur de boîte aux lettres.

Organisation Exchange cible

Une fois la migration terminée dans un organization hybride, exécutez la commande PowerShell suivante si vous souhaitez que vos utilisateurs disposent de boîtes aux lettres distantes locales :

Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox

Les réunions Teams migrent-elles entre locataires ?

Pendant que les réunions Teams sont déplacées, l’URL de la réunion n’est pas mise à jour lorsque les éléments migrent entre locataires. Étant donné que l’URL n’est pas valide dans le locataire cible, vous devez supprimer et recréer les réunions Teams.

Quel contenu est migré entre locataires ?

Lorsqu’une boîte aux lettres est migrée entre locataires avec cette fonctionnalité, seul le contenu visible par l’utilisateur dans la boîte aux lettres, également appelé Top of Information Store (e-mail, contacts, calendrier, tâches et notes), et les dossiers Éléments récupérables Suppressions, Versions et Purges sont migrés.

Les éléments de la boîte d’envoi sont-ils migrés entre locataires ?

Les éléments de la boîte d’envoi ne sont pas migrés entre locataires, car ce dossier est un dossier client spécifique au client Outlook. Les éléments de la boîte d’envoi sont stockés localement et ne sont pas synchronisés avec le cloud.

Le contenu du dossier de conversation Teams migre-t-il entre locataires ?

Non, le contenu du dossier de conversation Teams ne migre pas entre locataires. Toutefois, une fois que la boîte aux lettres a été migrée entre locataires, le contenu du dossier de conversation Teams est disponible pour que l’administrateur du locataire source puisse effectuer une recherche et une exportation à l’aide d’une recherche de contenu.

Comment puis-je voir uniquement les mouvements qui sont des déplacements interlocataires, et non mes déplacements d’intégration et de désinsaisonnement ?

Utilisez le paramètre Flags :

Get-MoveRequest -Flags "CrossTenant"

Pouvez-vous fournir des exemples de scripts pour copier les attributs utilisés dans le cadre du test ?

Remarque

EXEMPLE : TEL QUEL, AUCUNE GARANTIE Ce script suppose une connexion à la boîte aux lettres source (pour obtenir les valeurs sources) et à la Active Directory local Domain Services cible (pour marquer l’objet ADUser).

# 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

Comment accéder à Outlook le jour 1 après le déplacement de la boîte aux lettres de l’utilisateur ?

Étant donné qu’un seul locataire peut posséder un domaine, l’ancienne adresse SMTPAddress principale n’est pas associée à l’utilisateur dans le locataire cible une fois le déplacement de la boîte aux lettres terminé ; uniquement les domaines associés au nouveau locataire. Outlook utilise le nouvel UPN de l’utilisateur pour s’authentifier auprès du service, et le profil Outlook s’attend à trouver l’adresse SMTP principale héritée correspondant à la boîte aux lettres dans le système cible. Étant donné que l’adresse héritée n’est pas dans le système cible, le profil Outlook ne se connecte pas pour rechercher la boîte aux lettres nouvellement déplacée.

Pour ce déploiement initial, les utilisateurs doivent reconstruire leur profil avec leur nouvel UPN, leur nouvelle adresse SMTP principale et le contenu OST resynchroniser.

Remarque

Planifiez en conséquence au fur et à mesure que vous effectuez le traitement par lot de vos utilisateurs. Vous devez tenir compte de l’utilisation et de la capacité du réseau lorsque des profils client Outlook sont créés et que les fichiers OST et OAB suivants sont téléchargés sur les clients.

De quels rôles Exchange RBAC dois-je être membre pour configurer ou effectuer un déplacement interlocataire ?

Il existe une matrice de rôles basée sur l’hypothèse de tâches déléguées lors de l’exécution d’un déplacement de boîte aux lettres. Actuellement, deux rôles sont requis :

Le premier rôle est pour une tâche de configuration unique qui établit l’autorisation de déplacer du contenu vers ou hors de la limite de votre locataire/organisation. Étant donné que le déplacement des données hors du contrôle de votre organisation est une préoccupation essentielle pour toutes les entreprises, nous avons opté pour le rôle d’administrateur d’organisation le plus élevé. Ce rôle doit modifier ou configurer un nouveau OrganizationRelationship qui définit le -MailboxMoveCapability paramètre avec le organization distant. Seul l’administrateur organization peut modifier le -MailboxMoveCapability paramètre, tandis que les autres attributs de l’OrganizationRelationship peuvent être gérés par l’administrateur du partage fédéré.
Le rôle d’exécution des commandes de déplacement réelles peut être délégué à une fonction de niveau inférieur. Le rôle Déplacer des boîtes aux lettres est attribué à la possibilité de déplacer des boîtes aux lettres dans ou hors du organization.

Comment cibler l’adresse SMTP sélectionnée pour targetAddress (TargetDeliveryDomain) sur la boîte aux lettres convertie (en conversion MailUser) ?

La boîte aux lettres Exchange se déplace à l’aide de MRS pour créer la targetAddress sur la boîte aux lettres source d’origine lors de la conversion en mailUser en mettant en correspondance une adresse e-mail (proxyAddress) sur l’objet cible. Le processus prend la -TargetDeliveryDomain valeur passée dans la commande, puis recherche un proxy correspondant pour ce domaine côté cible. Lorsque nous trouvons une correspondance, la proxyAddress correspondante est utilisée pour définir externalEmailAddress (targetAddress) sur l’objet de boîte aux lettres convertie (maintenant MailUser).

Comment fonctionne le flux de messagerie après la migration ?

Le flux de messagerie interlocataire après la migration fonctionne de la même façon que le flux de messagerie hybride Exchange. Chaque boîte aux lettres migrée a besoin de la source MailUser avec l’adresse cible correcte pour transférer le courrier entrant du locataire source vers les boîtes aux lettres dans le locataire cible. Les règles de transport, les fonctionnalités de sécurité et de conformité s’exécutent comme configuré dans chaque locataire par lequel le courrier transite. Par conséquent, pour les messages entrants, les fonctionnalités telles que l’anti-courrier indésirable, le logiciel anti-programme malveillant, la mise en quarantaine, les règles de transport et les règles de journalisation s’exécutent d’abord dans le locataire source, puis dans le locataire cible.

Comment les autorisations de boîte aux lettres sont-ils transférées ?

Les autorisations de boîte aux lettres incluent Envoyer au nom de et Accès aux boîtes aux lettres :

Send On Behalf Of (AD :publicDelegates) stocke le DN des destinataires ayant accès à la boîte aux lettres d’un utilisateur en tant que délégué. Cette valeur est stockée dans Active Directory et ne se déplace pas actuellement dans le cadre de la transition de boîte aux lettres. Si publicDelegates est défini sur la boîte aux lettres source, vous devez les restaurer sur la boîte aux lettres cible une fois la conversion meU en boîte aux lettres terminée dans l’environnement cible en exécutant Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
Les autorisations de boîte aux lettres stockées dans la boîte aux lettres sont déplacées avec la boîte aux lettres lorsque le principal et le délégué sont déplacés vers le système cible. Par exemple, l’utilisateur TestUser7 bénéficie de FullAccess à la boîte aux lettres TestUser_8 dans le locataire SourceCompany.onmicrosoft.com. Une fois la boîte aux lettres déplacée vers TargetCompany.onmicrosoft.com, les mêmes autorisations sont configurées dans le répertoire cible. Des exemples utilisant _Get-MailboxPermission pour TestUser_7 dans les locataires source et cible sont présentés ci-dessous. Les applets de commande Exchange sont préfixées par source et cible en conséquence.

Voici un exemple de sortie de l’autorisation de boîte aux lettres avant un déplacement du côté source :

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

Voici un exemple de sortie de l’autorisation de boîte aux lettres après le déplacement du côté cible :

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

Remarque

Les autorisations de calendrier et de boîte aux lettres interlocataires ne sont pas prises en charge. Vous devez organiser les principaux et les délégués en lots de déplacement consolidés afin que ces boîtes aux lettres connectées soient transférées en même temps à partir du locataire source.

Quel proxy X500 doit être ajouté aux adresses proxy MailUser cibles pour permettre la migration ?

La migration de boîtes aux lettres inter-locataires nécessite que la valeur LegacyExchangeDN de l’objet de boîte aux lettres source soit estampillée en tant qu’adresse e-mail x500 sur l’objet MailUser cible.

Exemple :

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

Remarque

En plus de ce proxy X500, vous devez copier tous les proxys X500 de la boîte aux lettres de la source vers la boîte aux lettres de la cible. Bien que rare, vous pouvez également exécuter sur une adresse proxy X400 sur une boîte aux lettres, bien que le déplacement ne soit pas obligatoire, il est recommandé de marquer cette adresse sur l’objet utilisateur de messagerie cible.

Les locataires source et cible peuvent-ils utiliser le même nom de domaine ?

Non, les noms de domaine du locataire source et du locataire cible doivent être uniques, par exemple, un domaine source de contoso.com et le domaine cible de northwindtraders.com.

Les boîtes aux lettres partagées seront-elles déplacées et fonctionneront-elles toujours ?

Oui. Toutefois, nous conservons uniquement les autorisations de magasin comme décrit dans cet article :

Gérer les autorisations des destinataires dans Exchange Online

Avez-vous des recommandations pour les lots ?

Ne dépassez pas 2 000 boîtes aux lettres par lot. Nous vous recommandons vivement d’envoyer des lots deux semaines avant la date de basculement, car il n’y a aucun impact sur les utilisateurs finaux pendant la synchronisation. Si vous avez besoin d’aide pour les quantités de boîtes aux lettres supérieures à 50 000, vous pouvez contacter votre CSAM ou ouvrir une demande de support.

Que se passe-t-il si j’utilise le chiffrement de service avec la clé client Microsoft Purview ?

La boîte aux lettres est déchiffrée avant le déplacement. Vérifiez que la clé client est configurée dans le locataire cible si elle est toujours nécessaire. Pour plus d’informations, consultez ici.

Quelle est la durée estimée de la migration ?

Pour vous aider à planifier votre migration, le tableau présenté ici présente les instructions sur la fin des migrations de boîtes aux lettres en bloc ou des migrations individuelles. Ces estimations sont basées sur une analyse des données des migrations de clients précédentes. Comme chaque environnement est unique, votre vitesse de migration exacte peut varier.

Protection des documents dans le locataire source consommable par les utilisateurs du locataire de destination.**

La migration interlocataire ne migre que les données de boîte aux lettres et rien d’autre. Il existe plusieurs autres options, documentées dans le billet de blog suivant, qui peuvent vous aider :

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

Puis-je avoir les mêmes étiquettes dans le locataire de destination que dans le locataire source, soit comme seul ensemble d’étiquettes, soit comme un ensemble supplémentaire d’étiquettes pour les utilisateurs migrés en fonction de l’alignement entre les organisations.**

Étant donné que les migrations interlocataires n’exportent pas d’étiquettes et qu’il n’existe aucun moyen de partager des étiquettes entre locataires, vous ne pouvez atteindre cet objectif qu’en recréant les étiquettes dans le locataire de destination.

Prenez-vous en charge le déplacement de Groupes Microsoft 365 ?

Actuellement, la fonctionnalité de migration de boîtes aux lettres entre locataires ne prend pas en charge la migration de Groupes Microsoft 365.

Un administrateur de locataire source peut-il effectuer une recherche eDiscovery sur une boîte aux lettres une fois que la boîte aux lettres a été migrée vers le locataire nouveau/cible ?

Non, après une migration de boîte aux lettres interlocataire, eDiscovery sur la boîte aux lettres de l’utilisateur migré dans la source ne fonctionne pas. Cet échec eDiscovery est dû au fait qu’il n’y a plus de boîte aux lettres dans la source à rechercher, car la boîte aux lettres a été migrée vers le locataire cible et appartient désormais au locataire cible. EDiscovery après la migration de boîte aux lettres ne peut être effectuée que dans le locataire cible (où la boîte aux lettres existe maintenant). Si une copie de la boîte aux lettres source doit persister dans le locataire source après la migration, l’administrateur du locataire source peut copier le contenu dans une autre boîte aux lettres avant la migration pour les futures opérations eDiscovery sur les données.

À quel moment le MailUser de destination sera-t-il converti en boîte aux lettres de destination et la boîte aux lettres source convertie en mailUser source ?

Ces conversions se produisent automatiquement pendant le processus de migration. Aucune étape manuelle n’est nécessaire.

À quelle étape dois-je attribuer la licence Exchange Online à MailUsers de destination ?

Cette attribution de licence peut être effectuée avant la fin de la migration, mais vous ne devez pas attribuer une licence avant d’horodater l’attribut ExchangeGUID ; Sinon, la conversion de l’objet MailUser en boîte aux lettres échoue et une nouvelle boîte aux lettres est créée à la place. Pour atténuer ce risque, il est préférable d’attendre que la migration soit terminée et d’attribuer des licences pendant la période de grâce de 30 jours.

Puis-je utiliser Microsoft Entra Connect pour synchroniser les utilisateurs avec le nouveau locataire si je conserve le Active Directory local ?

Oui. Il est possible que deux instances de Microsoft Entra Connect se synchronisent avec différents locataires. Toutefois, il existe certaines choses que vous devez connaître :

Le préprovisionnement des comptes d’utilisateur avec le script fourni dans cet article ne doit pas être effectué. Au lieu de cela, une synchronisation sélective de l’unité d’organisation des utilisateurs dans l’étendue de la migration peut être effectuée pour remplir le locataire cible. Vous recevrez un avertissement indiquant que l’UPN ne correspond pas pendant la configuration Microsoft Entra Connect.
Selon l’état actuel d’Exchange hybride, vous devez vérifier que les objets d’annuaire local ont les attributs requis (tels que msExchMailboxGUID et proxyAddresses) correctement renseignés avant de tenter de se synchroniser avec un autre locataire . Sinon, vous rencontrerez des problèmes avec les boîtes aux lettres doubles et les échecs de migration.
Vous devez prendre des mesures supplémentaires pour gérer la transition UPN, en le modifiant localement une fois la migration terminée pour un utilisateur, sauf si vous déplacez également le domaine personnalisé pendant une migration à basculement.

Comment dois-je gérer les boîtes aux lettres qui sont proches du quota ou qui dépassent le quota ?

Les boîtes aux lettres qui approchent leur quota avant la migration peuvent se retrouver au-dessus du quota avant ou pendant la migration réelle. Si cela se produit, la migration de ces boîtes aux lettres échoue et doit être corrigée et redémarrée. Pour atténuer ce problème, il est recommandé à l’administrateur du locataire source d’identifier les boîtes aux lettres au quota ou à proximité avant la migration et de prendre les mesures nécessaires pour réduire la taille de la boîte aux lettres, approvisionner une archive principale ou, dans certains cas, activer le développement automatique des archives pour les boîtes aux lettres de l’utilisateur.

Remarque

Après avoir activé une archive ou une archive à développement automatique pour un utilisateur, vérifiez que les stratégies d’archivage appropriées sont appliquées à l’utilisateur et que le processus est exécuté pour déplacer les données de boîte aux lettres vers son nouvel emplacement et libérer de l’espace.

Les boîtes aux lettres d’archivage développées automatiquement sont-ils déplacées ?

Problème : Les archives développées automatiquement ne peuvent pas être migrées. Oui, si l’utilisateur de la source a activé l’extension automatique des archives et dispose d’archives auxiliaires supplémentaires, la migration de boîtes aux lettres entre locataires fonctionne. Nous prenons en charge le déplacement des utilisateurs qui n’ont pas plus de 12 boîtes aux lettres d’archivage auxiliaires. En outre, les utilisateurs disposant d’une grande archive principale, d’une grande main et de grandes boîtes aux lettres d’archivage auxiliaires ont besoin de temps supplémentaire pour se synchroniser et doivent être envoyés bien avant la date de basculement. Si la boîte aux lettres source est développée pendant le processus de migration de boîte aux lettres, la migration échoue car une nouvelle archive auxiliaire est créée dans la source, mais pas dans la cible. Dans ce cas, vous devez supprimer l’utilisateur du lot et le soumettre à nouveau.

Puis-je effectuer une migration de locataire à locataire entre cloud ?

La migration entre locataires cloud n’est pas prise en charge. Un exemple de scénario serait le passage de Office 365 Worldwide à Office 365 Secteur Public Cloud.

Les messages vocaux sont-ils migrés entre locataires ?

Oui, les messages vocaux sont migrés entre locataires.

Les messages vocaux reçus dans les e-mails sous forme de pièces jointes sont disponibles dans la boîte aux lettres cible.
Les messages vocaux reçus sont disponibles dans Teams si vous appelez la messagerie vocale et écoutez les messages enregistrés. (Les machines virtuelles reçues dans la source sont disponibles en tant que messages enregistrés)
Les messages vocaux reçus ne sont pas disponibles dans l’interface utilisateur du client Teams après la migration cible.
Le message d’accueil de la messagerie vocale est également migré vers la cible.

Les signatures de boîte aux lettres sont-elles migrées entre locataires ?

Les signatures de boîte aux lettres ne sont pas migrées entre locataires et doivent être recréées.

Problèmes connus

Les fonctionnalités Teams postérieures à la migration dans le locataire source seront limitées. Une fois la boîte aux lettres migrée vers le locataire cible, Teams dans le locataire source n’a plus accès à la boîte aux lettres de l’utilisateur. Si un utilisateur se connecte à Teams avec les informations d’identification du locataire source, il y a une perte de fonctionnalités, comme l’impossibilité de mettre à jour son image de profil, l’absence d’application de calendrier et l’impossibilité de rechercher et de rejoindre des équipes publiques.
Cloud MailUsers avec proxyAddress smtp non détenu bloquent les déplacements MRS. Lorsque vous créez des objets MailUser de locataire cible, vous devez vous assurer que toutes les adresses proxy SMTP appartiennent au locataire cible organization. S’il existe un proxyAddress SMTP sur l’utilisateur de messagerie cible qui n’appartient pas au locataire local, la conversion de MailUser en boîte aux lettres est empêchée. Cette prévention est due à notre assurance que les objets de boîte aux lettres peuvent uniquement envoyer des messages à partir de domaines pour lesquels le locataire fait autorité (domaines revendiqués par le locataire).
Si vous synchronisez des utilisateurs locaux à l’aide de Microsoft Entra Connect dans le locataire cible, vous pouvez provisionner des objets MailUser locaux avec ExternalEmailAddress pointant vers le locataire source où se trouve la boîte aux lettres (LaraN@contoso.onmicrosoft.com) et vous marquez l’adresse PrimarySMTPAddress en tant que domaine qui réside dans le locataire cible (Lara.Newton@northwindtraders.com). Ces valeurs sont synchronisées avec le locataire et un utilisateur de messagerie approprié est approvisionné et prêt pour la migration. Un exemple d’objet est présenté ici.
```
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

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

L’adresse contoso.onmicrosoft.comn’est pas présente dans le tableau EmailAddresses/proxyAddresses.
Les objets MailUser avec des adresses SMTP principales « externes » sont modifiés/réinitialisés en domaines « internes » revendiqués par l’entreprise.

Les objets MailUser sont des pointeurs vers des boîtes aux lettres non locales. Dans le cas de migrations de boîtes aux lettres interlocataires, nous utilisons des objets MailUser pour représenter la boîte aux lettres source (du point de vue de l’organization cible) ou la boîte aux lettres cible (du point de vue de l’organization source). Les MailUsers auront un ExternalEmailAddress (targetAddress) qui pointe vers l’adresse smtp de la boîte aux lettres réelle (ProxyTest@northwindtraders.onmicrosoft.com) et l’adresse primarySMTP qui représente l’adresse SMTP affichée de l’utilisateur de la boîte aux lettres dans le répertoire. Certaines organisations choisissent d’afficher l’adresse SMTP principale en tant qu’adresse SMTP externe, et non en tant qu’adresse détenue/vérifiée par le locataire local (par exemple, comme northwindtraders.com plutôt que comme contoso.com). Toutefois, une fois qu’un objet de plan de service Exchange est appliqué à MailUser via des opérations de licence, l’adresse SMTP principale est modifiée pour s’afficher en tant que domaine vérifié par le organization local (contoso.com). Il existe deux raisons possibles :
Lorsqu’un plan de service Exchange est appliqué à un mailUser, le processus Microsoft Entra ID commence à appliquer le nettoyage du proxy pour s’assurer que le organization local n’est pas en mesure d’envoyer du courrier, de l’usurpation ou du courrier à partir d’un autre locataire. Toute adresse SMTP sur un objet destinataire avec ces plans de service est supprimée si l’adresse n’est pas vérifiée par le organization local. Comme c’est le cas dans l’exemple, le domaine northwindtraders.com n’est pas vérifié par le locataire contoso.onmicrosoft.com ; par conséquent, le nettoyage supprime ce domaine northwindtraders.com. Si vous souhaitez conserver ces domaines externes sur MailUser, avant ou après la migration, vous devez modifier vos processus de migration pour supprimer les licences une fois le déplacement terminé ou avant le déplacement pour vous assurer que la personnalisation externe attendue est appliquée aux utilisateurs. Vous devez vous assurer que l’objet de boîte aux lettres dispose d’une licence appropriée pour ne pas affecter le service de messagerie. Un exemple de script pour supprimer les plans de service sur un MailUser dans le locataire contoso.onmicrosoft.com est présenté ici.

Remarque

Le script suivant utilise Microsoft Graph PowerShell. Pour plus d’informations, consultez Vue d’ensemble de Microsoft Graph PowerShell.

Pour plus d’informations sur l’utilisation de différentes méthodes pour l’authentification Connect-Graph dans un script sans assistance, consultez l’article Applets de commande du module d’authentification dans 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

Les résultats de l’ensemble de ServicePlans attribués sont présentés ici :

$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

L’adresse PrimarySMTPAddress de l’utilisateur n’est plus nettoyée. Le domaine northwindtraders.com n’appartient pas au locataire contoso.onmicrosoft.com et est conservé en tant qu’adresse SMTP principale indiquée dans l’annuaire.

Voici un exemple :

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

Lorsque msExchRemoteRecipientType est défini sur 8 (DeprovisionMailbox), pour les MailUsers locaux migrés vers le locataire cible, la logique de nettoyage du proxy dans Azure supprime les domaines non détenus et réinitialise le primarySMTP à un domaine détenu. Une fois le msExchRemoteRecipientType dans l’objet MailUser local effacé, la logique de nettoyage du proxy ne s’applique plus.

Voici l’ensemble complet des plans de service actuels qui incluent Exchange Online :

Nom
Stockage eDiscovery (Premium) (500 Go)
Référentiel sécurisé client
Protection contre la perte de données
Services CAL Exchange Enterprise (EOP, DLP)
Essentials Exchange
Exchange Foundation
Exchange Online (P1)
Exchange Online (plan 1)
Exchange Online (plan 2)
Archivage Exchange Online pour Exchange Online
Archivage Exchange Online pour Exchange Server
module complémentaire utilisateur inactif Exchange Online
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online (plan 1)
Exchange Online POP
Exchange Online Protection
Recherche de connecteurs Graph avec index
Obstacles aux informations
Protection des informations pour Office 365 – Premium
Protection des informations pour Office 365 – Standard
Insights par MyAnalytics
Gouvernance des informations Microsoft
Audit de Microsoft Purview (Premium)
Microsoft Bookings
Centre d’affaires Microsoft
Enquêtes sur les données Microsoft
Microsoft MyAnalytics (complet)
Conformité des communications Microsoft
Microsoft Communications DLP
Clé client Microsoft
Microsoft 365 Advanced Auditing
Gestion des enregistrements Microsoft
Office 365 eDiscovery (Premium)
Office 365 Advanced eDiscovery
Microsoft Defender for Office 365 (Plan 1)
Microsoft Defender pour Office 365 (Plan 2)
Office 365 Privileged Access Management
Chiffrement Premium dans Office 365

Échecs de migration

MailboxNotInCrossTenantMigrationScopeException

Vérifiez que l’étendue de la migration est correctement configurée sur le locataire source et que MailboxMovesPublishedScopes est défini dans la relation organization avec le locataire cible.
Vérifiez que la boîte aux lettres à migrer a été ajoutée au groupe de sécurité dans le locataire source.
Après avoir ajouté l’utilisateur au groupe de sécurité correct, reprenez le lot de migration.
AuxArchiveNotFoundInTargetRecipientException

Cet échec est dû au fait que l’utilisateur n’était pas dans l’étendue de migration au démarrage du lot et que l’utilisateur a AuxArchive sur la source.
Ajoutez un utilisateur au groupe de sécurité approprié sur la cible source.
Supprimez l’utilisateur de migration du lot.
Supprimez des utilisateurs avec la commande suivante :
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Ajouter un utilisateur au nouveau lot.
MailboxIsNotInExpectedDBException

Cet échec est dû à la maintenance interne de Microsoft.
Supprimez l’utilisateur de migration du lot.
Supprimez des utilisateurs avec la commande suivante :
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Ajouter un utilisateur au nouveau lot.
NotAcceptedDomainException

Une adresse proxy non valide estampillée sur l’utilisateur cible. Par exemple, un utilisateur dans contoso.onmicrosoft.com avait une adresse proxy de fabrikam.onmicrosoft.com, qui est le locataire source.
Supprimez l’adresse proxy non valide à l’aide de la commande suivante :
```
Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
```
Reprenez le lot de migration.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

Un nouvel AuxArchive a été provisionné pendant la migration.
Supprimez l’utilisateur de migration du lot.
Supprimez des utilisateurs avec la commande suivante :
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser 
```
Ajouter un utilisateur au nouveau lot.
UserDuplicateInOtherBatchException

L’utilisateur existe déjà dans un autre lot.
Supprimez l’utilisateur de migration du lot.
Supprimez des utilisateurs avec la commande suivante :
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Ajouter un utilisateur au nouveau lot.
MissingExchangeGuidException

Il manque à l’objet mailuser cible la valeur ExchangeGuid correcte.
Mettez à jour ExchangeGuid avec la commande suivante :
```
Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8  
```
Reprendre le lot de migration.
SourceMailboxAlreadyBeingMovedPermanentException

La boîte aux lettres source a déjà une demande de déplacement existante. Examinez et supprimez le déplacement existant. Il est possible qu’il s’agit d’un déplacement interne de Microsoft et que vous deviez attendre la fin du déplacement.
Supprimez l’utilisateur de migration du lot.
Supprimez des utilisateurs avec la commande suivante :
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Ajoutez un utilisateur au nouveau lot une fois le déplacement d’origine supprimé ou terminé.
UserAlreadyHasDemotedArchiveException

L’utilisateur avait précédemment une boîte aux lettres d’archivage qui était désactivée. Choisissez l’une des deux options suivantes pour résoudre ce problème.
Supprimez définitivement la boîte aux lettres d’archivage désactivée, ce qui n’est pas modifiable. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Réactivez la boîte aux lettres d’archivage désactivée avec la commande suivante :
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
Si vous réactivez la boîte aux lettres d’archivage désactivée, vous devez mettre à jour le GUID d’archive sur l’objet mailuser cible.
Reprendre le lot de migration.

Voir aussi

Gestion de Microsoft 365 à l’aide de PowerShell
Mise en place du SDK Microsoft Graph PowerShell
[https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]

Partager via

Migration de boîtes aux lettres inter-clients

Licences

Préparation des locataires source et cible

Conditions préalables pour les locataires source et cible

Étapes de configuration pour activer vos locataires pour les migrations de boîtes aux lettres interlocataires

Préparer le client cible (destination) en créant l’application de migration et le secret

Accorder le consentement à l’application

Préparez le client cible en créant le point de terminaison de la migration vers Exchange Online et la relation avec l'organisation.

Préparez le locataire source (emplacement actuel de la boîte aux lettres) en acceptant l’application de migration et en configurant la relation organization

Préparer les objets utilisateur cibles pour la migration

Prérequis pour les objets utilisateur cibles

Comment savoir si cela a fonctionné ?

Déplacer les boîtes aux lettres vers la source d’origine

Effectuer des migrations de boîtes aux lettres

Créer des lots de migration

Mettre à jour mailUsers local

Supprimer les points de terminaison et les relations organization après la migration

Foire aux questions

Dois-je mettre à jour remoteMailboxes dans le locataire local source après le déplacement ?

Organisation Exchange source

Organisation Exchange cible

Les réunions Teams migrent-elles entre locataires ?

Quel contenu est migré entre locataires ?

Les éléments de la boîte d’envoi sont-ils migrés entre locataires ?

Le contenu du dossier de conversation Teams migre-t-il entre locataires ?

Comment puis-je voir uniquement les mouvements qui sont des déplacements interlocataires, et non mes déplacements d’intégration et de désinsaisonnement ?

Pouvez-vous fournir des exemples de scripts pour copier les attributs utilisés dans le cadre du test ?

Comment accéder à Outlook le jour 1 après le déplacement de la boîte aux lettres de l’utilisateur ?

De quels rôles Exchange RBAC dois-je être membre pour configurer ou effectuer un déplacement interlocataire ?

Comment cibler l’adresse SMTP sélectionnée pour targetAddress (TargetDeliveryDomain) sur la boîte aux lettres convertie (en conversion MailUser) ?

Comment fonctionne le flux de messagerie après la migration ?

Comment les autorisations de boîte aux lettres sont-ils transférées ?

Quel proxy X500 doit être ajouté aux adresses proxy MailUser cibles pour permettre la migration ?

Les locataires source et cible peuvent-ils utiliser le même nom de domaine ?

Les boîtes aux lettres partagées seront-elles déplacées et fonctionneront-elles toujours ?

Avez-vous des recommandations pour les lots ?

Que se passe-t-il si j’utilise le chiffrement de service avec la clé client Microsoft Purview ?

Quelle est la durée estimée de la migration ?

Protection des documents dans le locataire source consommable par les utilisateurs du locataire de destination.**

Puis-je avoir les mêmes étiquettes dans le locataire de destination que dans le locataire source, soit comme seul ensemble d’étiquettes, soit comme un ensemble supplémentaire d’étiquettes pour les utilisateurs migrés en fonction de l’alignement entre les organisations.**

Prenez-vous en charge le déplacement de Groupes Microsoft 365 ?

Un administrateur de locataire source peut-il effectuer une recherche eDiscovery sur une boîte aux lettres une fois que la boîte aux lettres a été migrée vers le locataire nouveau/cible ?

À quel moment le MailUser de destination sera-t-il converti en boîte aux lettres de destination et la boîte aux lettres source convertie en mailUser source ?

À quelle étape dois-je attribuer la licence Exchange Online à MailUsers de destination ?

Puis-je utiliser Microsoft Entra Connect pour synchroniser les utilisateurs avec le nouveau locataire si je conserve le Active Directory local ?

Comment dois-je gérer les boîtes aux lettres qui sont proches du quota ou qui dépassent le quota ?

Les boîtes aux lettres d’archivage développées automatiquement sont-ils déplacées ?

Puis-je effectuer une migration de locataire à locataire entre cloud ?

Les messages vocaux sont-ils migrés entre locataires ?

Les signatures de boîte aux lettres sont-elles migrées entre locataires ?

Problèmes connus

Échecs de migration

Voir aussi

Commentaires

Ressources supplémentaires