Conseils pour la migration Active Directory vers WS 2012 R2

I. Présentation

Cet article a pour objectif de mentionner les bonnes pratiques à suivre lorsque l’on souhaite migrer un environnement Active Directory vers Windows Server 2012 R2.

Ceci vous permettra de préparer votre migration dans les meilleures conditions possibles. Une migration est un projet à part entière, il faut veiller à bien tout préparer.

La procédure de migration complète ne sera pas décrite entièrement, il s’agit plutôt de conseils, de méthodes à utiliser, pour réaliser la migration dans les meilleures conditions.

Tout d’abord, migrer présente plusieurs avantages :

- Bénéficier du support de l’OS par Microsoft. Concernant Windows Server 2003, le support termine Juillet 2015).

- Passer à la virtualisation puisque Windows Server 2012 R2 gère très bien cette technologique, ainsi vous pourrez profiter des avantages d’une telle installation.

- Profiter des nouvelles fonctionnalités.

II. Prérequis matériel

Commençons par parler du serveur en lui-même. Il doit être certifié fonctionnel avec Windows Server 2012/2012 R2, ce qui peut se vérifier par la présence d’une étiquette sur le serveur.

adbest0

Au niveau des attributions des ressources matérielles, Microsoft recommande 32 Go d’espace disque dur et 2 Go de RAM pour le serveur. Cependant les experts Active Directory de chez Microsoft recommandent plutôt 80 Go pour le disque dur et 8 Go de RAM.

Bien entendu, le processeur doit être compatible 64 bits puisque Windows Server 2012/2012 R2 est disponible exclusivement en version x64.

Si vous partez sur de la virtualisation, sachez qu’à partir de Windows Server 2012, il est possible de cloner un contrôleur de domaine à condition que l’hyperviseur gère le « VM-generationID ». Ce qui est le cas des dernières versions d’Hyper-V et de VMware.

III. Les différentes étapes

Un projet de migration d’Active Directory devrait se découper en 4 grandes étapes :

adbest0b

IV. Evaluation – Les bloqueurs potentiels

Il est important d'évaluer l'infrastructure actuelle avant d'envisager la migration, ceci dans le but d'identifier les bloqueurs potentiels. Ces bloqueurs n’empêcherons pas la migration mais pourront poser des problèmes suite à la migration. Il vaut mieux les identifier au préalable.

En général, tous les bloqueurs identifiés peuvent être contournés en paramétrant une GPO contenant certains paramètres spécifiques pour assurer la rétrocompatibilité.

A. Le chiffrement des comptes

Depuis Windows Server 2008 R2, le chiffrement DES/3DES des utilisateurs est désactivé par défaut. Si vous migrez depuis Windows Server 2000, 2003 ou 2003 R2 vous devez prendre cela en considération puisque ces OS utilisent le DES par défaut.

D’ailleurs, dans les options d’un compte, vous pouvez vérifier cela si l’option « Utiliser le chiffrement DES pour ce compte » est active ou non. Sinon, pour aller plus vite vous pouvez utiliser cette commande PowerShell sur votre annuaire :

Get-ADUser -filter * -Properties UserAccountControl | Where{($_.useraccountcontrol -band 2097152) -ne 0}

Ou

dsquery * -filter "(UserAccountControl:1.2.840.113556.1.4.804 :=2097152)"

Si vous souhaitez réactiver le DES sur vos nouveaux contrôleurs de domaine, vous devez configurer ce paramètre de stratégies de groupe :

Paramètres Windows, Paramètres de sécurité > Stratégies locales > Options de sécurité > Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos

Le chiffrement peut avoir un impact sur certaines applications codées en dur pour utiliser le DES ou 3DES, ce qui peut être le cas de certaines applications Java.

B. Compression des SIDs

Depuis Windows Server 2012, une nouvelle fonctionnalité permettant de compresser les SIDs est présente, et, activée par défaut. Cette compression permet de réduire la taille des tokens utilisés par Kerberos.

Certaines implémentations de Kerberos, comme ça peut être le cas sur des NAS ou Linux, ne supportent pas cette compression. Ainsi, cela peut poser des problèmes de compatibilité donc d’authentification.

Deux solutions :

- Désactiver la compression de SID uniquement pour le NAS, c’est-à-dire pour le compte utilisé par cette ressource.
- Désactiver la compression de SID sur l’ensemble de l’environnement. Attention cela requiert un redémarrage du contrôleur de domaine. Concernant le paramètre à modifier :

