Bonjour tout le monde
Je travaille actuellement sur un projet de migration entre 2 tenants Office 365 qui fait suite au rapprochement de 2 sociétés.
Ce projet, à première vue relativement simple (tout est dans le cloud) est en fait d’une très rare complexité comme nous allons le voir.
Le projet est toujours en cours. Cet article a surtout pour but de partager avec vous mes premières recherches, retours d’expériences.
Pour rappel, Office 365 c’est un ensemble de services qui s’appuient sur un annuaire Azure Active Directory dont Exchange Online, Skype for Business, la téléphonie Skype for Business (PSTN, si vous disposez de licence Office 365 E5), SharePoint Online, Yammer, Teams, les groups Office 365, Sway.
Mon client souhaite dans un premier temps faire coexister les 2 environnements puis lancer les migrations.
Retour d’expérience sur la coexistence entre 2 tenants Office 365 -> nombreux cas d’usages impossibles
Il est important de noter que la coexistence entre deux Tenants Office 365 est possible mais pas sans contraintes :
– Contrainte 1 : il n’est pas possible d’ajouter le même domaine de messagerie sur 2 tenants Office 365 en même temps. C’est la plus grosse contrainte. Il sera impossible de disposer d’un domaine de messagerie commun entre les 2 tenants si les utilisateurs des 2 tenants sont sous Exchange Online. Il existe des solutions pour partager un domaine de messagerie entre Exchange On-Premise et Exchange. Qui est volontaire pour faire une migration Exchange Online vers Exchange On-Premise ?
– Contrainte 2 : un serveur Azure AD Connect peut synchroniser plusieurs forêt Active Directory en tant que sources mais uniquement vers un seul Tenant Office 365. On oublie l’idée de synchroniser les utilisateurs dans 2 tenant Office 365 pour faire avoir une GAL à jour.
– Contrainte 3 : Office 365 génère un attribut appelé ImmutableId qui permet de lier un unique compte Active Directory avec un unique compte Azure Active Directory. Par défaut cet attribut est généré à partir de l’attribut ObjectGuid de l’annuaire Active Directory. Ce comportement par défaut générera des problèmes en cas de migration des comptes utilisateurs vers une nouvelle forêt car l’ObjectGuid change alors. Ce paramètre peut être modifié avec les dernières versions d’Azure Active Directory.
– Contrainte 4 : L’attribut UserPrincipalName d’Azure Active Directory (login Office 365, exemple : prenom.nom@tuifrance.com) est par défaut généré en se basant sur l’attribut UserPrincipalName d’Active Directory. Chaque domaine de messagerie Office 365 doit donc être ajouté en tant que suffixe UPN au niveau de l’annuaire Active Directory.
Créer une relation d’approbation entre 2 forêts avec les mêmes suffixe UPN générera des erreurs d’authentification avec le protocole Kerberos.
La solution est d’utiliser un autre attribut que l’attribut UserPrincipalName (Active Directory) pour générer le login Office 365. Cela s’appelle l’Alternate Login ID et cela n’est pas sans impact comme changement.
– Contrainte 5 : la mise en œuvre de l’Alternate Login ID nécessitera l’activation du protocole de fédération d’identités de dernière génération d’Office 365 (appelé aussi ADAL ou Modern Authentication). Cela nécessitera un changement au niveau du Tenant Office 365 et de modifier la configuration des serveurs de fédération d’identité. Le changement est moyennement complexe avec une solution de fédération d’identité comme ADFS, très complexe avec une solution de fédération d’identité tierce (il faut refaire toute la configuration, pas d’assistant…).
– Contrainte 6 : le mode Hybride Exchange ne peut être activé qu’entre une forêt Active Directory et un tenant Office 365. On oublie l’idée de faire un mode hybride entre un serveur Exchange On-Premise et 2 tenants Office 365.
– Contrainte 7 : il est possible de faire des conférences audio / vidéo et de la messagerie instantanée Skype for Business entre utilisateurs de 2 Tenant Office 365. Cependant les utilisateurs de 2 Tenant Office 365 ne pourront pas partager de plan de numérotation Skype (si licence Office 365 E5).
– Contrainte 8 : au niveau SharePoint et OneDrive For Business, les utilisateurs d’un Tenant Office 365 A sont vus comme des utilisateurs externes pour le Tenant Office 365 B. Il sera nécessaire d’autoriser le partage de données SharePoint / OneDrive for Business pour les utilisateurs externes.
– Contrainte 9 : Yammer, Planner, les Groups Office 365 considèrent les utilisateurs d’un autre Tenant Office 365 comme des utilisateurs externes / invités. Les fonctionnalités sont limitées.
– Contrainte 10 : la mise en œuvre d’une relation d’organisation (Exchange Online) entre 2 tenant Office 365 permettra de partager les informations de disponibilités et les calendriers. Elle ne permettra pas de partager les boîtes aux lettres.
– Contrainte 11 : Microsoft ne propose pas d’outil (autre que MIM 2016) pour synchroniser la liste d’adresses globale entre 2 tenant Office 365. Je vous préconise d’utiliser des scripts PowerShell pour effectuer cette action car le déploiement de MIM 2016 peut s’avérer complexe pour effectuer uniquement cette tâche.
– Contrainte 12 : L’Offline Address Book (OAB) est généré que toutes les 24 heures (non configurable). Exchange Online s’appuie sur l’attribut LegacyExchangeDn pour effectuer le routage des emails. Afin de conserver le LegacyExchangeDn et d’éviter des problèmes de routage email pendant 24h, il est nécessaire de créer les contacts comme des utilisateurs (MsolUser) avec adresse de messagerie externe et non comme des contacts avec adresse de messagerie externe (MsolContact).
Microsoft présente dans l’article ci-dessous les scénarios de coexistence pris en charge entre utilisateurs de 2 tenant Office 365 :
https://support.office.com/en-us/article/office-365-inter-tenant-collaboration-eb45fd8b-1d5d-4b0c-9c5a-479dbb176e7d
A ce jour Microsoft ne propose aucun outil de migration natif entre deux tenants Office 365.
Il est possible sans outil tiers de migrer les boîtes aux lettres Exchange Online entre 2 tenant Office 365 (export de la boîte aux lettres au format PST).
Il s’avère cependant très complexe de migrer les données des autres services comme OneDrive For Business, les sites Teams ou les groups Office 365 sans outil tiers.
On notera que certains outils tiers dédiés aux migrations entre 2 Tenants Office 365 ne sont pas capables de migrer tous les services Office 365 comme Sway, Teams, les groups Office 365.
Les contraintes 3,4 et 5 devront aussi être pris en compte (impact d’une éventuelle migration Active Directory). Vous devrez probablement configurer vos Tenants en Alternate Login ID et changer la méthode de génération de l’ImmutableID si vous prévoyez de fusionner les 2 domaines Active Directory après ou pendant le projet de migration Office 365.
Au niveau des outils de migration, je prévoie de tester les solutions suivantes :
Quest On Demand Migration :
https://www.quest.com/products/on-demand-migration/
BitTitan :
https://help.bittitan.com/hc/en-us/articles/115008106827-Office-365-to-Office-365-Migration-Guide-While-Keeping-the-Same-Domain-Name
https://help.bittitan.com/hc/en-us/articles/115010086447
https://help.bittitan.com/hc/en-us/articles/115008107427-OneDrive-for-Business-to-OneDrive-for-Business-Migration-Guide
https://help.bittitan.com/hc/en-us/articles/115008113567-Office-365-Group-to-Office-365-Group-Documents-Migration-Guide
https://help.bittitan.com/hc/en-us/articles/115008261988-SharePoint-to-SharePoint-Migration-Guide
Quadrotech Cloud Commander :
https://www.quadrotech-it.com/upcoming-product-release-tenant-to-tenant-cloud-migrations/
A très bientôt
Guillaume MATHIEU
Directeur Technique de Metsys
La connaissance s’accroît quand on la partage
http://msreport.free.fr
http://www.metsys.fr/blog
