> Tech > Migration Tenant a Tenant. Ce que vous devriez savoir !

Migration Tenant a Tenant. Ce que vous devriez savoir !

Tech - Par Laurent Teruin - Publié le 02 janvier 2025
email

La plupart des entreprises effectuent de la croissance externe, en acquérant des sociétés mais à l’inverse, parfois, se séparent d’une ou de plusieurs activités. Ces cessions / acquisitions occasionnent bien souvent la fusion voire l’exfiltration d’identités et de ressources.

Migration Tenant a Tenant. Ce que vous devriez savoir !

Dans le cas d’un environnement Cloud de type M365 se pose alors la question de pouvoir, soit intégrer, soit déplacer des utilisateurs et leurs ressources vers un autre tenant M365. Ce type de migration nommé par Microsoft comme « Cross Tenant » n’est pas si simple à réaliser. On vous explique ça tout de suite.

Pour commencer, la possibilité de migrer des ressources « inter ou cross tenant » M365 est assez récente mais comme vous le verrez, les fonctions proposées sont assez limitées.

  • La première des questions qu’il faut se poser est la suivante : Qu’entend-on par ressources ? S’agit-il de boîtes aux lettres et d’identités ? d’équipes Teams ? de sites SharePoint ?
  • La seconde des questions concerne le scénario de migration : Est-il envisageable de partir vers une migration en un week end (Cut-Over ou Single-event migration) ? ou au contraire vers une migration impliquant une coexistence. (Phased migration) ?  (En sachant qu’un nom de domaine ne peut pas être partagé par deux tenants au même moment).

Si vous le voulez bien nous allons commencer par l’identité. Comme je le précise à chaque projet, il faut toujours commencer par l’identité. Nous ajouterons ensuite, parce que nous sommes sur M365, l’aspect licence.

Migration des identités

Une solution de migration « cross tenant » devrait pouvoir offrir la possibilité de migrer les identités d’un tenant vers un autre tenant via la duplication de ces dernières. Certes, comme précisé ci-dessous, un domaine ne pouvant pas être partagé par plusieurs tenants, les identités cibles ne porteront pas le même UPN (ex : lteruin@unifiedit.fun) mais pourraient être provisionnées en attente d’activation. Prenons un exemple

La société unifiedit.fun décide de migrer une partie de ses utilisateurs vers un nouveau Tenant M365 portant le nom de domaine target.com. La solution de migration devrait pouvoir extraire sur la base d’un attribut dans l’Azure AD une liste d’utilisateurs concernés qui serait dupliquée dans l’Azure AD cible. Ainsi un utilisateur lteruin@unifiedit.fun serait dupliqué et maintenu comme tel, vers l’utilisateur lteruin@target.com du nouveau tenant. Idéalement la synchronisation des mots de passe entre ces entités serait un plus.

Licences M365

Dans notre cas, il va falloir, comme l’on dit à Marseille, « à un moment donné » du projet de migration, obtenir la présence de licence en double. Les licences M365 associées aux identités qui vont devoir être exfiltrées, devront être présentes sur les comptes sources & cibles (@target.com) durant un laps de temps qui dépend de l’agenda de votre projet. Cela suppose de prévenir votre interlocuteur Microsoft (Administrateur de services et responsable de service clientèle -CSAM) pour qu’un transfert de licence soit effectué et qu’un délai de grâce soit obtenu. Dans le cas contraire, vous devrez acquérir ces licences en double, le temps de la préparation de la migration jusqu’au jour J.

La fonctionnalité de duplication d’identité de votre solution de migration, devrait avoir la capacité d’identifier les licences directement positionnées sur les comptes concernés et les repositionner sur le compte cible si, naturellement, celles-ci sont disponibles.

En cas d’absence de licences sur l’environnement cible, la solution devrait être en mesure de présenter un rapport aux administrateurs de la solution de migration, permettant d’identifier les problèmes de correspondances de licence.

Migration des boites aux lettres Exchange (Mind the Gap !)

Si vous prenez le temps de consulter les différentes solutions de migration cross tenant disponibles sur le marché, vous vous apercevrez assez rapidement que le processus est présenté comme extrêmement simple et rapide. Dans la réalité et notamment dans l’environnement Exchange Online, disons qu’il existe un certain « gap » entre le monde idéal des fournisseurs de solutions et la réalité.  On vous explique ça.

