Suite à la vente d’une grande partie d’une entreprise, le nouveau propriétaire souhaitait une adaptation rapide des adresses e-mail pour la communication interne et, plus important encore, externe des employés existants. Des migrations de domaine supplémentaires auront lieu ultérieurement, mais pour la première phase, le message était aussi clair que stimulant : 1700 utilisateurs, même domaine AD, nouveau domaine de messagerie.

Comme l’étendue complète de la migration couvre une forêt d’environ 15 domaines, la première étape consistait à déterminer quels 1700 des 2500 utilisateurs devaient recevoir la nouvelle adresse e-mail et à clarifier qui devait être migré ou non pour les phases ultérieures. Pour apporter le moins de modifications possible au domaine, nous avons choisi de ne pas créer de groupes ou d’UO pour marquer les utilisateurs comme « à migrer ». Nous avons opté pour remplir msDS-cloudExtensionAttribute19 avec une valeur spécifique, le rendant clair partout, à la fois sur site et dans le cloud. Étant donné que les Service Desks locaux avaient les droits de modifier cet attribut dans l’AD pour « leurs » utilisateurs, cette tâche a été effectuée par eux. C’était déjà une étape importante du processus.

L’étape suivante consistait à réunir les fonds nécessaires pour acheter un nouveau tenant O365 auprès de Microsoft. Comme le nouveau propriétaire avait déjà une messagerie sur site et donc son propre serveur de messagerie avec l’enregistrement MX correspondant (disons @company.com), nous avons choisi d’enregistrer @companycloud.onmicrosoft.com auprès de Microsoft. Dans une phase ultérieure, les utilisateurs de messagerie sur site de @company.com seront également transférés vers @companycloud.onmicrosoft.com, mais pour les garder séparés pour le moment, nous avons choisi ce nom pour le tenant O365.

Tout étant prêt pour transférer effectivement les utilisateurs, nous avons pu commencer à créer des utilisateurs dans notre nouveau tenant O365. Pour cela, un serveur Azure AD Connect a été installé à côté de l’AD sur site de l’ancienne entreprise. Celui-ci a été configuré pour synchroniser tous les utilisateurs avec le cloudExtensionAttribute19 rempli avec la valeur correcte vers le nouveau tenant. Lors de la création des utilisateurs dans l’Azure AD de companycloud, une boîte aux lettres vide était immédiatement créée. La même approche a été utilisée pour les boîtes aux lettres partagées ; elles ont été listées puis créées comme boîtes aux lettres vides sur le nouveau tenant. Environ 250 groupes ont été créés via PowerShell. Comme tous les utilisateurs étaient déjà connus sur le nouveau tenant à ce moment-là, nous avons pu peupler les groupes avec les bons utilisateurs et nous assurer qu’après la migration, les bonnes personnes avaient accès aux boîtes aux lettres partagées.

Avec toutes ces préparations soigneusement exécutées, nous nous sommes lentement approchés du grand jour où l’utilisateur final serait converti et pourrait utiliser la nouvelle adresse @company.com au lieu de son ancienne adresse e-mail. Pendant un week-end chargé, tous les e-mails des boîtes aux lettres de l’ancienne entreprise ont été copiés dans les nouvelles boîtes aux lettres vides sur le nouveau tenant, mais ce n’était pas tout. Bien sûr, tous les groupes Teams (avec l’historique des conversations), les sites SharePoint et les OneDrives ont également été copiés. Simultanément, des actions cruciales ont été menées sur deux autres fronts, car il n’est pas prévu que les e-mails soient envoyés à leur adresse du tenant companycloud. Pour que les e-mails envoyés à leur nouvelle adresse @company arrivent dans leur boîte aux lettres, des contacts de messagerie ont été créés sur site chez company pour livrer tous les e-mails envoyés à nom@company.com à nom@companycloud.onmicrosoft.com. Pour s’assurer qu’ils envoient avec la bonne adresse e-mail, l’adresse SMTP dans leur compte AD a été changée pour leur adresse company.com. Le dimanche de ce week-end, certains membres de l’IT ont déjà été invités à effectuer les étapes nécessaires sur leur PC pour utiliser leurs nouveaux comptes de messagerie. Ainsi, ces personnes étaient préparées à guider l’utilisateur final dans les ajustements nécessaires sur leur PC dans les jours suivants.

Les étapes que l’utilisateur final devait effectuer sur son PC ont été mises dans un script bien conçu à l’avance, qui a été placé sur le bureau de tous les PC via SCCM. Ainsi, l’utilisateur final pouvait simplement double-cliquer sur l’icône de migration, et tous les carnets d’adresses personnels, tâches, archives, ainsi que tous les fichiers PST personnels étaient transférés dans un dossier temporaire. Cela était suivi d’une déconnexion complète automatique d’Outlook, Teams et OneDrive. Le PC était également redémarré par sécurité, et les gens pouvaient se reconnecter, toujours avec leur utilisateur d’origine, car comme mentionné, le domaine AD n’était pas modifié. On leur demandait ensuite de démarrer Outlook et de se connecter avec leur nouvelle adresse e-mail et le même mot de passe (synchronisation AD). En effectuant une configuration MFA, leur PC devenait hybride joint au nouveau tenant, et à partir de ce moment, ils pouvaient utiliser Outlook, Teams et OneDrive sans avoir à se connecter constamment.

Après quelques tests et le transfert de quelques utilisateurs qui avaient été oubliés dans la liste initiale, ainsi que quelques fichiers Teams et OneDrive manquants, nous avons pu conclure après quelques semaines intenses que nous avions réussi la migration. En route pour le prochain projet de migration du domaine lui-même. J’ai hâte… 😊

Écrit par: Dimitri M.