REG_DWORD : DisableResourceGroupsFields=1
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters

V. Evaluation – Ce qu’il faut évaluer

Voici quelques points important à prendre en compte lors de l’évaluation de votre infrastructure Active Directory.

- Vérifier la compatibilité des applications avec le système d’exploitation vers lequel vous migrez.

- Effectuer un inventaire des rôles et services installés sur les contrôleurs de domaine afin de déterminer s’ils doivent être réinstallés sur le nouveau serveur, rester sur le serveur actuel ou être assurés par un serveur différent. Il faut donc inclure la migration de ces services au projet de migration.

- Effectuer un état de santé de l’Active Directory.

VI. Commandes pour vérifier l’état de santé

Le dernier point cité précédemment mérite d’être détaillé car c’est un point incontournable dans l’évaluation de l’infrastructure en préparation à la migration.

A. Réplication de l’Active Directory

Afin de vérifier l’état de réplication de l’AD, on peut utiliser différentes commandes :

repadmin /replsummary : Déclenchera une collecte de données afin d’afficher un résumé de la réplication au niveau de la forêt.

repadmin /showrepl : Sur chaque DC, l’exécution de cette commande permet d’afficher l’état de la réplication lorsque le DC a tenté une réplication entrante pour la dernière fois.

Active Directory Replication Status Tool : Utilitaire disponible sur le site de Microsoft (Téléchargement), cet outil pratique et efficace permet de contrôler l’état de la réplication de l’ensemble des partitions de la forêt. Suite à une analyse, les erreurs trouvées vous seront indiquées.

Aperçu de Active Directory Replication Status Tool
Aperçu de l'application "Active Directory Replication Status Tool"

B. Réplication du SYSVOL

La réplication du SYSVOL peut être effectuée avec FRS ou DFSR, selon la version de Windows sous laquelle vous êtes et si vous avez déjà migré ou non le FRS vers DFSR.

Ultrasound : Cet outil fournit par Microsoft (Téléchargement) permet de surveiller et de dépanner la réplication via FRS

Sonar : Egalement pour FRS mais réservé aux systèmes d’exploitations Windows Server 2000 et 2003 (Téléchargement)

DFSRMon : Cet utilitaire permet de contrôler l’état de la réplication SYSVOL via DFSR sur votre domaine (Téléchargement)

C. La résolution de noms avec DNS

Le DNS est un élément indispensable dans un environnement Active Directory, il est important de vérifier qu’il soit en bonne santé lui aussi.

dcdiag /test:dns : Diagnostic du DNS concernant les enregistrements liés à l’Active Directory

Vous pouvez utiliser également l’utilitaire dnslint mais qui n’est pas présent sur toutes les versions de Windows. Par ailleurs, des tests de résolutions avec nslookup basiques peuvent être effectués en complément.

D. La base NTDS.dit

Ce fichier correspond à l’annuaire Active Directory, il en contient toutes les données. Il est préférable de vérifier l’état général de l’AD, pour cela l’Observateur d’événements doit être contrôlé afin de vérifier la présence éventuelle de messages d’erreurs.

Si vous migrez depuis Windows Server 2008 R2, vous devriez également faire une analyse avec le Best Pratices Analyzer qui peut vous remonter d’éventuels problèmes de configuration détectés.

La sauvegarde de l’état du système Active Directory

Comme vous sauvegardez régulièrement votre système (notamment capture instantanée de l’AD), vérifiez que vous disposez d’une sauvegarde grâce à la commande suivante :

repadmin /showbackup

Sans préciser de DC, la valeur localhost sera automatiquement ajoutée à la commande.

repadmin /showbackup
Exemple de résultat de la commande "repadmin /showbackup"

E. Les rôles FSMO

Utilisez la commande indiquée ci-dessous pour vérifier quel DC est maître d’opération pour chacun des rôles FSMO.

netdom query fsmo
adbest3
Résultat de la commande "netdom query fsmo"

F. La synchronisation NTP

Vous pouvez vérifier l’état de la synchronisation NTP de votre contrôleur de domaine en utilisant cette commande :

w32tm /query /status
w32tm /query /status
Résultat de la commande "w32tm /query /status"

Pour conclure sur cette partie, j’ajouterais que si vous avez des problèmes sur votre infrastructure actuelle, la migration ne les résoudra pas. C’est pourquoi il est intéressant d’effectuer tous ces tests au préalable afin de bien évaluer l’état actuel de votre infrastructure.

