Si j’ai installé un serveur 2003 (voir l’article précédent), ce n’est pas pur plaisir – quoique – mais car j’ai décidé de monter une maquette composée de deux contrôleurs de domaine en 2003 qui doivent être migré sous un OS plus récent, ici 2012 R2.
Dans cet article, je vais détailler les principales étapes pour mener à bien cette migration que j’ai réalisé en 2 temps, tout d’abord en migrant de 2003 vers 2008 R2, puis de 2008 R2 vers 2012 R2. Bien évidemment, avant de se lancer en production, valider la procédure sur un environnement de test me paraît indispensable ; tout comme valider ces quelques pré-requis : faire un dcdiag pour s’assurer qu’il n’y ait pas d’erreurs ou d’incohérences au niveau du domaine et être sûr de disposer de tous les mots de passe nécessaires aux promotions et dépromotions de contrôleurs de domaine. Je ne saurais être tenu responsable si vous appliquez ce procédé en production sur un environnement bancal et que ça coince quelque part sans que vous ayez de moyen de revenir en arrière !
Pour clarifier, j’ai nommé mon domaine maquette.local, et mes serveurs s’appelleront DCXXXPRI et DCXXXSEC.
Situation actuelle : 2 DC 2003 – DC2K3PRI et DC2K3SEC. C’est parti ! 💪
Tout d’abord, faire en sorte que le niveau fonctionnel de la forêt du domaine soit en 2003 : se rendre dans les consoles Active Directory Domains and Trusts et Active Directory Users and Computers pour faire les montées de version.
 |
||
| Le niveau fonctionnel de l’ActiveDirectory est en 2000 sur un domaine fraîchement configuré sur un 2003. |
Procéder à l’installation d’un serveur 2008 R2. Ce nouveau serveur sera mis sur le domaine et s’appellera DC2K8PRI. Une fois les rôles ADDS installés sur ce serveur, il est nécessaire de préparer la forêt pour recevoir un AD 2008.
Pour ce faire, monter l’ISO de Windows Server 2008 sur DC2K3PRI. Puis, ouvrir une invite de commande, se placer sur l’ISO (répertoire d:\support\adprep par défaut) et exécuter les instructions suivantes :
adprep32.exe /forestprep
adprep32.exe /domainprep
adprep32.exe /gpprep
adprep32.exe /rodcprep
La première instruction avec le paramètre forestprep demandera une confirmation en saisissant « c ».
 |
| adprep32.exe demande une confirmation lors de la demande de mise à niveau du schéma pour accueillir un DC 2008. |
 |
| Préparation du schéma en cours… |
 |
| Le domaine est prêt, il reste plus qu’à implémenter la nouvelle gestion des GPO et des RODC (Read-Only Domain Controller) si besoin. |
Une fois que tout s’est bien déroulé, retour sur DC2K8PRI. Exécuter dcpromo pour en faire un DC. Le serveur sera donc ajouté à la forêt existante, les autres paramètres ne doivent pas être modifiés et le serveur doit être ajouté comme un contrôleur de domaine supplémentaire.
 |
|
| On ajoute simplement un DC au domaine maquette.local. |
 |
|||
| On spécifie le compte d’administration à utiliser pour la promotion. |
 |
| La promotion est prête à être effectuée. |
Dès que l’assistant est terminé et le
serveur promu en DC avec succès, ce dernier redémarrera. Une fois le reboot
terminé, contrôler dans la console ActiveDirectory Users and Computers sa
présence dans l’OU Domain Controllers.
Se rendre sur DC2K3SEC, et effectuer un dcpromo.
 |
| Il ne faut surtout pas cocher cette case car nous souhaitons bien conserver le domaine ! |
seront supprimées en même temps que la dépromotion du serveur ; il n’est pas nécessaire d’en tenir
compte car elles ne seront plus utilisées par la suite. Une fois l’assistant terminé, le serveur va redémarrer, il ne
sera plus DC. Il ne reste plus qu’à lui retirer les rôles AD et à l’éteindre. Il nous reste donc 1 DC 2003 (master) et 1 DC 2008 R2.
transférer les rôles opérationnels de DC2K3PRI vers DC2K8PRI.
invite de commandes ou une invite Powershell et obtenir la confirmation que
c’est DC2K3PRI qui héberge les rôles opérationnels du domaine grâce à l’instruction netdom query fsmo :
 |
| Les rôles opérationnels sont bien portés par DC2K3PRI. |
 |
| Transfert du Naming Master |
Ensuite, ouvrir la console
ActiveDirectory Users and Computers et faire de même pour les rôles RID, PDC et
Infrastructure.
les 5 rôles, exécuter de nouveau la commande netdom query fsmo. Voici ce qui devrait
ressortir de l’instruction si tout s’est bien déroulé :
 |
