Dans cet article nous allons voir la mise à jour d’un schéma Active Directory dans un environnement à plusieurs sites. Nous parlerons des problèmes liés à la latence de réplication ainsi que de quelques bonnes pratiques.
Je vous conseille de suivre le Webcast ci-dessous présenté lors des Tehdays 2014 à Paris :
http://www.microsoft.com/france/mstechdays/programmes/2014/fiche-session.aspx?ID=b3d28f7a-c95b-4cb0-8a59-05c5c68450b3 (démonstration de la mise à jour du schéma à partir 21’53’’)
Dans notre maquette nous avons 3 contrôleurs de domaine répartis sur 2 sites. Sur le site 1 nous avons « DC1 » et « DC2 », sur le site 2 nous avons « DC3 ». Les 3 contrôleurs de domaine font partie du même et unique domaine de la forêt. Le principe reste le même si vous disposez de plusieurs domaines, la partition de schéma étant unique sur tous les DC de la forêt. Comme nous le verons un peu plus loin, « DC1 » dispose de l’ensemble des rôles FSMO de la forêt et du domaine.
Nous utiliserons dans cette démonstration l’outil « Active Directory Replication Status Tool (http://www.microsoft.com/en-us/download/details.aspx?id=30005) » afin de voir en détail la réplication des partitions des objets.
Pour commencer nous allons modifier le délai de réplication entre les sites. Par défaut il est de 180 minutes, nous allons le diminuer à 15 minutes pour faciliter notre démonstration. Il est à noter que cette modification n’est pas une recommandation pour votre future migration. Si vous souhaitez modifier l’intervalle de réplication il vous faudra réfléchir à la gestion de la bande passante entre vos 2 sites.
Avant toute opération sur Active Directory il est recommandé d’effectuer un minimum de contrôle sur l’état de santé de vos contrôleurs de domaine. Nous commençons par « dcdiag » et pour éviter de l’exécuter individuellement sur chaque DC, nous ajoutons « /e », le diagnostic se fera automatiquement sur l’ensemble des contrôleurs de domaine. Pour faciliter la lecture, le résultat est envoyé dans un fichier texte.
Nous constatons dans le résultat que « dcdiag » à trouver l’ensemble des contrôleurs de domaine et aucune anomalie n’est apparue.
Il est également possible d’effectuer un diagnostic individuellement sur chaque contrôleur de domaine :
Nous vérifions également la réplication avec la commande « repadmin /showrepl » :
La commande « netdom query fsmo » permet de déterminer pour chaque rôle FSMO (de forêt ou de domaine) quel contrôleur de domaine détient le rôle. Dans notre étude l’ensemble des rôles est pour l’instant sur « DC1.lab.lan ».
L’opération consistant à mettre à jour le schéma est une opération délicate sur le principe car en cas de problème le seul alternatif est la restauration de la forêt. Dans notre exemple nous allons déplacer le rôle de maître de schéma et seulement celui-ci, sur le « DC02 ».
« netdom query fsmo » permet de vérifier que le rôle de maître de schéma est sur DC2 :
Nous désactivons la réplication sortante depuis « DC02 » par la commande « repadmin /options dc02.lab.lan +DISABLE_OUTBOUND_REPL ».
Si nous essayons de lancer une réplication manuelle depuis « DC02 » vers « DC01 » dans la console « sites et services Active Directory ».
A partir de l’outil « Active Directory Replication Status Tool », nous allons suivre la réplication entre les DC2.
Pour ceux qui ne connaissent pas encore l’outil, vous pouvez consulter l’article : http://pbarth.fr/node/142
Sur l’image ci-dessous, nous constatons que « DC02 » ne répond à aucune requête de réplication sortante et sur aucune des partitions d’Active Directory.
Nous allons maintenant insérer l’ISO de 2012R2 sur notre machine virtuelle, afin d’accéder au dossier « support » contenant l’outil « adprep » de mise à jour du schéma.
Une copie du dossier « adprep » a été faite dans le dossier « c:\temp ». Nous allons mettre à jour le schéma avec la commande « adprep /forestpep », puis C puis entrée.
Une fois la mise à jour du schéma effectuée, nous pouvons vérifier le journal de mise à jour dans « c:\windows\debug\adprep\... » :
En cas d’anomalie nous aurions pu supprimer « DC02 », nettoyer les métadonnées et reconstruire un nouveau « DC02 » sans interrompre les autres contrôleurs de domaine.
Nous allons maintenant regarder l’état de la réplication. La réplication de « DC02 » vers « DC01 » est toujours en erreur vu que « DC02 » n’accepte pas la réplication sortante.
En dessous nous voyons que la réplication de « DC01 » vers « DC02 » n’a pas réussi en raison d’une correspondance de schéma à 11h47, juste après la mise à jour du schéma. La réplication de « DC03 » vers « DC02 » n’indique pas d’erreur mais la dernière tentative date de 11h41, juste avant la mise à jour du schéma. Le délai de 15 minutes n’ayant pas encore été atteint, la réplication n’a pas été tentée.
Comme nous n’avons pas eu d’erreur lors de la mise à jour du schéma, nous allons réactiver la réplication sortante de « DC02 » par la commande « repadmin /options dc02.lab.lan -DISABLE_OUTBOUND_REPL » :
Il va nous falloir faire preuve d’un peu de patience car il faut d’abord que « DC02 » réplique les modifications sur le schéma avant que la réplication vers « DC02 » fonctionne à nouveau, en tenant compte que la réplication de « DC03 » est de toutes les 15 minutes car nous avons diminué cette valeur qui est 3 heures par défaut. Le temps de répliquer la mise à jour du schéma la réplication de « DC03 » vers « DC02 » reste en erreur. On remarque également que la réplication de « DC03 » vers « DC02 » a eu lieu juste avant la réplication de « DC02 » vers « DC03 », il faut donc attendre un peu moins de 15 minutes pour la mise à jour du schéma et ensuite encore une fois ce délai pour que la réplication inverse ne soit plus en échec. Avec la valeur par défaut cela fait 6 heures tout de même avec 2 sites AD.
Dans l’image ci-dessous nous remarquons que nous n’avons plus d’erreur dans la réplication 15 minutes que le schéma est été répliqué de « DC02 » vers les autres.
Conclusion :
L’opération de mise à jour du schéma peut être vue comme une opération anodine dans la généralité des cas. Cette idée est renforcée par le fait qu’il n’y a que peu d’erreurs (ou pas) lors de la mise à jour d’un schéma. La présentation indiquée en début d’article remonte que cela fait plusieurs années que Microsoft n’a pas remontées d’incident sur la mise à jour d’un schéma.
Néanmoins il faut garder à l’esprit qu’en cas d’échec la restauration de la forêt n’est pas une opération simple et en général elle n’est pas réalisée régulièrement par les administrateurs systèmes, ce qui la rend hasardeuse. Dans une forêt mono domaine avec un seul site, la restauration consiste à restaurer un DC avec l’état du système et de reconstruire les autres après avoir nettoyé les métadonnées. Essayez maintenant d’imaginer le travail correspondant si votre entreprise est répartie dans le monde sur 20 sites, que certains sites distants ne répliquent pas depuis le site principal mais avec un autre site intermédiaire.
Peut-être avez-vous remarqué que sut Windows 2012, lorsque vous lancer la mise à jour l’assistant de configuration Active Directory (anciennement DCpromo), celui-ci effectuera automatiquement la mise à jour du schéma s’il n’est pas dans la bonne version, ainsi que la préparation du domaine. Cela peut paraître incohérent avec les bonnes pratiques proposées par Microsoft.
Afin de minimiser les risques et de prendre en charge dans les meilleures conditions je vous recommande de tenir compte des éléments suivants :
- Dans tous les scénarios possibles assuré vous d’avoir au moins une sauvegarde récente de 2 contrôleurs de domaines différents pour chaque domaine de votre forêt. Vérifiez dans un environnement neutre que vous êtes en mesure de restaurer votre Active Directory (voir : http://pbarth.fr/node/15 )
- Prenez en compte votre architecture géographique, les sites, les capacités des liens de sites et l’intervalle de réplication inter-site de chaque lien. Selon le cas il est fortement conseillé d’effectuer la mise à jour du schéma plusieurs jours avant.
- Si votre architecture AD est complexe (plusieurs domaines et/ou plusieurs sites), il est préférable d’effectuer la mise à jour du schéma sur un contrôleur de domaine avec l’unique rôle de maître de schéma et de désactiver la réplication sortante de celui-ci. Si l’opération c’est bien déroulé, il faudra réactiver la réplication sortante et faire preuve d’un peu de patiente. En cas d’echec vous supprimer le contrôleur de domaine et vous nettoyer les métadonnées ( voir : http://pbarth.fr/node/94 ), le reste de la forêt étant toujours intègre, cela vous évite une restauration complète lourde si vous disposez de plusieurs domaines et/ou sites
- Vous pouvez selon le cas réduire et optimiser les paramètres d’intervalle de réplication entre les sites en restant dans des limites acceptables en fonction des capacités de vos liens.
- Adprep n’existe pas en version 32bits depuis Windows 2012. Si vous souhaitez passer d’une version 32bits des DC vers du Windows 2012, il faut soit utiliser l’assistant de configuration Active Directory de Windows 2012 qui étendra le schéma à distance sur le maître de schéma en 32bits, soit créé un contrôleur de domaine temporaire en Windows 2008 R2 64 bits. Windows 2008R2 ayant encore l’outil « adprep » en 32 et 64 bits.
- Il n’est pas possible de migrer de Windows 2000 vers 2012, un des prérequis de 2012 est un niveau fonctionnel de forêt en 2003, ce qui impose qu’il n’y ait plus de contrôleur de domaine en Windows 2000.
Quelques lectures supplémentaires :
Réplication inter-site : https://technet.microsoft.com/fr-fr/library/bb967320.aspx?f=255&MSPPError=-2147217396#ECAA
Site et services Active Directory : https://technet.microsoft.com/fr-fr/library/dd407869.aspx
Sauvegarde et restauration : http://pbarth.fr/node/15.