VII. Planifier la migration

A. L’architecture

Vous devez prévoir votre future architecture, il est important de déterminer une architecture de migration : Combien vais-je avoir de contrôleurs de domaine ? Vais-je avoir des contrôleurs de domaine en lecture seule ? Les DCs seront-ils virtualisés ? Etc.

Les réponses à ces questions vont vous permettre d’éviter certaines interrogations de dernières minutes, et, cela permettra de valider au préalable vos choix.

Vous devez également intégrer dans l’architecture les applications à tester, et, les autres rôles que doivent jouer vos serveurs afin de savoir quels serveurs les hébergeront.

B. Le retour arrière

C’est « triste à dire » mais vous devez préparer le retour arrière au cas où la migration ne se passerait pas du tout comme prévu… Pour cela prévoyez :

- Une sauvegarde l’Active Directory (Etat du système et Système)
- Une sauvegarde complète de votre disque avec une solution adéquat
- Une sauvegarde de la machine virtuelle (dans le cas de DC virtualisé)

Note : Pour la sauvegarde de l’état du système vous pouvez utiliser l’outil de sauvegarde fournit avec Windows Server.

De plus, il est préférable d’avoir :

- Un PRA de la restauration totale de la forêt (Plan de Reprise d’Activité)

- Prévoir une « Forest Recovery » qui pourrait être nécessaire dans certains cas (Exemples : Impossible d'ajouter un nouveau contrôleur de domaine, impossible de faire fonctionner la réplication entre les partenaires, compromission de l'environnement Active Directory, etc.)

VIII. Tester - Environnement de tests

Tester, tester et encore tester ! Pour préparer au mieux la migration, effectuez des tests sur un environnement complètement isolé de la production. Pensez à supprimer cet environnement à la fin des tests pour éviter toute communication avec l’environnement en production à l’avenir.

La méthode que je vous recommande pour la création d’un environnement de test est la suivante :

Restaurer la sauvegarde complète d’un contrôleur de domaine directement sur une machine physique ou au sein d’une machine virtuelle.

adbest5

Une autre solution consisterait à ajouter un nouveau contrôleur de domaine à l’environnement de production, puis, à l’isoler dans un environnement de tests afin de le rendre autonome. On s’appuie réellement sur la production pour créer l’environnement de tests mais on ne vérifie pas l’état de la sauvegarde. De plus, il faudra réaliser un « metadata cleanup » sur les contrôleurs de domaine de production pour qu’ils « oublient » le DC dédié aux tests.

IX. Déployer – Préparer la migration

Etape décisive, le déploiement ! Cette partie référence quelques conseils et étapes intéressantes à suivre pour procéder à la migration et faire d’elle une réussite.

Le point suivante explique un début possible pour une migration, ensuite, une suite d’étape possible sera établie ce qui sera peut-être plus intéressant pour vous.

A. Bloquer la réplication

Il est possible de bloquer la réplication sortante sur un contrôleur de domaine, ceci dans le but d’effectuer des opérations de migration dessus sans affecter les autres contrôleurs de domaine tout le temps que la validation n’est pas effectuée.

Dans le cadre d’un environnement à 2 contrôleurs de domaine, sur le DC principal, empêcher la réplication sortante du schéma dans le but de vérifier qu’elle soit bien effectuée localement. Pour cela on utilise la commande suivante :

repadmin /options dc1 +disable_outbound_repl

On peut vérifier la prise en compte de cette option avec la commande suivante :

repadmin /showrepl

Dans le cas d’un environnement plus conséquent, c’est-à-dire où il y a plus de 2 DCs. Choisir un second DC et désactivez la réplication sortante sur ce dernier, puis, depuis le DC principal initier une réplication manuelle pour vérifier la réplication des objets et des attributs.

B. Vérifier le mode fonctionnel de la forêt

Exécutez la commande Adprep /forestprep sur le contrôleur de domaine. Attention, si vous êtes sur Windows Server 2003 la commande ne pourra pas être effectuée pour une mise à jour vers 2012/2012 R2, vous devez passer par un intermédiaire sous 2008 R2 (adprep n’existe plus sur 2012).