La plupart des solutions que vous allez trouver sur le marché savent migrer des contenus de boites aux lettres Exchange Online d’un tenant source vers d’autres boites aux lettres Exchange Online d’un tenant cible. Le diable se cachant dans les détails, dans ce cas de figure on parle bien de migration de contenus et non de migration de boites aux lettres. Ce qui signifie d’une part que les boites aux lettres cibles doivent exister préalablement (d’où l’importance d’obtenir des licences M365 en double), et d’autre part que tout le reste ne sera pas migré.

Le « tout le reste » est important car il comprend, les délégations, les règles utilisateurs, ainsi que les alias de messagerie. Autant de paramètres que vous allez perdre et que vous allez devoir inventorier sur l’environnement source et repositionner à la main (Powershell) sur l’environnement source.

Les règles de boites aux lettres sont récupérables avec la commande get-inboxrule et les délégations le sont avec la commande Get-MailboxPermission. Vous trouverez des exemples sur le lien Microsoft suivant : https://learn.microsoft.com/en-us/exchange/recipients/mailbox-permissions?view=exchserver-2019

Migration des listes de distribution Exchange

Qu’elle soit de type statique ou dynamique, la migration des listes de distribution n’est parfois pas prise en compte par les solutions de migration du marché. Ce qui signifie, que là aussi, vous allez devoir les recréer manuellement dans l’environnement cible. Selon leur nombre et leur imbrication, cela peut représenter un travail non négligeable d’analyse et de création.

La difficulté dans la migration des listes de distribution statiques est qu’il est parfois difficile de les dupliquer depuis la source car les membres de ces dernières ne sont peut-être pas tous concernés par la migration. L’outil de migration ou votre script PowerShell devra donc prendre en compte les identités sources et omettre les identités qui ne doivent pas être exfiltrées. Le plus simple est encore d’identifier les identités concernées par l’exfiltration, via une valeur d’attribut dans l’Azure AD source ou par leur appartenance à un groupe Azure AD.

La migration des listes de distribution dynamiques est également délicate car la transposition des critères de sélection qui les composent ne sont pas forcément reproductibles sur l’environnement cible.  Vous devrez donc les examiner au cas par cas et les reproduire manuellement.

On notera qu’en plus des membres d’une liste de distribution, celle-ci possède des caractéristiques propres ainsi que des délégations qu’il faudra reproduire à l’identique ou les adapter en fonction du contexte. Autant de choses que vous devez préparer avant le jour J de la migration.

Gestion des alias et l’adresse de messagerie primaire

Si vous envisagez une migration en un week-end, certaines solutions du marché peuvent synchroniser le contenu des boites aux lettres sources vers les boites aux lettres cibles en maintenant une relation 1 à 1. Cette synchronisation de contenu est nécessaire pour effectuer une migration du jour ou lendemain (CutOver Migration) car compte tenu des volumes en jeu, mieux vaut synchroniser le contenu au préalable.

Comme un nom de domaine ne peut pas être partagé par deux tenants et si vous avez la nécessité de migrer le nom de domaine, les UPN cibles et l’adresse de messagerie primaire avant le jour J vont nécessairement être différents de ceux d’origine. En revanche, le jour, ou le week-end où vous effectuerez la migration définitive, il vous faudra :

  • Supprimer toute référence du domaine à migrer dans l’environnement M365 du domaine source pour pouvoir procéder à sa suppression
  • Mettre en place le domaine sur le nouveau tenant (Déclaration du domaine, ajout d’un enregistrement TXT et MX dans la zone DNS)
  • Modifier les identités migrées pour qu’elles retrouvent leurs noms de domaine d’origine ainsi que leur alias. Ne pas oublier les listes de distribution qui elles aussi doivent recevoir leurs alias d’origine.

On est donc très loin du monde « bisounours » présenté par certains « Solution Providers » qui vantent une migration simple et rapide.

Migration Teams

La migration des équipes Teams est également délicate car une partie des identités des équipes que vous devez migrer ne sont pas obligatoirement concernées par l’exfiltration. Pensez à vérifier que les équipes Teams de l’environnement cible sont en mesure de récupérer à minima un propriétaire.