||
| Le transfert s’est bien déroulé : tous les rôles ont basculé sur DC2K8PRI. |
été déplacés, il est envisageable de continuer. Maintenant que le DC maître est DC2K8PRI, installer un serveur
2008 R2 nommé DC2K8SEC. Le mettre sur le domaine, installer les rôles AD,
réaliser un dcpromo pour le déclarer contrôleur de domaine. Nous avons donc en l’état 1 DC 2003 et 2 DC 2008 R2 (dont un maître). Il nous reste plus qu’à retirer le dernier DC en 2003 pour que la première partie de la migration soit réalisée.
 |
| Il n’y a plus de trace des serveurs 2003 dans l’OU des contrôleurs de domaine. |
Si tout s’est bien déroulé jusqu’ici, il suffit de retirer le rôle AD sur le serveur 2003 et à l’éteindre pour conclure proprement cette première partie.
être nécessaire d’effectuer une montée de niveau fonctionnel de la forêt et du
domaine vers 2008 R2. Si besoin, répéter l’opération effectuée en début de
procédure pour monter de 2000 vers 2003 (ouvrir la console ActiveDirectory
Domains and Trusts, puis Raise forest functional level vers 2008, puis 2008
R2 ; ouvrir la console ActiveDirectory Users and Computers et monter le niveau
du domaine de la même manière).
 |
| Montée du niveau fonctionnel de la forêt en 2008. |
 |
| Forêt et domaine en niveau fonctionnel 2008 R2. |
Et c’est reparti pour une installation : un serveur 2012 R2, le mettre sur le domaine, y installer les rôles ADDS, et le promouvoir en contrôleur de domaine.
 |
| Installation des rôles ADDS |
 |
| Prêt pour l’installation. |
La promotion comme contrôleur de domaine se fait directement par le Server Manager, dcpromo n’existant plus en tant qu’application appelable par l’utilisateur. Il n’y a pas besoin d’effectuer un adprep avec 2012 R2 car c’est l’assistant qui va préparer le schéma. Lorsque l’assistant est terminé, le serveur redémarre, vérifier dans la console ActiveDirectory Users and Computers que DC2012PRI apparaît bien dans l’OU des DC. A ce moment, il y a 2 DC 2008 R2 (dont maître) et un DC 2012 R2.
Le transfert des rôles vers le nouveau DC en 2012 R2 s’effectue maintenant. Vérifier avec netdom query fsmo que DC2K8PRI est toujours porteur des rôles. Dans une invite de commande ou Powershell, saisir regsvr32 schmmgmt.dll puis ouvrir un mmc.exe et y ajouter la console ActiveDirectory Schema. Dans la console, s’assurer que l’on est bien connecté sur DC2012PRI.
 |
|
| Bien sélectionner DC2012PRI afin de le désigner comme nouveau maître du schéma. |
Ensuite réaliser l’opération de transfert des rôles, de la même manière qu’effectuée sur le 2003 (Operation Masters puis Change). Ouvrir les consoles ActiveDirectory Domains and Trusts et ActiveDirectory Users and Computers pour y réaliser le transfert des rôles de naming, RID, PDC et Infrastructure. Vérifier que le transfert a bien été appliqué :
 |
| DC2012PRI est le nouveau serveur « maître » du domaine. |
Maintenant que le DC primaire est DC2012PRI, installer un serveur 2012 R2 nommé DC2012SEC. Le mettre sur le domaine, installer les rôles AD, réaliser un dcpromo pour le définir contrôleur de domaine et le définir contrôleur de domaine avec l’assistant. Si tout s’est bien déroulé jusqu’alors, il y a 3 DC : 1 2008 R2 et 2 2012 R2 (dont le maître).
Tous les rôles étant sur DC2012PRI et DC2012SEC étant fonctionnel, exécuter dcpromo sur DC2K8PRI, le dépromouvoir, puis supprimer les rôles ADDS, et procéder à l’extinction du serveur.
 |
| DC2K8PRI n’est plus que l’ombre de ce qu’il fut pendant quelques heures… |
Enfin, nous avons 2 DC en 2012 R2. Afin de vérifier que tout s’est bien déroulé, réaliser un dcdiag et s’assurer que tous les tests sont concluants – pass :
dcdiag /v /c /d /e /s:DC2012PRI
 |
|
| Les tests sont complets et si tout s’est bien déroulé du début à la fin, ils doivent tous être passés avec succès. |
Pour conclure, il ne reste plus qu’à reconfigurer la synchronisation du temps sur le contrôleur de domaine hébergeant le rôle PDCEmulator afin d’être sûr qu’il se synchronise sur une source de temps valide et qu’il ne conserve pas une référence caduque suite aux migrations. Dans cet exemple, je prends le serveur de temps Microsoft mais il peut s’agir d’un serveur en interne.
w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update