Migration vers Active Directory 2008 R2 – 2e partie

Une fois les contrôleurs de domaine 2008 R2 installés et synchronisés (voir la première partie de cet article), nous allons passer à la migration des rôles Active Directory, suivie du retrait des anciens contrôleurs de domaine.

 

a)    Vérifications intermédiaires

Avant de rétrograder les anciens contrôleurs de domaine, il faut vérifier que la nouvelle infrastructure ne comporte pas de problèmes. 2008 Server R2 à l’avantage de posséder dès l’installation de composants, d’outils permettant de vérifier leur bon fonctionnement. De ce fait, les outils utilisés précédemment sont déjà installés.

Ces outils peuvent être trouvés dans la console Server Manager, en sélectionnant le rôle à tester. Comme lors des tests de la plate-forme 2003, exécuter un test dcdiag.

 

Chaque rôle possède également un analyseur de best practices (BPA). Lancer l’analyse des rôles Active Directory et DNS sur chaque serveur et corriger les problèmes éventuels.

Remarque : Il est conseillé, si possible, d’attendre au moins 24h avant de lancer ces tests – idéalement, et avant de désinstaller les serveurs 2003. Cela permet aux journaux d’événements d’êtres propres de toute erreur de réplication, normales lors du démarrage de l’infrastructure et permet des résultats plus cohérents.

Pour lancer les tests, ouvrir la fenêtre racine de chaque rôle, et cliquer sur Scan This Role, dans la section Best Practices Analyser.

b)    Migration des rôles FSMO

Dans un domaine Active Directory, le contrôle et la diffusion de l’annuaire est effectuée de manière uniforme par l’ensemble des contrôleurs de domaine. Cependant, certains rôles critiques, appelés les rôles FSMO, ne sont effectués que par un seul contrôleur de domaine sur le réseau. Il faut donc migrer l’ensemble de ces rôles vers un des nouveaux serveurs avant d’arrêter les anciens serveurs.

Il est possible de cumuler l’ensemble des rôles sur un seul et même serveur (celui du siège par exemple).

 

Pour migrer chaque rôle, ouvrir une session sur le nouveau contrôleur de domaine principal et procéder comme suit :

 

RID, PDC et Infrastructure Masters :

Lancer la console Active Directory Users and Computers et faire un clic-droit sur le domaine. Choisir l’option Operations Masters.

Dans la fenêtre qui s’ouvre, choisir chaque rôle – un par onglet, et cliquer sur changer. Vérifier ensuite que le nouveau rôle est bien migré vers un serveur 2008.

 

Schema master :

Avant de pouvoir lancer la console de gestion du schéma, il faut enregistrer le snap-in en exécutant la commande :

regsvr32 schmmgmt.dll

 

Lancer ensuite une mmc et ajouter le snap-in Active Directory Schema (File / Add or Remove Snap-ins.) :

Dans la console AD Schema, faire un clic-droit sur la racine, puis Change Directory Server. Choisir le nouveau contrôleur principal :

 

Un message d’avertissement précise qu’il ne sera pas possible de modifier le schéma.
Refaire un clic-droit sur la racine, pointant maintenant sur le nouveau serveur puis choisir la rubrique Operations Master. Comme pour les autres rôles, cliquer sur Change

 

Domain Naming Master :

Pour changer ce dernier rôle FSMO, lancer la console Active Directory Domains and Trusts.
Faire un clic-droit sur le domaine. Choisir l’option Operations Master. Comme précédemment, cliquer sur Change :

 

c)     Migration des clients et des services

Avant de supprimer les anciens contrôleurs de domaine du réseau, il est nécessaire de vérifier que l’ensemble des clients interroge les nouveaux serveurs pour tous les services fournis.

Il faut notamment vérifier la configuration DNS des clients. Si celle-ci est fournie via DHCP, il suffit de mettre à jour l’option envoyée sur le serveur DHCP et d’attendre le temps d’expiration pour que les clients renouvellent leur bail et obtienne la nouvelle configuration. Si la configuration est fixée en statique sur chaque poste, il est possible de la mettre à jour via une GPO.

 