Les données Teams sont stockées à plusieurs endroits. Les fichiers Teams sont stockés dans SharePoint Online et les fichiers de chat Teams sont stockés dans OneDrive for Business. La messagerie vocale, le calendrier et les contacts sont stockés dans Exchange Online.

Aussi, vérifiez bien que votre solution de migration prend en charge tous ces emplacements et si la migration des propriétés des équipes et des canaux est assurée.  Dans la plupart des cas, il n’existe pas de translation de réunion. Autrement dit, si vos utilisateurs ont créé des réunions Teams dans le tenant source via Outlook, une fois migrés, les liens vers ces réunions ne fonctionneront plus. Sauf si la solution de migration a une capacité à récréer ces dernières dans l’environnement cible.

D’une façon plus globale, les fonctionnalités de Teams sont liées à l’environnement Exchange Online. Si vous utilisez ces deux environnements, vous devriez considérer le fait de les migrer dans le même laps de temps.

Dans le cadre d’une migration Teams Cross Tenant, l’usage d’une solution tierce est fortement recommandé. (Voir les acteurs du marché)

SharePoint Online

La migration de site SharePoint est, selon le degré de sophistication de l’environnement source, un projet à part entière. Au-delà des problèmes d’identité et de permission, il vous faudra auditer, précisément, les sites concernés et déterminer les conséquences d’une migration vers un autre Tenant.

Une autre difficulté réside cette fois-ci côté client. Si vos utilisateurs doivent à un moment donné du projet, accéder à deux sites SharePoint qui ne sont pas dans le même Tenant, gardez en tête qu’un explorateur internet ne peut pas se connecter à deux tenants différents sauf à utiliser le mode privé. Il faudra donc l’expliquer aux utilisateurs.

Avec SharePoint Online, l’usage d’une solution tierce est indispensable. Une des références en la matière se trouve chez ShareGate.  (https://sharegate.com/).

La migration de sites SharePoint online demande une connaissance approfondie de ce domaine, mais elle requiert également une bonne connaissance des fonctions et scenarios supportés par la solution de migration.  Si vos équipes ne possèdent que des connaissances superficielles, et si l’environnement source est complexe, je vous conseille vivement de faire appel à une société partenaire Microsoft.

Les fournisseurs de solutions

Pour notre migration inter-tenant, nous avons retenu trois fournisseurs de solutions avec lesquels j’ai pris l’habitude de travailler depuis plusieurs années.

  • Quest : Quest parce que cet éditeur fournit depuis longtemps des solutions de migration et que son offre s’est étayée avec le rachat de Binary Tree
  • BitTitan : Parce que j’ai déjà travaillé avec eux de nombreuses fois sur certaines migrations et que la solution était plutôt bien pensée.
  • Avepoint : Parce que je n’ai jamais travaillé avec eux et que je voulais connaitre leur environnement

En leur envoyant un tableau listant l’ensemble des points de migration, j’ai pu m’apercevoir que Quest et Avepoint restaient, sur ce type de migration, les plus avancés fonctionnellement.

Les impacts sur les postes de travail

Pensez à migrer le contenu, c’est une chose mais estimer l’impact poste de travail, donc l’impact utilisateur, en est une autre. Si la plupart des solutions permettent de migrer en une soirée des sites SharePoint entiers voire des milliers de boites aux lettres, se pose la question de la reconnexion du poste de l’utilisateur vers le nouveau Tenant.

La plupart des fournisseurs de solutions fournissent un agent à déployer sur le poste de travail pour permettre une reconnexion des postes concernés vers le nouveau Tenant. Cet agent fonctionne sous Windows, peu en possèdent pour Macintosh.

Selon votre scénario, selon vos contraintes, une migration inter-tenant n’est pas un projet simple et va vous demander une préparation attentionnée. Comme précisé, l’usage d’une solution SaaS est fortement recommandée ainsi que de solides connaissances sur les environnements migrés, mais également sur les capacités et limites de la solution SaaS retenue.

Si vous ne disposez pas de suffisamment de compétences techniques ou si vous manquez de temps, je vous recommande vivement de faire appel à un prestataire de services ayant l’expérience de ce type de migration !

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental

Tech - Par Laurent Teruin - Publié le 02 janvier 2025