Sommaire
ToggleLorsque que l’on souhaite migrer ses comptes utilisateurs, ses groupes et ses machines vers une nouvelle forêt Active Directory, une question revient systématiquement.
Disposez-vous d’une messagerie Microsoft Exchange ?
Introduction & Contexte
Nous allons voir dans cet article que cette question à priori hors sujet est très structurante pour ce type de projet.
Exchange stocke en effet sa configuration dans la partition de configuration d’Active Directory (exemple : CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=metsys,DC=intra ). Pour cette raison, il ne peut y avoir qu’une seule organisation Exchange par forêt et une organisation Exchange ne peut pas s’étendre sur 2 forêts Active Directory différentes.
Dans notre exemple, la personne disposait d’Exchange et souhaite migrer toutes ses ressources (comptes utilisateurs, groupes, comptes ordinateurs, boîtes aux lettres Exchange et dossiers publics) vers une nouveau domaine / forêt Active Directory. Il souhaite également que la migration se fasse progressivement et sans perte de fonctionnalités pendant la phase de migration.
Un utilisateur migré devait par exemple pouvoir accéder au(x) calendrier(s) d’un utilisateur non migré et à ses données sur un serveur de fichiers non migré.
La personne doit pouvoir aussi utiliser uniquement des outils de migration fournis par Microsoft (outils gratuits) pour des raisons budgétaires principalement.
Comment migrer les comptes utilisateurs, groupes et les machines dans la nouvelle forêt sans impacter les utilisateurs ?
Microsoft fournit gratuitement un outil appelé Microsoft ADMT (actuellement en version 3.2) qui permet de migrer de manière relativement transparente les comptes utilisateurs, les groupes et les comptes ordinateurs d’un domaine / forêt Active Directory source vers un domaine / forêt Active Directory cible.
Cet outil dispose d’une fonctionnalité appelée SIDHistory qui permet à un utilisateur migré de continuer à accéder à ses données même si elles sont hébergées sur un serveur non migré.
Comment migrer les boîtes aux lettres et les dossiers publics vers la nouvelle forêt Exchange sans impacter les utilisateurs ?
La réponse est simple. Cela ne se fera pas sans impact. Il est en effet nécessaire dans ce cas de créer une nouvelle organisation Exchange dans le domaine / forêt cible et d’effectuer une migration inter-organisation Exchange.
Hors une migration inter-organisation Exchange est tout sauf sans impact.
Ce qui marche avec les outils natifs de migration inter-organisation Exchange :
Microsoft fournit deux scripts PowerShell pour déplacer une boîte aux lettres entre 2 organisations Exchange différentes.
Nous vous invitons à lire l’article http://msexchangeguru.com/2013/11/03/e2013crossforestmigration.
Microsoft fournissait avec Exchange 2003 un outil pour migrer les dossiers publics entre 2 organisations Exchange différentes. Cet outil bien que non supporté sous Exchange 2007 / 2010 semble fonctionner (non testé). On notera que l’on est obligé de déployer un serveur Windows 2003 comme expliqué dans l’article :
https://blog.gothamtg.com/2012/10/19/interorg-public-folder-replication-exchange-2007-to-exchange-2010/
Une autre technique consiste à recréer une topologie de dossiers publics vierge à l’aide de commandes PowerShell puis de migrer le contenu des dossiers publics à l’aide d’un client Outlook ! Il faut pour cela configurer le client Outlook avec un compte dans l’organisation Exchange source et un compte dans l’organisation Exchange cible. Les amoureux des scripts PowerShell basés sur les objets COM Outlook pourront toujours automatiser cette tâche mais c’est bien compliqué tout de même !
Ce qui marche partiellement ou pas du tout lors d’une migration inter-organisations Exchange
Microsoft permet depuis Exchange 2010 de fédérer 2 organisations Exchange différentes. Cette fonctionnalité permet de partager les informations de disponibilité entre les 2 organisations Exchange et de partager le calendrier entre utilisateurs de 2 organisations Exchange différentes.
On notera cependant qu’un utilisateur de l’organisation Exchange A ne peut pas ouvrir la boîte aux lettres d’un utilisateur d’une organisation Exchange B.
Il n’est pas non plus possible de synchroniser le contenu des dossiers publics entre serveurs de 2 organisations Exchange différentes.
Le point le plus critique reste cependant le besoin de reconfigurer les clients Outlook et les terminaux mobiles après la migration de la boîte aux lettres sur le nouveau serveur.
On comprend donc à la lecture de ces quelques lignes qu’une migration inter-organisation est tout sauf sans impact. Nous allons maintenant voir quelques astuces pour contourner ces différentes problématiques.
Comment limiter les impacts d’une migration inter-organisations Exchange
Il faut pour cela réduire au maximum la durée de la migration des boîtes aux lettres / dossiers publics entre les 2 organisations.
Il est cependant difficile d’envisager une migration Active Directory sur quelques jours / semaines surtout quand on dispose de plusieurs milliers de stations de travail / serveurs à migrer. L’outil ADMT permet en plus de faire coexister très correctement les utilisateurs migrés / non migrés.
Pour cette raison, la bonne approche est de séparer complètement la migration Exchange et la migration Active Directory et de les traiter comme 2 tâches indépendantes. Pour cela, il faut découper le projet en 4 phases.
Phase 1 : configuration du serveur ADMT 3.2 et mise en œuvre de la fédération entre les 2 organisations Exchange
- La première étape est de créer une relation d’approbation entre les 2 forêts, déployer l’outil Microsoft ADMT et d’activer la prise en charge du SID History.
- La seconde étape sera de créer la relation (fédération) entre les 2 organisations Exchange comme expliqué dans l’article Microsoft :
https://technet.microsoft.com/fr-fr/library/dd351260(v=exchg.141).aspx - La troisième étape sera d’exporter les permissions sur les boîtes aux lettres Exchange et sur les dossiers publics.
Phase 2 : migration des dossiers publics de l’organisation Exchange source vers l’organisation Exchange cible
Il n’est pas possible de synchroniser les dossiers publics entre deux organisations Exchange 2007 et versions ultérieures. En conséquence il est nécessaire de :
- Sauvegarder le contenu de la base de dossiers publics de l’organisation Exchange source au format PST à l’aide du client Outlook.
- Exporter la topologie de dossiers publics (script Metsys) de l’organisation Exchange source et la recréer dans l’organisation Exchange cible (script Metsys).
- Migrer le contenu des dossiers publics à l’aide d’un client Outlook (script Metsys).
- Convertir tous les accès en lecture / écriture au niveau des dossiers publics de l’organisation Exchange source en accès en lecture seule (script Metsys).
Le but est de migrer les dossiers publics sur les serveurs de l’organisation Exchange cible et d’empêcher les modifications par des utilisateurs de l’organisation Exchange source.
Remarque
Nous préconisons de ne pas migrer les dossiers publics vers des boîtes aux lettres de site car cette solution nécessite l’achat de licences SharePoint Server Standard ou Entreprise. De plus, elle est complexe à paramétrer et limitée en terme de fonctionnalités. Un pas à pas complet est disponible à cette adresse :
https://spasipe.wordpress.com/2013/03/19/sharepoint-2013-les-site-mailboxes-44-limitations-et-utilisation-de-logiciels-tiers
Phase 3 : migration des boîtes aux lettres et reconfiguration des clients Outlook / terminaux mobiles puis suppression de l’organisation Exchange source
- La première étape sera d’utiliser le script Microsoft pour créer le compte utilisateur avec adresse de messagerie externe. Pour cela, il faut appliquer la procédure expliquée dans cet article :
http://msexchangeguru.com/2013/11/03/e2013crossforestmigration/ - La seconde étape est de lancer une migration de tous les comptes utilisateurs et de tous les groupes du domaine / forêt Active Directory source vers le domaine / forêt Active Directory cible. Il faudra configurer l’outil Microsoft ADMT pour faire une fusion avec le compte créé par le script de migration Exchange (étape précédente).
- La troisième étape sera de migrer toutes les boîtes aux lettres de l’organisation Exchange source en tant que boîte aux lettres liée dans l’organisation Exchange cible. Les utilisateurs accéderont à leur nouvelle boîte aux lettres en s’authentifiant avec leur compte utilisateur du domaine / forêt source. L’article Microsoft ci-dessous présente la fonctionnalité de boîte aux lettres liées :
https://technet.microsoft.com/fr-fr/library/jj673532(v=exchg.150).aspx - La quatrième étape sera d’importer les permissions sur les boîtes aux lettres et les dossiers publics (script Metsys).
- La cinquième étape sera de reconfigurer les clients Outlook à l’aide d’un script PRF pour qu’il modifie le profil Outlook afin d’utiliser le nouveau serveur de messagerie. La procédure est expliquée dans l’article : http://www.howto-outlook.com/howto/deployprf.htm.
- La sixième étape sera de reconfigurer les entrées DNS / SRV pour l’Autodiscover Exchange dans le domaine / forêt source afin de pointer vers les serveurs de l’organisation Exchange cible. Cette action ne pourra être effectuée que lorsque toutes les boîtes aux lettres seront migrées vers l’organisation Exchange cible.
- La septième étape sera de supprimer le ou les serveurs de l’organisation Exchange source.
Phase 4 : migration des ressources Active Directory (comptes utilisateurs, groupes et comptes ordinateurs), migration des machines membres puis suppression de l’ancien domaine et du SID History
Cette phase peut être effectuée progressivement. Il est recommandé de faire des lots de 20 utilisateurs / stations de travail par jour par technicien. Elle consiste à effectuer les actions suivantes pour chaque utilisateur / station de travail :
- Migrer une seconde fois le compte utilisateur dans le domaine / forêt cible (pour la mise à jour du mot de passe, utilisation du mode fusion de l’outil Microsoft ADMT).
- Activer le compte utilisateur et convertir la boîte aux lettres liée en boîte standard. L’utilisateur accédera à sa boîte aux lettres avec son compte dans le domaine / forêt cible.
- Migrer la station de travail de l’utilisateur dans le domaine / forêt cible avec l’outil Microsoft ADMT.
- Réappliquer les permissions au niveau des boîtes aux lettres et des dossiers publics (script Metsys).
Remarques
Afin de tenir la cadence de 20 stations de travail par jour et par technicien, il est important d’effectuer les actions suivantes :
- Dans la mesure du possible, les stations de travail portables doivent être migrées dans un banc d’intégration.
- Les mots de passe de démarrage doivent être désactivés temporairement.
- Une GPO doit être configurée pour désactiver l’antivirus temps réel, la veille écran et permettre un accès aux partages administratifs (ADMIN$, C$) depuis le serveur Microsoft ADMT.
- ADMT 3.2 ne prend pas en charge les OS antérieurs à Windows 2003 (https://technet.microsoft.com/fr-fr/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx). Il sera nécessaire de prévoir une procédure spéciale pour ce type de machine.
Une fois l’ensemble des stations de travail et des serveurs membres migrés vers le nouveau domaine / forêt, il est nécessaire de supprimer le SID History et l’ancien domaine / forêt Active Directory.
C’est seulement à ce moment que l’on peut affirmer que la migration est terminée et qu’elle est un succès.