Migration des contrôleurs de domaine Active Directory vers Windows 2008 R2 -> 11 retours d’expériences

Salut à tous

J’ai récemment travaillé sur plusieurs projets de migration des contrôleurs de domaine Active Directory Windows 2003 Server vers Windows 2008 R2.
Cet article a pour but de vous présenter 10 retours d’expériences sur cette migration.

PROCÉDURE DE MIGRATION :
Pour rappel, la procédure de migration / remplacement des contrôleurs de domaine Windows Server 2003 par des contrôleurs de domaine Windows Server 2008 R2 est la suivante :
– Préparation du schéma (ajout nouveaux attributs / nouvelles classes…) : ADPREP /FORESTPREP
– Préparation du domaine : ADPREP /DOMAINPREP /GPPREP et ADPREP/RODCPREP
– Installation des nouvelles machines et DCPROMO pour ajouter ces machines en tant que contrôleurs de domaine dans un domaine existant.
– Migration des rôles FSMO / reprise des anciennes IP / migration des services réseaux.
– Suppression des anciens contrôleurs de domaine Windows Server 2003.
Et entre chaque étape / DCPROMO, une bonne sauvegarde de tous les contrôleurs de domaine avec votre outil de sauvegarde et l’outil de sauvegarde natif Microsoft (NTBACKUP / Windows Server Backup selon version). Toujours utiliser deux outils de sauvegarde pour l’annuaire. C’est trop critique !

Microsoft met à disposition sur Internet une procédure complète pour migrer ses contrôleurs de domaine vers Windows 2008 R2. Il y a aussi d’autres retours d’expériences dans ce document:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=fa629de2-f4dd-47ac-8d80-3db46b2877a2

Retour d’expérience 1 : Tester sa procédure de migration.
Pour cela, l’idéale est de dupliquer un contrôleur de domaine et de restaurer les services et applications qui s’appuient sur l’annuaire (EXchange / Office Communication Server / applications métiers) le tout dans un environnement de tests totalement isolé au niveau réseau.
Pour rappel avec Exchange, on peut restaurer un serveur en faisant setup /m:recoverser.
J’ai déjà abordé en détail ce point dans l’article suivant :

Migration AD 2003 / Exchange 2003 vers AD 2008 / Exchange 2007 -> Comment tester et valider le processus de migration

Retour d’expérience 2 : Propager les modifications du schéma progressivement.
Les mises à jour du schéma sont presque irréversibles (on peut désactiver les attributs mais bon).
En gros, on a pas trop le droit à l’erreur surtout quand on a 300 contrôleurs de domaine répartis dans le monde. Donc l’idée est de valider et de propager progressivement les modifications de schéma.
Voici la méthodologie que je préconise.
Quelques jours avant la mise à jour du schéma (le temps que tout réplique) :
– Créer un site dédié pour la phase de mise à jour de schéma :
– Déplacer 2 / 3 contrôleurs de domaine dans ce site (des machines virtuelles feront l’affaire).
– Configurer un lien de site pour que la réplication soit désactivée (on interdit la réplication à tout heure)
Avant de lancer la mise à jour du schéma, désactiver la réplication entrante et sortante sur le maître de schéma en tapant les commandes :
repadmin /options +DISABLE_OUTBOUND_REPL
repadmin /options +DISABLE_INBOUND_REPL

Une fois que la mise à jour du schéma est terminée, réactiver la réplication entrante / sortante sur le maître de schéma en tapant les commandes suivantes :
repadmin /options -DISABLE_OUTBOUND_REPL
repadmin /options -DISABLE_INBOUND_REPL

Les modifications sont propagées aux contrôleurs de domaine du site de TEST. Cela permet de valider que la réplication fonctionne toujours bien.
En cas de problème, c’est DCPROMO /FORCEREMOVAL et NTDSUTIL SEIZE ROLES pour transférer le rôle FSMO Maître de schéma et NTDSUTIL METADATA CLEANUP pour supprimer complètements les enregistrements du ou des contrôleurs de domaine de l’annuaire.

Retour d’expérience 3 : Incompatibilité entre le schéma Office Communication Server (OCS) et ADPREP /FORESTPREP :
Il y a un conflit entre le schéma Office Communication Server (OCS) et l’ADPREP WINDOWS 2008 R2.
Suite à l’ADPREP /FORESPREP, les services OCS ne redémarrent plus ! Rien que ça.
Pour plus d’informations : http://support.microsoft.com/kb/982020

