Les migrations tenant-to-tenant s’imposent dans de nombreux scénarios : fusions-acquisitions, restructurations d’entités, ou regroupements de filiales sous un annuaire Microsoft 365 commun. Dans ce contexte, la préparation du tenant cible Microsoft 365 constitue le socle sur lequel repose l’ensemble du projet. La relation d’organisation interlocataire joue un rôle central : elle établit la confiance entre les environnements Exchange Online, conditionne la lisibilité des disponibilités calendaires et encadre les flux d’authentification via Microsoft Entra ID et les Cross-tenant access settings. Bien paramétrée, elle garantit la conformité des échanges, réduit les risques opérationnels et accélère sensiblement la phase de bascule. Cet article détaille les prérequis, les étapes de configuration et les bonnes pratiques à adopter pour sécuriser cette brique essentielle.
À retenir :
- Configurer une relation d’organisation cross-tenant est crucial pour migrer des boîtes aux lettres entre deux tenants Microsoft 365
- Les migrations se font souvent lors de fusions, restructurations ou regroupements d’entités sous un annuaire commun
- La confiance établie entre tenants assure la conformité des échanges et facilite la gestion des flux d’authentification
- Des paramètres PowerShell comme MailboxMoveEnabled et MailboxMoveCapability sont essentiels pour configurer les migrations
- La validation des conditions techniques et la configuration sécurisée des accès sont primordiales avant de commencer toute migration
Eliadis propose un partenariat pour garantir une migration sécurisée et conforme grâce à son expertise technique
Comprendre les fondements d’une relation d’organisation cross-tenant Exchange Online
Une relation d’organisation cross-tenant est le mécanisme central qui permet de lier deux locataires Microsoft 365 afin d’autoriser le déplacement de boîtes aux lettres Exchange Online de l’un vers l’autre. Elle constitue la première étape obligatoire de toute migration inter-tenant structurée.
Définition et applications dans Exchange Online
Dans le contexte d’Exchange Online, une relation d’organisation cross-tenant définit un accord de confiance technique entre deux tenants distincts. Elle indique au service Exchange que les administrateurs des deux environnements ont consenti à des opérations communes, notamment la cross-tenant mailbox migration. Selon Microsoft, cette relation permet aux administrateurs d’utiliser PowerShell et le service MRS (Mailbox Replication Service) pour migrer des boîtes aux lettres entre tenants (Source : Microsoft — 2025-09-28). En pratique, elle s’applique aussi bien aux fusions d’entreprises, aux scissions organisationnelles qu’aux consolidations de domaines dans le cadre d’une organisation multi-tenant Microsoft 365.
Pour comprendre comment l’application de migration est préalablement configurée dans Microsoft Entra ID, vous pouvez consulter notre guide sur la création d’application de migration Microsoft Entra ID tenant to tenant.
Composants structurants : MailboxMoveEnabled et MailboxMoveCapability
La relation d’organisation repose sur deux paramètres PowerShell déterminants dans la cross-tenant mailbox move configuration :
| Paramètre | Valeur possible | Rôle |
|---|---|---|
| MailboxMoveEnabled | $true / $false | Active ou désactive la possibilité de déplacer des boîtes aux lettres via cette relation |
| MailboxMoveCapability | Inbound / Outbound / RemoteInbound / RemoteOutbound | Définit le sens du flux de migration autorisé (entrant ou sortant) selon la perspective du tenant concerné |
Ces deux paramètres se configurent via la commande Set-OrganizationRelationship dans Exchange Online PowerShell. Leur combinaison détermine précisément quels tenants peuvent initier ou recevoir une migration. Une mauvaise configuration de MailboxMoveCapability est l’une des causes les plus fréquentes de blocages lors d’un paramétrage des relations entre locataires Microsoft 365.
Lien avec la stratégie de confiance entre tenants
La relation d’organisation ne fonctionne pas isolément : elle s’appuie sur une relation de confiance tenant à tenant établie au niveau de Microsoft Entra ID. Cette confiance est matérialisée par une application de migration enregistrée dans chaque tenant, associée à des droits délégués spécifiques sur Exchange Online. La documentation Microsoft sur la migration multi-tenant détaille les prérequis d’identité nécessaires. Sans cette couche d’authentification mutuelle, la relation d’organisation reste inopérante, quelle que soit la précision de sa configuration PowerShell.
La maîtrise de ces fondements est indispensable avant d’aborder la procédure concrète de création et de configuration de la relation d’organisation dans les deux tenants impliqués.
Mettre en place la relation d’organisation côté tenant source et cible
La configuration d’une relation d’organisation cross-tenant repose sur une symétrie précise : le tenant cible déclare une capacité Inbound, tandis que le tenant source déclare une capacité RemoteOutbound. Ces deux déclarations s’articulent pour former un canal d’approbation bidirectionnel, condition nécessaire au déplacement de boîtes aux lettres entre tenants Exchange Online.
Configurer le tenant cible : MailboxMoveEnabled et MailboxMoveCapability Inbound
Sur le tenant cible, la relation d’organisation s’établit en PowerShell via les cmdlets New-OrganizationRelationship ou Set-OrganizationRelationship. Le paramètre MailboxMoveEnabled doit être positionné à $true pour autoriser le déplacement de boîtes aux lettres. Le paramètre MailboxMoveCapability prend la valeur Inbound, signifiant que ce tenant est autorisé à recevoir des migrations en provenance du tenant source. Selon la documentation Microsoft, cette configuration s’applique via la commande Set-MailboxOrganizationRelationship -MailboxMoveEnabled $true -MailboxMoveCapability Inbound (Source : Microsoft — 2025-09-28). Il convient également de renseigner le domaine cible dans le champ DomainNames afin que la relation d’approbation entre tenants soit correctement scoped.
Configurer le tenant source : RemoteOutbound et OAuthApplicationId
Du côté du tenant source, la relation d’organisation se déclare avec MailboxMoveCapability positionnée sur RemoteOutbound. Cette valeur indique que le tenant initie le déplacement vers l’extérieur. Le paramètre OAuthApplicationId joue ici un rôle central : il référence l’identifiant de l’application Microsoft Entra ID créée préalablement sur le tenant cible, celle-là même qui sert de socle d’authentification pour l’ensemble du processus. Pour bien comprendre comment créer cette application dans Entra ID, la ressource création d’application de migration Microsoft Entra ID tenant to tenant détaille les étapes à suivre. Sans cet identifiant correctement renseigné, la configuration des politiques d’accès cross-tenant reste incomplète et le déplacement ne peut pas s’authentifier.
Paramètres d’authentification et synchronisation de confiance entre tenants
Le tableau ci-dessous récapitule les paramètres clés à configurer pour chaque tenant dans le cadre du paramétrage des migrations de boîtes aux lettres entre tenants :
| Tenant | Paramètre | Valeur | Rôle |
|---|---|---|---|
| Cible | MailboxMoveEnabled | $true | Autorise la réception de migrations |
| Cible | MailboxMoveCapability | Inbound | Déclare la direction entrante |
| Source | MailboxMoveCapability | RemoteOutbound | Déclare la direction sortante |
| Source | OAuthApplicationId | GUID de l’app Entra ID | Authentification OAuth inter-tenant |
L’ensemble de ces paramètres peut également être vérifié via l’Exchange Online Admin Center, dans la section dédiée aux relations d’organisation, bien que la configuration initiale reste recommandée en PowerShell pour garantir la précision des valeurs. Les cross-tenant access settings pour Exchange Online doivent être cohérents des deux côtés avant de lancer la première migration. La section suivante aborde la vérification de la relation d’organisation et le lancement d’un déplacement de boîte aux lettres en test.
Définir les scopes, endpoints et politiques d’accès cross-tenant
La configuration des scopes et des endpoints constitue l’étape déterminante pour délimiter précisément quelles boîtes aux lettres seront migrées entre deux tenants Exchange Online. Sans ce cadrage, aucun déplacement de données ne peut être autorisé par la plateforme Microsoft.
Mise en place des MailboxMovePublishedScopes
Le paramètre MailboxMovePublishedScopes définit les objets inclus dans le périmètre de migration côté tenant source comme côté tenant cible. Selon la documentation officielle Microsoft, ce scope peut contenir jusqu’à 5 000 objets à migrer par scope défini. (Source : Microsoft — 2026-03-23). Il est donc essentiel de planifier la segmentation des migrations volumineuses en plusieurs scopes distincts afin de ne pas dépasser cette limite et d’éviter tout blocage lors de l’exécution des mouvements de boîtes.
Création d’un groupe mail-enabled pour le scope de migration
Pour définir le périmètre de migration, la bonne pratique consiste à créer un groupe mail-enabled dans Exchange Online, puis à l’associer au MailboxMovePublishedScopes. Ce groupe peut être un groupe de distribution ou un groupe de sécurité à extension messagerie. Les comptes utilisateurs à migrer sont ajoutés en tant que membres de ce groupe. Cette approche offre une gestion granulaire : il suffit d’ajouter ou de retirer des membres pour ajuster dynamiquement le scope sans reconfigurer l’ensemble de la relation d’organisation.
| Élément | Valeur recommandée | Rôle |
|---|---|---|
| Type de groupe | Mail-enabled Security Group | Définit les objets inclus dans le scope |
| Limite d’objets par scope | 5 000 maximum | Plafond imposé par Microsoft |
| Paramètre de scope | MailboxMovePublishedScopes | Référencement du groupe dans la relation d’organisation |
| RemoteServer | outlook.office.com | Endpoint cible de la migration cross-tenant |
Configuration du RemoteServer et des endpoints de migration
Pour les Migration Endpoints Exchange Online, le domaine outlook.office.com doit être renseigné comme valeur du paramètre RemoteServer lors de la création de l’endpoint. Ce point d’entrée standardisé garantit que le service de migration peut établir une connexion sécurisée entre les deux tenants. La configuration des scopes de migration Exchange Online s’articule donc autour de cet endpoint unique, indépendamment du nombre de boîtes à déplacer.
Configuration des politiques cross-tenant dans Microsoft Entra ID
En parallèle du paramétrage Exchange, les Cross-tenant access settings dans Microsoft Entra ID doivent être configurées pour autoriser explicitement les opérations de migration entre les deux organisations. La Cross-tenant access policy contrôle les flux d’authentification entre tenants : elle doit permettre l’accès entrant (inbound) côté tenant cible et l’accès sortant (outbound) côté tenant source. Sans cette configuration dans Entra ID, les tentatives de déplacement de boîtes seront rejetées, même si la relation d’organisation Exchange est correctement définie. Pour approfondir le paramétrage des migrations tenant to tenant dans leur globalité, la documentation Microsoft sur la migration cross-tenant multi-tenant détaille l’ensemble des prérequis et des étapes de configuration. Le chapitre suivant abordera l’exécution concrète des mouvements de boîtes et le suivi des opérations de migration.
Tests, validation et supervision de la relation d’organisation
Avant de lancer toute migration, la validation de la relation d’organisation cross-tenant Exchange Online est une étape critique : elle garantit que les deux tenants communiquent correctement et que les prérequis techniques sont réunis. Un test manqué à ce stade peut bloquer l’ensemble du mouvement de boîtes aux lettres.
Tests de connectivité et validation OAuth entre tenants
La première vérification porte sur la connectivité OAuth entre les deux environnements. L’OAuthApplicationId doit être présent et correctement associé dans la configuration de la relation d’organisation. Pour tester la connectivité, il est recommandé d’exécuter la commande Test-MigrationServerAvailability depuis le tenant source, en ciblant le endpoint du tenant cible. Une réponse positive confirme que le canal de confiance est opérationnel. En cas d’échec, il convient de vérifier les permissions déléguées de l’application Azure AD et la cohérence des domaines déclarés de part et d’autre.
Vérification des MailUsers dans le tenant cible
Selon Microsoft, les utilisateurs doivent exister en tant que MailUsers dans le tenant cible, accompagnés d’attributs de migration spécifiques, pour que le déplacement de boîte puisse s’initier (Source : Microsoft — 2026-01-26). Concrètement, chaque MailUser cible doit présenter un ExternalEmailAddress pointant vers l’adresse source, et l’attribut LegacyExchangeDN doit être synchronisé. La vérification peut s’effectuer via Get-MailUser en PowerShell ou depuis l’interface du centre d’administration Exchange. Cette étape conditionne directement le succès du contrôle de la migration tenant to tenant : aucun lot ne peut être soumis si les objets cibles sont absents ou mal configurés.
| Attribut | Description | Obligatoire |
|---|---|---|
| ExternalEmailAddress | Adresse de routage vers la boîte source | Oui |
| LegacyExchangeDN | Identifiant Exchange hérité pour la résolution | Oui |
| PrimarySmtpAddress | Adresse SMTP principale dans le domaine cible | Oui |
| Alias | Identifiant court unique dans le tenant cible | Oui |
Activation des logs et suivi des migrations
Une fois les migrations lancées, les Mailbox move logs constituent la source principale de supervision. Ils sont accessibles via Get-MoveRequestStatistics et fournissent des indicateurs clés : pourcentage de complétion, nombre d’éléments copiés, erreurs transitoires. Il est conseillé de mettre en place des alertes dans le centre de conformité Microsoft 365 pour être notifié de tout mouvement bloqué. La documentation officielle de migration multi-tenant Microsoft 365 détaille les codes d’erreur les plus fréquents et les procédures de reprise associées.
Sécurité et gouvernance pendant la migration
Les validation et tests de la relation d’organisation cross-tenant ne sauraient être complets sans un volet sécurité structuré. Le Conditional Access doit être configuré pour imposer la MFA sur les comptes impliqués dans la migration, en particulier les comptes de service. Les Sensitivity Labels attachés aux données migrées doivent être contrôlés pour éviter toute perte d’étiquetage entre tenants. Ces contrôles de sécurité et conformité Microsoft 365 s’inscrivent dans une logique de gouvernance continue, qui dépasse la simple phase de test et s’étend tout au long du projet. La prochaine étape consistera à aborder les scénarios de post-migration et de coexistence prolongée entre les deux tenants.
Conclusion
Configurer une relation d’organisation cross-tenant Exchange Online repose sur trois étapes structurantes : la création de l’application de migration, la configuration des règles d’organisation dans les deux tenants, et la validation des prérequis techniques avant tout transfert de boîte aux lettres. Respecter cette séquence est la condition de base pour sécuriser un projet de cross-tenant mailbox migration.
Les meilleures pratiques migration cross-tenant Exchange convergent toutes vers un même impératif : un pilotage conjoint entre les administrateurs source et cible dès la phase de conception. La gouvernance des relations d’organisation cross-tenant ne peut pas être traitée en silo. Elle engage à la fois des enjeux de sécurité Microsoft Entra ID, de conformité et d’objectifs métier liés au paramétrage de la migration Exchange Online tenant to tenant. À ce titre, il convient de noter que, selon Microsoft, les licences requises incluent Exchange Online et Teams (E3/E5) pour les tenants source et cible (Source : Microsoft — 2026-01-26), un point de vérification incontournable avant d’engager la migration.
Pour les organisations qui souhaitent sécuriser chaque étape, Eliadis accompagne ses clients en tant que partenaire Microsoft 365 expert, de la conception de la relation de confiance entre tenants jusqu’à la validation post-migration, en combinant expertise technique et gouvernance stratégique.