Pour la migration des services, il faut vérifier l’ensemble des services se basant sur Active Directory ou LDAP (messagerie, ERP, base de données…). Certains vieux systèmes peuvent pointer sur un contrôleur de domaine spécifique. Afin de pointer sur le domaine de manière générale (et donc sur le contrôleur de domaine utilisé pour l’authentification, on peut utiliser le nom de domaine comme nom de serveur LDAP.

Remarque : Pour un serveur Exchange, la configuration par défaut ne précise pas de contrôleur de domaine spécifique. Pour vérifier que c’est toujours le cas, lancer la console Exchange, et clique sur Modify Configuration Domain Controller, dans la section Organization. Décocher la case Configuration Domain Controller pour pointer vers n’importe quel contrôleur de domaine disponible.

 

d)    Retrait des anciens contrôleurs de domaine

Une fois que chaque site dispose d’un nouveau contrôleur de domaine et que les rôles FSMO ont été migrés, il est possible d’enlever les anciens serveurs.

Ce retrait doit de préférence être planifié en heure creuse pour deux raisons :

  • Les utilisateurs connectés à l’AD sur ce serveur lors du retrait peuvent se retrouver dans un fonctionnement instable avec certaines applications (pas de problème particulier avec un Windows classique) lors du retrait du serveur. Si cela arrive, une réouverture de session réglera le problème.
  • Le serveur devra être redémarré. Cela peut poser problème si le serveur mutualise plusieurs rôles (un contrôleur de domaine également serveur de fichier par exemple).

Il est essentiel de retirer les contrôleurs de domaine « proprement », c’est-à-dire en utilisant dcpromo et non en éteignant simplement le serveur. Cette étape permet de supprimer les références obsolètes de ce contrôleur dans l’annuaire et garantis la cohérence de la topologie de réplication.

 

Pour cela, se connecter localement sur chaque serveur 2003. Il faut d’abord vérifier que l’ordinateur courant est bien celui auquel est connectée la console Active Directory Users and Computers. Si ce n’est pas le cas, le service Active Directory pourrait être supprimé sur un autre serveur que celui où est exécutée la commande dcpromo.

Pour cela, lancer la commande AD Users and Computers, puis faire un clic-droit sur le domaine puis connect to domain controller. Sélectionner le serveur courant, puis valider :

Changer la configuration du client DNS, pour que le serveur ne pointe plus sur lui-même, mais sur le nouveau contrôleur le plus proche, tout comme un serveur classique. Lancer ensuite la commande dcpromo.exe.

Ne PAS cocher la case This server is the last in the domain. Entrer le nouveau mot de passe de l’administrateur local et valider.

 

A la fin de l’installation, le serveur va redémarrer.

Désinstaller le serveur DNS, via Add/Remove Windows Components.

 

Une fois chaque contrôleur retiré, ne pas oublier de le retirer du client DNS des nouveaux serveurs.

Vérifier que les anciens serveurs ne sont plus présents dans l’AD, dans l’OU Domain controllers, ni dans la liste des serveurs DNS gérants chaque zone.

Vérifier également qu’ils n’existent plus dans chaque site de réplication, dans la console AD Sites and Services. (Suite à des problèmes de réplication dus à la suppression du contrôleur, les serveurs ne sont pas toujours supprimés).

 

e)     Augmentation des niveaux fonctionnels

Lorsque le domaine est entièrement géré par des contrôleurs de domaine 2008, il est possible d’augmenter le niveau fonctionnel de la forêt et du domaine afin d’apporter des fonctionnalités supplémentaires, telles que la réplication DFS de l’annuaire, les contrôleurs en lecture seule, la possibilité de définir des stratégies de mot de passe par OU, ou encore des fonctionnalités pour Exchange 2010 et les versions à venir.

 