Retour d’expérience 4 : ADPREP /FORESTPREP depuis le maître de schéma et antivirus désactivé.
On fait l’ADPREP /FORESTPREP sur le contrôleur de domaine qui joue le rôle de maître de schéma.
Penser à couper votre antivirus temps réel / détection de comportement. Cela évitera que l’injection LDIF soit considérée comme une attaque. J’ai déjà eu cette erreur lors d’un ADPREP /FORESTPREP chez un client (heureusement que c’était sur la maquette).

Retour d’expérience 5 : Échec ADPREP /RODCPREP :
ADPREP /RODCPREP peut échouer si vous avez forcer le transfert du rôle “Maître d’infrastructure” suite à la perte du contrôleur de domaine hébergeant ce rôle même si vous avez fait un NTDSUTIL METADATA CLEANUP.
Pour plus d’informations, voir http://support.microsoft.com/kb/949257/en-us
Le script ne marche pas forcément. Donc souvent je fais la modification directement avec ADSIEDIT. Il faut savoir saisir un schéma LDAP.

Retour d’expérience 6 : Problème avec les outils de migration ADMT / Quest Migration Manager suite à un ADPREP /RODCPREP :
Suite au passage de la commande adprep /rodcprep, il n’est plus possible de migrer une station de travail d’un domaine d’une autre forêt vers la forêt Windows 2008 R2.
Le message suivant apparaît :
ERR3:7075 Failed to change domain affiliation, hr=800704f1
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Deux solutions :
– Déployer le patch sur toutes les stations de travail à migrer pour la prise en charge des RODC : http://support.microsoft.com/kb/944043/en-us
– Abaisser le niveau de sécurité du domaine : http://support.microsoft.com/kb/942564
Pour plus d’informations :
http://jaxtech.blogspot.com/2010/05/admt-failed-to-change-domain.html
http://blogs.technet.com/askds/archive/2009/10/19/admt-rodc-s-and-error-800704f1.aspx
Remarque :
Le patch http://support.microsoft.com/kb/944043/en-us doit être déployé sur tous les Windows antérieurs à 2008 / Vista pour une prise en charge correcte des RODC.

