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 :
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:WINDOWSSystem32msiexec.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.lanNETLOGONinstall_flash_player_10.1.53.64_plugin.msi
******* Action:
******* CommandLine: **********
MSI (c) (40:E4) [19:08:26:269]: Note: 1: 2203 2: \formation10.lanNETLOGONinstall_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 GPOConfiguration 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:windowssystem32.
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 :
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
Architecte Metsys
La connaissance s’accroît quand on la partage.