Il est à noter que le fait de migrer vers 2012 R2 implique que le schéma passera en version 69, ceci peut se vérifier dans l’attribut « ObjectVersion » du schéma. Par exemple, en étant sous 2003 la valeur passera de 31 à 69 mais par contre comme on a désactivé la réplication sortante les autres DCs ne seront pas affectés pour le moment. Cela offre un point d’assurance supplémentaire dans le cas où l’on souhaite revenir en arrière en cas de problème.

Vérifier s’il y a des problèmes… Si tout est OK on peut ouvrir à nouveau la réplication vers les autres DC mais avant cela on fait une réplication manuelle :

repadmin /replicate dc2 dc1 cn=schema,cn=configuration,dc=it-connect,dc=fr /force

On obtient le résultat : Sync from DC1 to DC2 completed successfully

Suite à la réplication, l’attribut ObjectVersion doit être passé également à 69 sur le second contrôleur de domaine.

Dans le cas d’un environnement très grand, il est intéressant de créer un script PowerShell pour vérifier la valeur de certains attributs de façon automatique. Vous gagnerez du temps, beaucoup de temps.

Enfin, on réactive en automatique la réplication sur le DC « principal » (- à la place de +) :

repadmin /options dc1 -disable_outbound_repl

Afin de forcer la réplication des DCs on utilisera la commande suivante :

repadmin /syncall /e

Cette procédure permet de vérifier la mise à jour du schéma locale sur le maitre de schéma et la mise à jour du schéma via une réplication sur le partenaire.

C. Les étapes du déploiement du premier contrôleur de domaine

Voici les étapes qui peuvent être suivies pour déployer le premier contrôleur de domaine sous Windows Server 2012/2012 R2 au sein de votre environnement.

- Préparer et appliquer la stratégie de groupe (GPO) qui permettra d’assurer la compatibilité entre votre environnement actuel et votre futur environnement. Configurez la stratégie de groupe en adéquation avec les résultats de vos tests.

- Installation du rôle Active Directory Domain Services (ADDS) et promotion en tant que contrôleur de domaine via le Gestionnaire de serveur (dcpromo n’existe plus). Pour promouvoir le premier contrôleur de domaine sous Windows Server 2012/2012 R2, le niveau fonctionnel de la forêt doit être au minimum « Windows Server 2003 ».

- Vérifier l’état de santé de votre infrastructure suite à la promotion du nouveau DC (réplication, DNS, numéro de version du schéma, vérifier les journaux, etc.)

- Vérifier et valider le bon fonctionnement de l’authentification

- Vérifier et valider le bon fonctionnement des applications tierces

- Sauvegardez votre contrôleur de domaine et votre annuaire avec NTDSutil
Ces étapes peuvent être répétées pour chacun des contrôleurs de domaine à intégrer.

D. Les étapes de la finalisation du déploiement

Avec nostalgie, vous devez rétrograder vos anciens contrôleurs de domaine, ils ont fait leur temps !

Remarque : Une fois tous les nouveaux DCs promus sous 2012/2012 R2, il est déconseillé de rétrograder les anciens DCs tous en même temps. Il vaut mieux en laisser un ancien actif le temps de finaliser la phase de transition, notamment si certaines applications continuent d’aller aléatoirement vers l’ancien DC et continue de fonctionner grâce au fait que l’ancien DC soit toujours présent. Pour vérifier vers quel contrôleur de domaine pointe une application pour l’authentification, utilisez un outil d’analyse réseau.

- Rétrograder les anciens DCs

- Augmenter le niveau fonctionnel du domaine et de la forêt

- Vérifier le bon fonctionnement des applications

- Activer et exploitez les nouvelles fonctionnalités. Par exemple : migrer la réplication SYSVOL de FRS vers DFSR, authentification plus forte (Authentication Mechanism Assurance), ADMX à la place des ADM, etc.

- Mettre à jour les différentes procédures concernant votre environnement, notamment le PRA

X. Liens utiles

Ci-dessous se trouvent une liste de liens contenant des informations utiles et pouvant vous aider dans votre migration !

Windows Server 2012 – Best Practice Analyzer

Windows Server : Capture instantanée de l’Active Directory

Apprivoiser les services Active Directory

Configurer le NTP avec w32tm

ADMX Migrator : Convertir les ADM en ADMX

Ajouter un contrôleur Windows Server 2012 dans un domaine existant

Configuration requise pour Windows Server 2012 R2

Les niveaux fonctionnels Active Directory

Authentication Mechanism Assurance for AD DS

Aide sur Repadmin

Compression des SIDs sous Windows Server 2012