Pour cela, lancer la commande Active Directory Domain and Trusts. et faire un clic-droit sur la racine de la console, puis Raise Forest functional level.
Valider en cliquant sur Raise :

Cette opération va élever tous les domaines présents dans la forêt. Si cela n’est pas possible (s’il reste un contrôleur 2003 dans l’un des domaines par exemple), il est possible de n’augmenter qu’un domaine (en faisant un clic-droit sur le domaine, puis Raise…)

 

Conclusion

J’espère que cet article vous aura éclairci sur le processus de migration d’Active Directory vers 2008R2 ! J’essayerai par la suite de traiter d’autres sujets sur Active Directory, tels que l’organisation d’un annuaire, le traitement des stratégies de groupe, ou le nettoyage DNS.

par .

4 Commentaires

  1. LABIED dit :

    Bonjour
    j’ai lu ce formidable tutoriel et je le trouve proche de mes besoin.

    je travail actuellement sur mon projet de fin d’étude qui consiste à:

    1-migrer du windows server 2003 vers 2008
    2-migrer de l’Exchange 2003 vers 2010
    3-virtualisation

    ce je que je souhaite savoir est:

    * comment garder les 2 anciens serveur (où on a installé windows server 2003 et exchange 2003) et en meme temps virtualiser windows server 2008 et Exchange 2010 dans ces serveurs qu’on a.

    *une solution de sauvegarde pour prteger les données lors de la migration

    merci d’avance.

  2. David dit :

    Bonjour,
    Merci.

    Lors de ce type de migration, tu peux facilement conserver les anciens serveurs, puisque la migration n’est pas en « one shot ». Il te suffira de désinstaller Exchange ou Active Directory pour conserver le serveur si celui-ci héberge d’autres rôles, une fois tes migrations terminées.

    Dans l’ordre, le processus de migration pourrait être :
    – Installation Active Directory sous 2008 R2 (en machine virtuelle),
    – Installation d’Exchange 2010 (en machine virtuelle),
    – Migration des utilisateurs Exchange (transfert des boites aux lettres),
    – Retrait d’Exchange 2003,
    – Retrait des anciens contrôleurs 2003,
    – Virtualisation de l’ancien serveur Exchange 2003,
    – Virtualisation de l’ancien contrôleur de domaine 2003.

    La solution de sauvegarde peut être variée. Backup Exec offre une bonne protection Active Directory / Exchange, et permet des restaurations granulaires des objets.

    Si tu es dans un projet de virtualisation, tu pourrais également virtualiser (un P2V) tes anciens serveurs, pour qu’ils soient sauvegardés en temps que machine virtuelles (via Veeam par exemple).

    David.

  3. Letoine dit :

    Bonjour,
    J’ai parcouru le tuto en diagonal, je l’avoue et il me semble correct.
    Cependant, ce que je ne trouve dans aucun de ces tuto de migration AD 2Kx vers 2K8 (R2) c’est un outil de contrôle de la bonne réplication AD / DNS.
    La plupart du temps, tout se passe bien. Donc pas besoin de le vérifier.

    Mais parfois, plutôt que le principe d’attendre 24h, on souhaiterai déclencher les opérations manuellement (quitte à créé un arrêt de production) et être certain que la réplication est complète et à jour.

    Il m’est arrivé une fois que ça ne soit pas le cas et *patatra* :-/

    Je continue ma recherche à ce sujet 😀

    • David dit :

      Bonjour,

      Ce tutoriel (qui date un peu) n’est en effet pas très complet.

      Tu peux utiliser la commande repadmin /showrepl pour afficher l’état de ta réplication, depuis chaque nouveau contrôleur 2008 R2.

      Si la synchronisation n’est pas effectué, il faut consulter les logs d’événements et éventuellement forcer une réplication via la console Sites & Services.

      Pour plus d’informations :
      http://technet.microsoft.com/fr-fr/library/cc770963%28v=ws.10%29

Laisser un commentaire

*