Retour d’expérience 7 : plus de déploiement des logiciels via NETLOGON / SYSVOL :
Lorsque que l’on essaie d’installer un logiciel via le partage NETLOGON, on a l’erreur suivante (même si on est logué avec un compte administrateur du domaine) :
“The installation package could not be opened”
Si on copie l’exécutable en local sur c:\ par exemple, cela fonctionne.
Ce problème ne se pose pas si on essaie d’installer le logiciel depuis un contrôleur de domaine antérieur à Windows Server 2008 R2.
Si on active les logs de Windows Installer (http://support.microsoft.com/kb/314852), on voit l’erreur 1619.
=== Verbose logging started: 04/10/2010  19:08:26  Build type: SHIP UNICODE 3.01.4001.5512  Calling process: C:\WINDOWS\System32\msiexec.exe ===
MSI (c) (40:E4) [19:08:26:269]: Resetting cached policy values
MSI (c) (40:E4) [19:08:26:269]: Machine policy value ‘Debug’ is 0
MSI (c) (40:E4) [19:08:26:269]: ******* RunEngine:
******* Product: \\formation10.lan\NETLOGON\install_flash_player_10.1.53.64_plugin.msi
******* Action:
******* CommandLine: **********
MSI (c) (40:E4) [19:08:26:269]: Note: 1: 2203 2: \\formation10.lan\NETLOGON\install_flash_player_10.1.53.64_plugin.msi 3: -2147287035
MSI (c) (40:E4) [19:08:26:269]: MainEngineThread is returning 1619
=== Verbose logging stopped: 04/10/2010  19:08:26 ===

Le problème provient du fait qu’on ne peut plus faire un accès exclusif sur le partage NETLOGON avec Windows 2008 R2. On ne peut donc plus utiliser NETLOGON comme emplacement pour déployer des logiciels. Il faut utiliser un partage réseau classique ou une cible DFS.
Ce problème se posait déjà avec SYSVOL et les contrôleurs de domaine Windows 2003.
http://support.microsoft.com/kb/889710
Pour plus d’informations sur le déploiement des applications via GPO\Configuration Ordinateur :
http://forums.techarena.in/active-directory/914815.htm

Retour d’expérience 8 : Plus possible de se loguer en Citrix suite à la mise à jour des contrôleurs de domaine vers Windows Server 2008 R2 :
Suite à la migration des contrôleurs de domaine vers Windows 2008 R2, les utilisateurs ne peuvent plus se connecter à Citrix. Le serveur Terminal Server n’arrive plus à émettre de licences Terminal Server par utilisateur.
Avec des contrôleurs de domaine Windows 2008 R2, il y a de nouveaux attributs au niveau du compte utilisateur qui sont utilisés par le groupe “Serveur de licence terminal Server”. Hors ce dernier n’a pas le droit d’écrire dans ces attributs pour des comptes créés avant la migration. Pas de problème avec les comptes créés après la migration. Pour plus d’informations, se référer à l’article suivant :
http://msreport.free.fr/?p=190
http://support.microsoft.com/kb/2030310

Retour d’expérience 9 : Rappelez vous que Windows Server 2008 R2 n’existe qu’en version 64 bits.

Si vous avez des machines virtuelles Vmware ESX, rappelez vous que vous avez besoin d’IntelVT pour activer la possibilité de créer des machines virtuelles 64 bits avec des processeurs Intel.

Retour d’expérience 10 : Quelques changements dans les outils de sauvegarde :
Attention, la taille d’une sauvegarde du système State avec Windows 2008 R2 est de 7 Go.
En effet le SYSTEMSTATE sous Windows 2008 / Windows 2008 R2 intègre un élément qui s’appelle le SYSTEMFILE qui recopie la majorité des fichiers de c:\windows\system32.
Pour rappel, Windows Server backup ne sait pas faire de sauvegarde sur lecteur LTO4. Par contre il sait faire de la déduplication.

Retour d’expérience 11 : Les quelques réglages à faire sur Windows Server 2008 R2 :
Les stations de travail Windows Vista / Seven / 2008 / 2008 R2 ne permettent plus le déploiement d’un logiciel via un partage accessible par les utilisateurs anonymes. Pour plus d’informations :
http://support.microsoft.com/kb/2022222
http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm
Attention si les DC sont aussi serveurs d’impression, on a des problèmes pour mapper les imprimantes quand on utilise un alias DNS pour se connecter au serveur d’impression. Pour plus d’informations :

Problèmes alias DNS et imprimantes sous Windows 2008 R2 -> Operation could not be completed (error 0x00000709)


Attention l’UAC peut bloquer l’exécution de certains scripts.
Le pare feu peut générer des problèmes avec les profils itinérants (la désactivation du pare feu sur un contrôleur de domaine Windows 2008 Server avait corrigé le problème de chargement d’un profil itinérant.
Pour utiliser les GPO de préférence, il faut déployer le patch KB 943729 sur les stations Windows XP / 2003 / Vista. Pour plus d’informations :

Windows Server 2008 GPO de préférence -> il faut mettre à jour Windows XP Pro et Windows Vista !

A+
Guillaume MATHIEU
Le bonheur, c’est le partage.

A propos Guillaume Mathieu

Directeur Technique chez Flexsi
Ce contenu a été publié dans Active Directory, ADMT, Annuaire, Bug, Migration, Scripts, Troubleshouting, Windows Server 2008 R2, avec comme mot(s)-clé(s) , , , , , , , . Vous pouvez le mettre en favoris avec ce permalien.

3 réponses à Migration des contrôleurs de domaine Active Directory vers Windows 2008 R2 -> 11 retours d’expériences

  1. boby dit :

    Bonjour,

    Dans le cadre de mon stage en deuxième année en informatique je dois migrer un domaine WDS 2003 sp2 ( 1AD ) en WDS 2008 R2 ( 2 AD dont le deuxième serait en back Up). Je decouvre la notion de réseau, c’est dans ce contexte que je vous demande de l’aide. Pourriez vous m’aider a accomplir cette tache par n’importe quel moyen via un tutoriel ou une procédure.

    En vous remerciant d’avance

  2. Un passant dit :

    “Plus de déploiement des logiciels via NETLOGON / SYSVOL

    Cela n’est pas un “problème” c’est une volonté, le SYSVOL n’est pas fait pour déployer des logiciels, ni d’ailleurs pour répliquer des mp3,avi, ….. ou autre fichier non lié à l’AD.
    le sysvol doit uniquement contenir les Policies et les script de logon/logoff.

  3. Oui en effet pour rappel, SYSVOL ne doit pas faire plus de 2 Go (Best Practice Microsoft).
    La mise en place d’un Central Store (fichiers ADMX) permet justement de réduire la taille du répertoire Policies.

Laisser un commentaire