Meta data cleanup

Je conclurais en disant qu’il faut faire de nombreux tests, bien évaluer son infrastructure et très bien se documenter pour éviter les surprises lors de la migration d’un Active Directory.

Vous aussi donnez vos conseils en laissant un commentaire sur cet article et donnez votre avis sur ce dernier !

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Florian B.

Co-Fondateur d'IT-Connect, je souhaite partager mes connaissances et expériences avec vous, et comme la veille techno' est importante je partage aussi des actus.

florian has 1967 posts and counting.See all posts by florian

11 pensées sur “Conseils pour la migration Active Directory vers WS 2012 R2

  • Billet complet 🙂 Dommage que 2012 soit une véritable usine à gaz si on le compare à 2008 (2003 je n’en parle même pas) ^^

    Répondre
  • Merci Florian pour cette synthèse intéressante.

    Répondre
  • Bonjour, je suis en phase de test pour migrer de 2003 à 2012 R2. Comment réagit exchange 2010 avec la migration? Le temps que le 2003 soit rétrogradé. Merci d’avance!

    Répondre
  • Dois-je désactiver la compression des SSID avant de promouvoir le server 2012???
    Sachant que je suis en environnement 2003 et qu’il n’y pas de compression des ssid.

    Répondre
    • Non ce n’est pas utile, après je ne connais pas ton environnement… Est-ce qu’il y a des NAS ou des applis Linux spécifiques qui s’appuient sur l’annuaire pour l’authentification ?

      Répondre
  • Alors! Merci pour ce billet, effectivement complet. Tous c’est bien passé.

    J’avais une crainte c’était d’augmenté le shema de la foret en 2008 sans avoir de serveur 2008. Je migrais à partir du 2003. Mais tout c’est bien passé.

    Seule exception: Les windows XP Embeded sur nos stations HP se sont désynchronisés de l’heure. C’est a dire qu’après le changement de PDC, elles se sont remis à l’heure de leur Bios.
    Les utilisateurs ne pouvaient plus ouvrir leur session à cause de ce décalage de temps trop important.

    Donc je les ai remis à l’heure approximativement en me loguant en local. Ensuite les stations ce sont bien synchronisées après les ouvertures de sessions. J’ai vérifié avec « w32tm /query /status ».

    J’ajoute aussi cette indication, si vous prés-voyer de virtualiser un DC, n’oublier pas de désactive les syncho de temps dans les options VMwres tools.

    J’ai encore une erreur aussi quand je configure le failover DHCP, a suivre.
    Je n’ai pas encore activé le DFS.

    Et pour répondre à Florian, mon NAS ne s’appuyant pas sur l’annuaire ad, je n’ai pas désactive la compression du ssid et je n’ai pas eu de problème de ce coté la.

    Répondre
  • Doc très bien fait. Merci pour votre générosité et pour votre sens de la pédagogie.
    Je fais des extensions de schémas depuis un moment selon une méthode similaire. J’ai réalisé une extension de schéma de 2003 à 212R2 en isolant un DC par domaine en cas de besoin de fail back. J’ai aussi isolé le schéma Master pour l’opération. Après le /forestprep. J’ai ouvert la repli sur le schema master seul et attendu que le nouveau schéma soit diffusé dans toute la foret à l’exception des DC ou la repli est désactivée. A ma grande surprise j’ai découvert que l’ojectversion est passé à 69 partout y compris dans les DC ou la réplication est toujours désactivée. Comme cela a-t-il pu se produire ? Merci.

    Répondre
  • Petite coquille « Choisir un second DC est désactivez la réplication sortante sur ce dernier » => « et » et non pas « est »

    Répondre
  • Bonjour,
    Dans mon cas : j’ai un DC sous 2003 avec AD/DNS, je comptais faire comme cela ;
    – Ajout de mon Serveur 2012 ou Serveur 2016 (je n’ai pas choisi) dans le domaine
    – Augmenter le niveau fonctionnel de mon 2003 au niveau de la foret en mode 2003
    – Ajout du serveur 2012 ou 2016 en tant que DC
    – Forcer la réplication
    -Bascule des rôles FSMO
    – Je demote le DC 2003

    Je ne comprends pas vos phases ave les /adprep

    Pouvez vous m’en dire plus ?
    Concernant les GPO je peux les copier d’un 2003 vers 2012 ?

    Par avance merci.

    Répondre

Répondre à Florian BURNEL Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

 

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.