Suite \u00e0 la vente d’une grande partie d’une entreprise, le nouveau propri\u00e9taire souhaitait une adaptation rapide des adresses e-mail pour la communication interne et, plus important encore, externe des employ\u00e9s existants. Des migrations de domaine suppl\u00e9mentaires auront lieu ult\u00e9rieurement, mais pour la premi\u00e8re phase, le message \u00e9tait aussi clair que stimulant : 1700 utilisateurs, m\u00eame domaine AD, nouveau domaine de messagerie. <\/p>\n
Comme l’\u00e9tendue compl\u00e8te de la migration couvre une for\u00eat d’environ 15 domaines, la premi\u00e8re \u00e9tape consistait \u00e0 d\u00e9terminer quels 1700 des 2500 utilisateurs devaient recevoir la nouvelle adresse e-mail et \u00e0 clarifier qui devait \u00eatre migr\u00e9 ou non pour les phases ult\u00e9rieures. Pour apporter le moins de modifications possible au domaine, nous avons choisi de ne pas cr\u00e9er de groupes ou d’UO pour marquer les utilisateurs comme \u00ab\u00a0\u00e0 migrer\u00a0\u00bb. Nous avons opt\u00e9 pour remplir msDS-cloudExtensionAttribute19 avec une valeur sp\u00e9cifique, le rendant clair partout, \u00e0 la fois sur site et dans le cloud. \u00c9tant donn\u00e9 que les Service Desks locaux avaient les droits de modifier cet attribut dans l’AD pour \u00ab\u00a0leurs\u00a0\u00bb utilisateurs, cette t\u00e2che a \u00e9t\u00e9 effectu\u00e9e par eux. C’\u00e9tait d\u00e9j\u00e0 une \u00e9tape importante du processus. <\/p>\n
L’\u00e9tape suivante consistait \u00e0 r\u00e9unir les fonds n\u00e9cessaires pour acheter un nouveau tenant O365 aupr\u00e8s de Microsoft. Comme le nouveau propri\u00e9taire avait d\u00e9j\u00e0 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\u00e8s de Microsoft. Dans une phase ult\u00e9rieure, les utilisateurs de messagerie sur site de @company.com seront \u00e9galement transf\u00e9r\u00e9s vers @companycloud.onmicrosoft.com, mais pour les garder s\u00e9par\u00e9s pour le moment, nous avons choisi ce nom pour le tenant O365. <\/p>\n
Tout \u00e9tant pr\u00eat pour transf\u00e9rer effectivement les utilisateurs, nous avons pu commencer \u00e0 cr\u00e9er des utilisateurs dans notre nouveau tenant O365. Pour cela, un serveur Azure AD Connect a \u00e9t\u00e9 install\u00e9 \u00e0 c\u00f4t\u00e9 de l’AD sur site de l’ancienne entreprise. Celui-ci a \u00e9t\u00e9 configur\u00e9 pour synchroniser tous les utilisateurs avec le cloudExtensionAttribute19 rempli avec la valeur correcte vers le nouveau tenant. Lors de la cr\u00e9ation des utilisateurs dans l’Azure AD de companycloud, une bo\u00eete aux lettres vide \u00e9tait imm\u00e9diatement cr\u00e9\u00e9e. La m\u00eame approche a \u00e9t\u00e9 utilis\u00e9e pour les bo\u00eetes aux lettres partag\u00e9es ; elles ont \u00e9t\u00e9 list\u00e9es puis cr\u00e9\u00e9es comme bo\u00eetes aux lettres vides sur le nouveau tenant. Environ 250 groupes ont \u00e9t\u00e9 cr\u00e9\u00e9s via PowerShell. Comme tous les utilisateurs \u00e9taient d\u00e9j\u00e0 connus sur le nouveau tenant \u00e0 ce moment-l\u00e0, nous avons pu peupler les groupes avec les bons utilisateurs et nous assurer qu’apr\u00e8s la migration, les bonnes personnes avaient acc\u00e8s aux bo\u00eetes aux lettres partag\u00e9es. <\/p>\n
Avec toutes ces pr\u00e9parations soigneusement ex\u00e9cut\u00e9es, nous nous sommes lentement approch\u00e9s du grand jour o\u00f9 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\u00e9, tous les e-mails des bo\u00eetes aux lettres de l’ancienne entreprise ont \u00e9t\u00e9 copi\u00e9s dans les nouvelles bo\u00eetes aux lettres vides sur le nouveau tenant, mais ce n’\u00e9tait pas tout. Bien s\u00fbr, tous les groupes Teams (avec l’historique des conversations), les sites SharePoint et les OneDrives ont \u00e9galement \u00e9t\u00e9 copi\u00e9s. Simultan\u00e9ment, des actions cruciales ont \u00e9t\u00e9 men\u00e9es sur deux autres fronts, car il n’est pas pr\u00e9vu que les e-mails soient envoy\u00e9s \u00e0 leur adresse du tenant companycloud. Pour que les e-mails envoy\u00e9s \u00e0 leur nouvelle adresse @company arrivent dans leur bo\u00eete aux lettres, des contacts de messagerie ont \u00e9t\u00e9 cr\u00e9\u00e9s sur site chez company pour livrer tous les e-mails envoy\u00e9s \u00e0 nom@company.com \u00e0 nom@companycloud.onmicrosoft.com. Pour s’assurer qu’ils envoient avec la bonne adresse e-mail, l’adresse SMTP dans leur compte AD a \u00e9t\u00e9 chang\u00e9e pour leur adresse company.com. Le dimanche de ce week-end, certains membres de l’IT ont d\u00e9j\u00e0 \u00e9t\u00e9 invit\u00e9s \u00e0 effectuer les \u00e9tapes n\u00e9cessaires sur leur PC pour utiliser leurs nouveaux comptes de messagerie. Ainsi, ces personnes \u00e9taient pr\u00e9par\u00e9es \u00e0 guider l’utilisateur final dans les ajustements n\u00e9cessaires sur leur PC dans les jours suivants. <\/p>\n
Les \u00e9tapes que l’utilisateur final devait effectuer sur son PC ont \u00e9t\u00e9 mises dans un script bien con\u00e7u \u00e0 l’avance, qui a \u00e9t\u00e9 plac\u00e9 sur le bureau de tous les PC via SCCM. Ainsi, l’utilisateur final pouvait simplement double-cliquer sur l’ic\u00f4ne de migration, et tous les carnets d’adresses personnels, t\u00e2ches, archives, ainsi que tous les fichiers PST personnels \u00e9taient transf\u00e9r\u00e9s dans un dossier temporaire. Cela \u00e9tait suivi d’une d\u00e9connexion compl\u00e8te automatique d’Outlook, Teams et OneDrive. Le PC \u00e9tait \u00e9galement red\u00e9marr\u00e9 par s\u00e9curit\u00e9, et les gens pouvaient se reconnecter, toujours avec leur utilisateur d’origine, car comme mentionn\u00e9, le domaine AD n’\u00e9tait pas modifi\u00e9. On leur demandait ensuite de d\u00e9marrer Outlook et de se connecter avec leur nouvelle adresse e-mail et le m\u00eame mot de passe (synchronisation AD). En effectuant une configuration MFA, leur PC devenait hybride joint au nouveau tenant, et \u00e0 partir de ce moment, ils pouvaient utiliser Outlook, Teams et OneDrive sans avoir \u00e0 se connecter constamment. <\/p>\n
Apr\u00e8s quelques tests et le transfert de quelques utilisateurs qui avaient \u00e9t\u00e9 oubli\u00e9s dans la liste initiale, ainsi que quelques fichiers Teams et OneDrive manquants, nous avons pu conclure apr\u00e8s quelques semaines intenses que nous avions r\u00e9ussi la migration. En route pour le prochain projet de migration du domaine lui-m\u00eame. J’ai h\u00e2te… \ud83d\ude0a <\/p>\n
\u00c9crit par: Dimitri M.<\/p>\n","protected":false},"excerpt":{"rendered":"
Suite \u00e0 la vente d’une grande partie d’une entreprise, le nouveau propri\u00e9taire souhaitait une adaptation rapide des adresses e-mail pour la communication interne et, plus important encore, externe des employ\u00e9s existants. Des migrations de domaine suppl\u00e9mentaires auront lieu ult\u00e9rieurement, mais pour la premi\u00e8re phase, le message \u00e9tait aussi clair que…<\/span><\/p>\n","protected":false},"author":2,"featured_media":18433,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[251,254],"tags":[255,300,337],"class_list":["post-21322","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-fr","category-ict-fr","tag-connect-consulting-fr","tag-ict-fr","tag-migration-o365"],"acf":[],"yoast_head":"\n