Virtualisation de contrôleurs de domaine avec Hyper-V

S’applique à : Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Windows Server 2012 et les versions ultérieures prennent en charge les contrôleurs de domaine (DC) virtualisés avec des protections pour éviter la restauration du numéro de séquence à un état antérieur (USN Rollback) sur les DC virtuels et la capacité de cloner des DC virtuels. La virtualisation regroupe différents rôles de serveur sur une seule machine physique. Pour plus d’informations, consultez l’article Virtualisation sécurisée Active Directory Domain Services (AD DS).

Ce guide décrit comment exécuter des DC en tant que systèmes d’exploitation invités 32 bits ou 64 bits.

Planification pour la virtualisation

Les sections suivantes contiennent des considérations de planification à connaître lors de la virtualisation d’un DC, y compris les exigences matérielles, l’architecture, la configuration, et la gestion de la sécurité et des performances.

Configuration requise pour Hyper-V

Pour installer et utiliser le rôle Hyper-V, votre matériel doit remplir les conditions suivantes :

• Vous devez disposer d’un processeur x64.

• Votre processeur doit permettre d’activer la fonctionnalité de virtualisation assistée par le matériel.

  • Typiquement, ce paramètre est connu sous le nom de Technologie de virtualisation Intel (Intel VT) ou Virtualisation avancée AMD (AMD-V).

• Votre processeur doit prendre en charge la Protection de l’exécution des données matérielle (DEP).

  • Vous ne pouvez utiliser Hyper-V que si vous activez le bit d’exécution sans faille Intel (XD) ou le bit de non-exécution AMD (NX).

Évitez les points de défaillance uniques

Lors de la planification de votre déploiement de DC virtuel, nous vous recommandons de préparer une stratégie pour éviter de créer des points de défaillance uniques. Vous pouvez éviter d’introduire des points de défaillance uniques potentiels, ou des zones où les temps d’arrêt peuvent causer l’arrêt complet du système, en mettant en œuvre une redondance du système.

Les recommandations suivantes peuvent contribuer à prévenir les points de défaillance uniques. Toutefois, il est également important de se rappeler que la suite de ces recommandations peut augmenter les coûts d’administration.

• Exécutez au moins deux contrôleurs de domaine virtualisés par domaine sur des hôtes de virtualisation différents. Cette configuration réduit le risque de perte de tous les contrôleurs de domaine dans le cas où un hôte de virtualisation s’arrête de fonctionner.

• Diversifiez le matériel sur lequel s’exécutent vos DC. Par exemple, utilisez différents processeurs, cartes mères, adaptateurs réseau, etc. Un matériel diversifié prévient les dommages causés par les dysfonctionnements des appareils et du matériel ou la configuration du fournisseur.

• Si possible, exécutez vos DC sur du matériel situé dans différentes régions. Cette approche réduit les conséquences des catastrophes qui affectent l’un des sites hébergeant vos DC.

• Ajoutez des DC physiques à tous vos domaines. La configuration de votre système avec des DC physiques empêche vos systèmes hôtes de subir des dysfonctionnements de la plate-forme de virtualisation.

Considérations de sécurité

Vous devez gérer l’ordinateur hôte sur lequel vous exécutez vos DC virtuels avec autant de soin que vous le feriez pour un DC inscriptible, même si l’ordinateur n’est qu’un ordinateur appartenant à un domaine ou à un groupe de travail. Cette exigence est pour des raisons de sécurité. Les hôtes mal gérés sont vulnérables aux attaques d’élévation des privilèges, où des utilisateurs malveillants obtiennent un accès à des privilèges plus élevés que ceux auxquels ils sont censés avoir accès parce que l’administrateur a attribué le mauvais niveau de permission à un rôle de niveau inférieur. Ces attaques peuvent compromettre toutes les machines virtuelles (VM), les domaines et les forêts hébergés par l’ordinateur affecté.

Lorsque vous planifiez de virtualiser votre DC, gardez à l’esprit les considérations de sécurité suivantes :

• Les informations d’identification administratives locales d’un ordinateur hébergeant des DC inscriptibles virtuels doivent être traitées de la même manière que l’administrateur de domaine par défaut de tous les domaines et forêts auxquels ces DC appartiennent.

• Nous vous recommandons de configurer votre système pour qu’il dispose d’un hôte exécutant une installation de base de Windows Server avec uniquement Hyper-V comme application. Cette configuration limite le nombre d’applications et de serveurs que vous installez sur le serveur. Cette limitation améliore les performances du système et crée également une surface d’attaque réduite, avec moins de points d’entrée pour les attaques malveillantes via des applications et des services.

• Pour les succursales ou autres emplacements difficiles à sécuriser, nous vous recommandons d’utiliser des DC en lecture seule (RODC). Si vous avez un réseau de gestion distinct, nous vous recommandons de connecter uniquement l’hôte à ce réseau de gestion. Pour plus d’informations sur les contrôleurs de domaine en lecture seule, consultez l’article Installer un contrôleur de domaine en lecture seule Active Directory Windows Server (niveau 200).

• Vous pouvez sécuriser vos DC avec BitLocker. Dans Windows Server 2016 et ultérieur, vous pouvez également utiliser la fonctionnalité de module de plate-forme sécurisée virtuelle (TPM) qui fournit le matériel de clé invité nécessaire pour déverrouiller le volume système.

• La structure fabric protégée et les machines virtuelles dotées d’une protection maximale peuvent fournir des contrôles complémentaires pour protéger vos contrôleurs de domaine.

Pour plus d’informations sur la sécurisation des contrôleurs de domaine, consultez le guide des bonnes pratiques de sécurisation des installations Active Directory.

Limites de sécurité pour les configurations d’hôte et invité

Vous pouvez mettre en œuvre des machines virtuelles (VM) sur de nombreux types différents de configurations de DC. Par conséquent, vous devez soigneusement considérer comment ces VM affectent les limites et les relations de confiance dans votre topologie Active Directory. La liste suivante décrit deux configurations que vous pouvez mettre en place pour les contrôleurs de domaine (DC) Active Directory et les hôtes sur un serveur Hyper-V, ainsi que les ordinateurs invités qui sont des machines virtuelles (VM) exécutées sur le serveur Hyper-V :

• Un hôte qui est un ordinateur de groupe de travail ou membre avec un invité qui est un DC.
• Un hôte qui est un ordinateur de groupe de travail ou membre avec un invité qui est également un ordinateur de groupe de travail ou membre.

Le diagramme suivant illustre une configuration de trois VM DC invitées hébergées sur un serveur Hyper-V :

Diagramme d’un exemple de déploiement de trois machines virtuelles et d’un serveur Hyper-V. Les trois VM sont à l’intérieur d’un rectangle bleu étiqueté « machines invités ». Les trois VM sont des contrôleurs de domaine. La VM 1 est dans le domaine Corp et dans la forêt Contoso.com. La VM 2 est dans le domaine Fabrikam et dans la forêt Fabrikam.com. La VM 3 est dans le domaine HQ et dans la forêt Fineartschool.net. Le serveur Hyper-V est à l’extérieur du rectangle bleu. C’est un serveur membre situé dans le domaine Corp et la forêt Contoso.com.

Sur la base de la configuration d’exemple dans le diagramme précédent, voici quelques considérations importantes que vous devriez prendre en compte lors de la planification d’un déploiement comme celui-ci :

• Accès administrateur :

  • Les informations d’identification administratives sur l’ordinateur hôte doivent être traitées de la même manière que celles de l’administrateur de domaine sur le DC inscriptible. Pour un invité RODC, les informations d’identification administratives de l’ordinateur hôte doivent être traitées de la même manière que celles de l’administrateur local sur le RODC invité.

• Droits administratifs du DC sur l’ordinateur hôte :

  • Un administrateur d’un DC virtualisé dispose de droits administratifs sur l’hôte si vous rejoignez l’hôte dans le même domaine. Cependant, ce privilège d’accès peut également donner aux utilisateurs malveillants l’occasion de compromettre toutes les VM s’ils peuvent accéder à la VM 1. Ce scénario crée un possible vecteur d’attaque. Vous pouvez prévenir ce vecteur d’attaque en vous assurant que tous les DC configurés pour plusieurs domaines ou forêts ont un domaine d’administration centralisé auquel tous les domaines font confiance, et en faisant de l’hôte de virtualisation un membre du domaine d’administration très privilégié. Cette approche empêche les administrateurs de domaine individuels de contrôler l’hôte et donc les autres domaines.

• Éviter les attaques :

  • Les utilisateurs malveillants peuvent attaquer la VM 1 même si vous l’installez en tant que RODC. Bien que les administrateurs de RODC n’aient pas explicitement de droits d’administrateur de domaine, ils peuvent toujours utiliser le RODC pour appliquer des politiques à l’ordinateur hôte. Ces politiques peuvent par exemple inclure des scripts de démarrage. Si un acteur malveillant trouve un moyen d’obtenir des droits d’administrateur RODC et envoie une politique avec un script de démarrage malveillant, il peut compromettre l’ordinateur hôte et l’utiliser pour compromettre d’autres VM sur l’hôte.

• Sécurité des fichiers de disque virtuel (VHD) :

  • Les fichiers VHD pour un DC virtuel sont comme le disque dur physique d’un DC physique. Vous devez aussi bien sécuriser le fichier VHD que vous le feriez avec un disque dur. Assurez-vous de n’autoriser que des administrateurs fiables et de confiance à accéder à ces fichiers VHD.

• Contrôleurs RODC

  • Vous pouvez placer des RODC dans des endroits où la sécurité physique n’est pas garantie, comme les succursales. Vous pouvez protéger leurs fichiers VHD à l’aide de l’encryption de lecteur BitLocker de Windows contre les attaques sur l’hôte impliquant le vol du disque physique. Cependant, ces protections ne s’appliquent pas aux systèmes de fichiers à l’intérieur du RODC.

Considérations relatives aux performances

L’architecture micro-noyau 64 bits offre de meilleures performances Hyper-V par rapport aux plates-formes de virtualisation précédentes.

Les performances des VM dépendent de la charge de travail que vous utilisez. Nous vous recommandons de tester des topologies de VM spécifiques pour vous assurer que vous êtes satisfait des performances de votre déploiement Active Directory. Vous pouvez évaluer les performances sous des charges de travail sur une période de temps spécifique à l’aide d’outils comme le Moniteur de fiabilité et de performances (Perfmon.msc) ou l’outil Microsoft Assessment and Planning (MAP). L’outil MAP peut également vous aider à dresser l’inventaire de tous les serveurs et rôles de serveur actuellement présents dans votre réseau.

Pour vous donner une idée de la façon dont les tests de performance des DC virtualisés fonctionnent, nous avons créé un exemple de test de performance utilisant l’outil de test de performance Active Directory (ADTest.exe).

Des tests du protocole d’accès léger au répertoire (LDAP) ont été effectués sur un DC physique en utilisant ADTest.exe. Les mêmes tests ont été exécutés sur un DC virtualisé qui consistait en une VM hébergée sur un serveur identique au DC physique. Seul un processeur logique a été utilisé dans cette configuration d’exemple pour l’ordinateur physique et un seul processeur virtuel pour la VM. Cette configuration a permis au déploiement d’atteindre facilement une utilisation CPU de 100 %.

Le tableau suivant répertorie les résultats des tests pour les DC physiques et virtuels. Les lettres et chiffres entre parenthèses à côté des noms des tests sont leurs étiquettes dans ADTest.exe. Ces données montrent que les performances du DC virtualisé étaient comprises entre 88 et 98 % des performances du DC physique.

Mesure	Test	Physique	Les machines	Delta
Recherches/s	Recherche de nom commun dans l'étendue de base (L1)	11 508	10 276	-10,71 %
Recherches/s	Recherche de groupe d'attributs dans l'étendue de base (L2)	10123	9005	-11,04 %
Recherches/s	Recherche de tous les attributs dans l'étendue de base (L3)	1 284	1 242	-3,27 %
Recherches/s	Recherche de nom commun dans l'étendue de sous-arborescence (L6)	8 613	7904	-8,23 %
Liaisons réussies/s	Réalisation de liaisons rapides (B1)	1438	1 374	-4,45 %
Liaisons réussies/s	Réalisation de liaisons simples (B2)	611	550	-9,98 %
Liaisons réussies/s	Utilisation de NTLM pour réaliser les liaisons (B5)	1068	1056	-1,12 %
logiques/s	Écriture de plusieurs attributs (W2)	6 467	5 885	-9 %

Pour maximiser les performances dans notre déploiement de test, nous avons installé des composants d’intégration (IC) dans cette configuration de test pour permettre au système d’exploitation invité d’utiliser des pilotes synthétiques prenant en charge les hyperviseurs. Lorsque vous installez un IC, parfois vous devez utiliser des pilotes émulés pour les disques IDE ou les adaptateurs réseau. Dans un environnement de production, remplacez ces pilotes émulés par des pilotes synthétiques afin d'accroître les performances.

En se basant sur ce test, prenez en compte les recommandations suivantes pour améliorer les performances :

• Lorsque vous surveillez les performances de la VM en utilisant l’outil Perfmon.msc, parfois les informations CPU pour la VM ne sont pas entièrement précises. Cette inexactitude est due à la manière dont le processeur virtuel est planifié pour s’exécuter sur le processeur physique. Pour des informations sur le CPU plus précises pour les VM exécutées sur des serveurs Hyper-V, utilisez les compteurs de processeur logique de l’hyperviseur Hyper-V dans la partition hôte. Pour plus d’informations sur le réglage des performances pour AD DS et Hyper-V, consultez le guide d’optimisation des performances pour Windows Server.

• Nous vous recommandons d’éviter d’utiliser des disques VHD à différenciation sur une VM configurée en tant que DC, car ces disques peuvent réduire les performances. Pour en savoir plus sur les types de disques Hyper-V, y compris les disques de différentiation, consultez Assistant Nouveau disque dur virtuel.

• Nous vous recommandons également de vous familiariser avec les informations sur l’utilisation d’AD DS dans les environnements d’hébergement virtuel en lisant les Points à considérer lorsque vous hébergez des contrôleurs de domaine Active Directory dans des environnements d’hébergement virtuel.

Points à prendre en considération pour le déploiement

Les sections suivantes décrivent les pratiques courantes des machines virtuelles à éviter lors du déploiement de contrôleurs de domaine, ainsi que les considérations spéciales pour la synchronisation de l’heure et le stockage.

Recommandations concernant le déploiement

Les plates-formes de virtualisation comme Hyper-V ont de nombreuses fonctionnalités qui facilitent la gestion, la maintenance, la sauvegarde et la migration des machines. Cependant, il y a certaines recommandations à suivre pour profiter de ces fonctionnalités pour vos DC virtuels.

• Pour garantir que vos écritures Active Directory sont durables, ne déployez pas les fichiers de base de données virtuels DC, tels que la base de données Active Directory NTDS.DIT, les journaux et SYSVOL, sur des disques IDE virtuels. Au lieu de cela, créez un deuxième disque dur virtuel (VHD) attaché à un contrôleur SCSI virtuel et assurez-vous que les fichiers de base de données sont sur le disque SCSI de la VM lors de l’installation du DC.

• N’implémentez pas de disques VHD à différenciation sur une VM que vous configurez comme le DC. Bien que cette approche rende facile la restauration de votre déploiement à des versions précédentes, elle diminue également les performances. Pour plus d’informations sur les types de disque dur virtuel (VHD), consultez Assistant Nouveau disque dur virtuel.

• N’implémentez pas de domaines et de forêts Active Directory sur une copie d’un système d’exploitation Windows Server sans utiliser d’abord l’outil de préparation du système (Sysprep) pour les préparer au déploiement. Pour plus d’informations sur l’exécution de l’outil Sysprep, consultez Vue d’ensemble de Sysprep (préparation du système).

  Avertissement

  L’exécution de Sysprep sur un DC promu n’est pas recommandée, car cela peut avoir un impact négatif sur la base de données AD et les composants associés et entraîner les problèmes suivants :

  • Perte de données
  • Corruption de la base de données AD
  • Problèmes de stabilité et de fonctionnalité
  • Problèmes d’applications, de services et de pilotes

• N’implémentez pas d’autres DC avec une copie d’un fichier VHD à partir d’un DC que vous avez déployé. Ne pas utiliser de copies empêche les scénarios potentiels d’USN rollback. Pour plus d’informations sur l’USN rollback, veuillez consulter la section USN et USN rollback.

  • Dans Windows Server 2012 et les versions ultérieures, les administrateurs peuvent cloner des images DC pour déployer plus de DC, mais seulement s’ils utilisent des images correctement préparées.

• Ne pas utiliser la fonction Exportation Hyper-V pour exporter une VM qui exécute un DC.

  • Dans Windows Server 2012 et les versions ultérieures, le système gère l’exportation et l’importation des invités virtuels DC comme une restauration non autoritaire. Ce processus détecte si l’ID de génération a changé et si le DC n’est pas configuré pour le clonage.

  • Lorsque vous exportez une VM invitée, assurez-vous que personne ne l’utilise. Pour simplifier les choses, vous pouvez utiliser la réplication Hyper-V pour créer une copie inactive du DC. Lorsque vous commencez à utiliser l’image répliquée, vous devez également effectuer un nettoyage comme vous le feriez pour l’image source après avoir exporté une image de DC invitée.

Conversion physique vers virtuelle

System Center VM Manager (VMM) vous permet de gérer les machines physiques et les VM de manière unifiée. Vous pouvez également utiliser VMM pour migrer une machine physique vers une VM. Ce processus de migration s’appelle la conversion de physique à machine virtuelle, ou conversion P2V. Pour commencer le processus de conversion P2V, vous devez vous assurer que la VM et le DC physique que vous migrez ne fonctionnent pas en même temps. En veillant à ce que les deux machines ne fonctionnent pas en même temps, vous évitez les scénarios de retour en arrière USN, comme décrit dans USN et retour en arrière USN.

Il est recommandé d’effectuer la conversion P2V en mode hors ligne pour maintenir la cohérence des données de l’annuaire lorsque vous rallumez le DC. Vous pouvez activer le mode hors ligne dans le programme d’installation de Convert Physical Server. Pour plus d’informations sur l’utilisation du mode hors ligne, consultez la documentation Convertir des ordinateurs physiques en VM dans VMM.

Nous vous recommandons également de déconnecter la VM du réseau pendant la conversion P2V. Vous ne devriez activer l’adaptateur réseau qu’après avoir terminé le processus de conversion et vérifié que tout fonctionne correctement. À ce moment-là, vous devriez éteindre la machine source physique. Ne rallumez pas la machine source physique et ne la reconnectez au réseau qu’après avoir reformaté le disque dur.

Éviter l’USN rollback

Lorsque vous créez des DC virtuels, vous devriez éviter de créer des scénarios d’USN rollback. Pour éviter le rollback, vous pouvez configurer un nouveau DC virtuel avec une promotion régulière, une promotion à partir de l’installation à partir des médias (IfM), ou en clonant le DC si vous avez déjà au moins un DC virtuel. Cette approche vous permet également d’éviter les problèmes de matériel ou de plate-forme que les invités virtuels convertis P2V pourraient rencontrer.

Avertissement

Pour prévenir les problèmes de réplication d’Active Directory, assurez-vous qu’il n’existe qu’un seul DC physique ou virtuel sur un réseau donné à tout moment. Vous pouvez réduire le risque de problème lié à l’ancien clone en utilisant l’une des méthodes suivantes :

• Lorsque le nouveau DC virtuel fonctionne, exécutez la commande suivante deux fois pour changer le mot de passe du compte ordinateur :

  netdom resetpwd /Server:<domain-controller>
  

• Exportez et importez le nouvel invité virtuel pour le forcer à devenir un nouvel ID de génération et un ID d’appel de base de données.

Environnements de test et migration P2V

Vous pouvez utiliser la migration P2V en combinaison avec le VMM pour créer des environnements de test. Avec cette méthode, vous pouvez migrer des DCs de production de machines physiques à des VMs pour créer un environnement de test sans mettre définitivement hors service les DCs de production. Cependant, vous devez construire l’environnement de test sur un réseau séparé de l’environnement de production pour permettre l’existence de deux instances du même DC. Il est important d’éviter les USN rollback lorsque vous créez des environnements de test en utilisant la migration P2V.

Création d’un environnement de test

Nous vous recommandons la démarche suivante lorsque vous créez des environnements de test en utilisant P2V :

• Migrez un DC en production de chaque domaine vers une VM de test en utilisant P2V, en vous basant sur les recommandations fournies dans la section Conversion de physique vers virtuel.

• Placez les machines de production physiques et les VMs de test sur des réseaux différents lorsque vous les remettez en ligne.

• Pour éviter les USN rollbacks dans l’environnement de test, déconnectez tous les DCs que vous prévoyez de migrer du réseau. Vous pouvez déconnecter vos DCs en arrêtant le service NTDS ou en redémarrant les machines en mode de restauration des services d’annuaire (DSRM).

• N’introduisez aucune nouvelle mise à jour dans l’environnement après avoir déconnecté les DCs du réseau.

• Ne connectez aucune des machines au réseau pendant la migration P2V. Vous ne pouvez les reconnecter qu’une fois la migration de toutes les machines terminée.

• Vous devriez uniquement promouvoir les DCs de test que vous créez après la conversion P2V en tant que répliques dans l’environnement de test.

Service de temps et synchronisation

Pour les VMs que vous configurez pour être des DCs, nous recommandons de désactiver la synchronisation temporelle entre le système hôte et le système invité agissant en tant que DC. Si le DC invité ne se synchronise pas avec le système hôte, alors il se synchronise avec la hiérarchie du domaine à la place.

Pour désactiver le fournisseur de synchronisation temporelle Hyper-V, éteignez la VM, puis allez dans les paramètres de la VM, sélectionnez Services d’intégration et décochez la case Synchronisation temporelle.

Stockage et optimisation

Il est conseillé de suivre les recommandations de stockage fournies dans cette section pour optimiser la performance de votre VM DC et assurer la durabilité de vos écritures Active Directory.

• Pour le stockage invité, stockez le fichier de base de données Active Directory (Ntds.dit) et les fichiers de journal et SYSVOL sur un disque virtuel séparé des fichiers OS. Nous recommandons de stocker ces fichiers dans un disque SCSI virtuel dans un deuxième VHD attaché à un contrôleur SCSI virtuel. Un disque SCSI virtuel augmente la performance et prend en charge l’Accès Forcé à l’Unité (FUA). Avec FUA, l’OS écrit et lit directement depuis le média, contournant tout mécanisme de mise en cache.

• Si vous utilisez BitLocker pour sécuriser votre invité DC virtuel, configurez les volumes supplémentaires pour le déverrouillage automatique en utilisant l’applet de commande PowerShell Enable-BitLockerAutoUnlock.

• Lorsque vous stockez des fichiers VHD sur des hôtes, vous devriez utiliser un disque qui n’est pas fréquemment utilisé par d’autres services ou applications, comme le disque système pour le système d’exploitation hôte. Stockez chaque fichier VHD sur une partition séparée du système d’exploitation hôte et des autres fichiers VHD, de préférence sur un disque physique séparé.

• Votre système de disque physique hôte doit répondre à au moins l’un des critères suivants pour répondre aux exigences d’intégrité des données des charges de travail virtualisées :

  • L’hôte utilise des disques de classe serveur, tels que SCSI ou Fibre Channel.

  • L’hôte assure que les disques sont connectés à un HBA avec cache sur batterie.

  • L’hôte utilise un contrôleur de stockage comme un système de disques en réseau indépendant (RAID) comme dispositif de stockage.

  • L’hôte utilise une alimentation sans interruption (UPS) pour alimenter le disque.

  • L’hôte désactive par défaut la fonction de mise en cache en écriture du disque.

• Lorsque vous utilisez des fichiers VHD, nous vous recommandons d’utiliser des disques pass-through ou des VHD de taille fixe car ils sont optimisés pour la performance. Nous ne recommandons pas les disques en expansion dynamique et les disques de différenciation car ils peuvent causer des retards, une dégradation de la performance pendant une activité disque élevée et une perte de données potentielle lors du retour à un instantané précédent.

• Nous vous recommandons d’utiliser des contrôleurs SCSI virtuels pour réduire les chances de corruption de vos données Active Directory.

  • Sur les serveurs Hyper-V qui hébergent des DC virtuels, vous devriez utiliser des disques physiques SCSI. Si votre scénario ne vous permet pas d’utiliser des disques SCSI, nous vous recommandons de désactiver la mise en cache en écriture sur le disque ATA ou IDE que vous utilisez à la place. Pour plus d’informations, consultez ID d’événement 1539 – Intégrité de la base de données.

Restrictions opérationnelles pour les contrôleurs de domaine VM

Certaines restrictions opérationnelles applicables aux contrôleurs de domaine exécutés sur des machines virtuelles ne s’appliquent pas aux contrôleurs de domaine exécutés sur des ordinateurs physiques. Lorsque vous utilisez un DC virtualisé, vous devez suivre ces directives :

• Ne mettez pas en pause, n’arrêtez pas, ni ne stockez l’état enregistré d’un DC dans une VM plus longtemps que la durée de vie de l’objet effacé de la forêt. La reprise d’un état enregistré que vous avez mis en pause ou enregistré plus longtemps que la durée de vie de l’objet effacé peut interférer avec la réplication. Pour savoir comment déterminer la durée de vie de désactivation de la forêt, consultez l’article Déterminer la durée de vie de désactivation de la forêt(uniquement disponible en anglais pour le moment).

• Ne copiez ni ne clonez des VHDs.

• Ne prenez pas ni n’utilisez des instantanés de DC virtuels. Vous devriez utiliser une méthode de sauvegarde plus permanente et fiable à la place.

• Ne pas utiliser la fonction d’exportation sur une machine virtuelle qui exécute un contrôleur de domaine.

• Ne restaurez ni ne revenez à un état antérieur de votre DC ou du contenu d’une base de données Active Directory en utilisant une méthode de sauvegarde non prise en charge.

Considérations relatives à la sauvegarde et à la restauration

Vous devez sauvegarder vos DCs pour éviter la perte de données due à des scénarios de catastrophe ou à des erreurs administratives. La méthode de sauvegarde prise en charge par Active Directory est d’utiliser une application de sauvegarde pour restaurer une sauvegarde de l’état du système faite à partir de l’installation actuelle du DC. L’application devrait être compatible avec Active Directory, comme Windows Server Backup. Pour plus d’informations sur les méthodes de sauvegarde prises en charge, veuillez consulter le guide étape par étape de la sauvegarde et de la récupération d’AD DS.

Dans les déploiements virtualisés, vous devez prêter une attention toute particulière à certaines exigences relatives aux opérations de sauvegarde d’Active Directory. Par exemple, si vous restaurez un DC en utilisant une copie du fichier VHD et que vous ne mettez pas à jour la version de la base de données du DC après l’avoir restauré, cela peut causer des problèmes de réplication en raison de numéros de suivi inexacts parmi les réplicas de DC. Dans la plupart des cas, la réplication ne détecte pas ce problème et ne signale aucune erreur, mais des incohérences entre les DCs peuvent potentiellement causer des problèmes dans certains scénarios.

Méthode recommandée pour sauvegarder et restaurer les DCs virtualisés

La méthode que nous vous recommandons d’utiliser pour sauvegarder et restaurer vos DCs virtualisés est d’exécuter Windows Server Backup dans le système d’exploitation invité. Pour plus d’informations, veuillez consulter la rubrique Restaurer un contrôleur de domaine virtuel.

Bien que vous puissiez techniquement utiliser des instantanés ou des copies de fichiers VHD pour restaurer une sauvegarde, nous ne recommandons pas d’utiliser ces méthodes pour les raisons suivantes :

• Si vous copiez ou clonez un fichier VHD, la base de données devient obsolète car son numéro de version de la base de données n’est pas automatiquement mis à jour lorsque vous la restaurez. Cette incohérence dans les numéros de suivi signifie que si vous démarrez le VHD en mode normal, vous pouvez potentiellement provoquer un USN rollback.

• Bien que Windows Server 2016 et les versions ultérieures soient compatibles avec les instantanés, les instantanés ne fournissent pas le type d’historique de sauvegarde stable et permanent dont vous avez besoin pour restaurer de manière cohérente votre système en cas de scénarios catastrophe. Les instantanés basés sur le Volume Shadow Copy Service (VSS) que vous pouvez créer dans Hyper-V de Windows Server 2016 et les version ultérieures ne sont également pas compatibles avec BitLocker, ce qui peut potentiellement causer des problèmes de sécurité. Ce problème empêche le moteur de base de données Active Directory d’accéder à la base de données contenant l’instantané lorsque Hyper-V tente de monter le volume de l’instantané.

Remarque

Le projet de VM protégée décrit dans Infrastructure Service Guardian et VMs protégées a une sauvegarde pilotée par l’hôte Hyper-V comme un non-objectif pour la protection maximale des données de la VM invité.

USN et restauration USN

Cette section décrit les problèmes de réplication qui peuvent survenir en raison d’une restauration incorrecte de la base de données Active Directory avec une ancienne version de machine virtuelle. Pour plus d’informations sur la réplication Active Directory, consultez Concepts de réplication Active Directory.

Utilisation des USN par AD DS et les contrôleurs de domaine

AD DS utilise les USN pour assurer le suivi de la réplication des données entre les contrôleurs de domaine. Chaque fois que vous modifiez des données dans l’annuaire, l’USN augmente pour indiquer un nouveau changement.

Les DC de destination utilisent les USN pour suivre les mises à jour de chaque partition d’annuaire qu’ils stockent. L’USN suit également l’état de chaque DC qui stocke des réplicas de ces partitions d’annuaire. Lorsque les DC répliquent des changements entre eux, ils interrogent leurs partenaires de réplication pour des changements avec des USN supérieurs au dernier changement que le DC a reçu de son partenaire.

Vous pouvez trouver les tables de métadonnées de réplication qui contiennent les USN dans le vecteur d’actualité et la limite supérieure. Les DC source et de destination utilisent ces tables pour filtrer les mises à jour requises pour le DC de destination.

Le DC de destination maintient la table du vecteur d’actualité pour suivre les mises à jour d’origine qu’il reçoit de tous les DC source. Lorsqu’un contrôleur de domaine cible demande des modifications pour une partition d’annuaire, il fournit son vecteur de mise à jour au contrôleur de domaine source. Le contrôleur de domaine source utilise ensuite cette valeur pour filtrer les mises à jour qu’il envoie au contrôleur de domaine cible. Le DC source envoie son vecteur d’actualité au DC de destination après qu’un cycle de réplication réussi se termine. Le DC source utilise l’USN pour suivre si le DC de destination est synchronisé avec les mises à jour d’origine de chaque DC, et que les mises à jour vers les destinations sont au même niveau que la source.

Le DC de destination maintient la table de la limite supérieure pour suivre les changements les plus récents qu’il a reçus d’un DC source spécifique pour une partition spécifique. La table de la limite supérieure empêche le DC source d’envoyer des changements que le DC de destination a déjà reçus de sa part.

Identité de la base de données de l'annuaire

Outre les USN, les contrôleurs de domaine conservent une trace de la base de données d’annuaire des partenaires de réplication sources. Le système maintient l’identité de la base de données d’annuaire fonctionnant sur le serveur séparément de l’identité de l’objet serveur lui-même. L’identité de la base de données d’annuaire de chaque contrôleur de domaine est stockée dans l’attribut invocationID de l’objet NTDS Settings, qui se trouve à l’emplacement LDAP (Lightweight Directory Access Protocol)cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*.

Le système stocke l’identité de l’objet serveur dans l’attribut objectGUID de l’objet NTDS Settings. Cette identité ne change jamais. Cependant, l’identité de la base de données d’annuaire change dans les circonstances suivantes :

• Lorsqu’une procédure de restauration de l’état du système se produit sur le serveur.

• Lorsque vous ajoutez une partition d’annuaire d’application au serveur, puis la supprimez, puis l’ajoutez à nouveau.

• Lorsqu’une instance Hyper-V déclenche ses enregistreurs VSS sur une partition contenant un VHD de DC virtuel.

  Dans ce scénario, l’invité déclenche ses propres enregistreurs VSS. Cette action est le même mécanisme utilisé par le processus de sauvegarde et de restauration. Cette méthode réinitialise l’attribut invocationID.

L’attribut invocationID relie un ensemble de mises à jour d’origine sur un DC avec une version spécifique de la base de données d’annuaire. Les tables de vecteur de mise à jour et de limite supérieure utilisent l’attribut invocationID et le GUID du DC respectivement pour que les DC reconnaissent de quelle copie de la base de données Active Directory les informations de réplication proviennent.

L’attribut invocationID est une valeur d’identifiant unique global (GUID) qui est visible près du haut de la sortie après avoir exécuté la commande repadmin /showrepl. Le texte suivant représente un exemple de sortie de cette commande :

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Lorsque vous restaurez AD DS sur un DC, le système réinitialise l’attribut invocationID. Ce changement augmente le trafic de réplication, avec une durée relative à la taille de la partition que vous répliquez.

Pour démontrer ce scénario, le diagramme suivant représente un exemple d’environnement où le contrôleur de domaine virtuel VDC1 et le contrôleur de domaine DC2 sont deux DC dans le même domaine. Ce diagramme montre comment DC2 détecte la valeur invocationID dans VDC1 après une réinitialisation dans un scénario de restauration pris en charge.

Un diagramme représentant un organigramme de la vue de VDC1 sur lui-même et la vue de DC2 sur VDC1. Sur la ligne VDC1, VDC1 commence avec un USN de 1000 et un ID d’invocation de B. Il est ensuite restauré à sa version précédente, qui a un USN de 500 et une valeur ID d’invocation de B. Des changements se produisent sur VDC1, le ramenant à USN 600 tandis que l’ID d’invocation reste le même. Sur la ligne où est écrit « Vue de DC2 sur VDC1 », DC2 commence avec un ID d’invocation de VDC1(A)@USN1000. Après la restauration de VDC1, DC2 réinitialise son USN attendu de 1000 à 500, faisant sa valeur pour l’ID d’invocation B VDC1(B)@USN500. Il continue de suivre à la fois l’ID d’invocation A et l’ID d’invocation B. Après le prochain ensemble de changements sur VDC1, DC2 suit maintenant l’ID d’invocation A de VDC1 de USN 1000 et son nouvel ID d’invocation B de USN 600.

Restauration USN

Un USN rollback se produit lorsque le système ne peut pas mettre à jour un USN comme d’habitude, qu’un utilisateur contourne les mises à jour USN, ou qu’un DC tente d’utiliser un USN inférieur à sa dernière mise à jour. Lorsque le système détecte un USN rollback, il arrête la réplication avant que la non-concordance puisse causer une divergence dans la forêt.

De nombreux facteurs peuvent causer un USN rollback. Par exemple, cela peut se produire si vous utilisez de vieux fichiers VHD ou effectuez une conversion P2V sans déconnecter définitivement la machine physique après la conversion.

Prévenir un USN rollback

Vous pouvez prévenir les USN rollback en prenant les précautions suivantes :

• Si vous n’exécutez pas Windows Server 2012 (ou version ultérieure), n’effectuez ni n’utilisez pas d’instantané d’une machine virtuelle de contrôleur de domaine.

• Ne copiez pas le fichier VHD du contrôleur de domaine.

• Lorsque vous n’exécutez pas Windows Server 2012 ou une version ultérieure, n’exportez pas une VM qui exécute un DC.

• Restaurez uniquement un DC ou revenez aux contenus d’une base de données Active Directory en utilisant des solutions de sauvegarde de première partie prises en charge, telles que la sauvegarde de serveur Windows.

Parfois, le système ne peut pas détecter un USN rollback avant qu’il ne puisse causer des erreurs de réplication. Lorsque vous rencontrez des erreurs de réplication, vous devez identifier l’étendue du problème et y remédier dès que possible. Pour plus d’informations sur comment supprimer les objets résiduels pouvant résulter d’un USN rollback, veuillez consulter l’événement ID 1388 ou 1988 de réplication Active Directory : Un objet résiduel est détecté.

Détection des restaurations USN

Dans la plupart des cas, le système peut détecter les USN rollback en suivant les incohérences dans l’attribut invocationID causées par la restauration d’un DC sans réinitialiser l’attribut. Windows Server 2008 offre des protections contre les erreurs de réplication après des opérations de restauration de DC non supportées. Ces protections sont déclenchées lorsqu’une restauration non supportée crée des USNs inférieurs aux versions originales, représentant des changements que les partenaires de réplication ont déjà reçus.

Dans Windows Server, lorsque un DC de destination demande des changements en utilisant un USN précédemment utilisé, le DC de destination interprète la réponse du partenaire de réplication comme signifiant que ses métadonnées de réplication sont obsolètes. Des métadonnées obsolètes signifient que la base de données Active Directory sur le DC source est revenue à un état antérieur, donc le système répond en conséquence.

Par exemple, disons qu’un fichier VHD d’une VM est revenu à une version précédente. Dans ce cas, le DC de destination initie les mesures de quarantaine suivantes sur le DC identifié comme ayant subi une restauration non supportée :

• AD DS interrompt le service Net Logon, empêchant la modification des mots de passe des comptes utilisateur et ordinateur. Cela évite que ces modifications soient perdues si elles se produisent après une restauration inadéquate.

• AD DS désactive la réplication Active Directory en entrée et en sortie.

• AD DS génère l’événement ID 2095 dans le journal d’événements du service d’annuaire pour enregistrer ce qui s’est passé.

Le diagramme suivant montre la séquence d’événements qui se produisent lorsque AD DS détecte un USN rollback sur VDC2, le DC de destination qui fonctionne sur une VM. Dans cette illustration, la détection d’un USN rollback se produit sur VDC2 lorsqu’un partenaire de réplication détecte que VDC2 a envoyé une valeur d’USN de mise à jour déjà vue par le DC de destination. Cette condition indique que la base de données de VDC2 a subi un rollback.

Un diagramme dépeignant un organigramme des mises à jour de VDC2 et la valeur de mise à jour pour VDC2 sur DC1. VDC2 commence avec un USN de 100 et un ID d’invocation A. Il met ensuite à jour ses USNs de 101 à 200, qui sont répliqués sur DC1. Cependant, l’utilisateur fait également une copie VHD de VDC2 USN 200. Ensuite, VDC2 se met à jour de USN 201 à 350, et réplique ces changements sur DC1. Cependant, VDC2 échoue par la suite. L’utilisateur restaure alors VDC2 avec la copie qu’il a faite sur le VHD USN 200. Après cela, l’utilisateur fait une autre mise à jour sur VDC2 pour une nouvelle version des USNs 201-355. DC1 demande des changements supérieurs à USN 350 de VDC2 et se fait répliquer parce que l’USN sur VDC2 est plus élevé que sur DC1. Cependant, la nouvelle version des USNs 201 à 350 n’est pas la même que celle sur DC1, causant un USN rollback.

Résoudre les problèmes liés à l’ID d’événement 2095

Si vous voyez l’événement ID 2095 dans le journal d’événements du service d’annuaire, suivez immédiatement ces instructions :

1. Isolez du réseau la machine virtuelle qui a enregistré l’erreur.

2. Vérifiez si les changements signalés proviennent de ce DC et se sont propagés à d’autres DCs. Si l’événement est le résultat de l’utilisation d’une capture ou d’une copie d’une VM, essayez de déterminer quand l’USN rollback s’est produit. Une fois que vous avez le moment, vous pouvez vérifier les partenaires de réplication de ce DC pour déterminer si une réplication a eu lieu après le rollback.

   Vous pouvez utiliser l’outil Repadmin pour vérifier d’où viennent les changements. Pour plus d’informations sur l’utilisation de Repadmin, consultez l’article Utiliser Repadmin pour surveiller et résoudre les problèmes associés à de la réplication Active Directory (uniquement disponible en anglais pour le moment). Si vous ne pouvez pas le déterminer par vous-même, contactez le Support Microsoft pour obtenir de l’aide.

3. Procédez à une rétrogradation forcée du contrôleur de domaine. Cette opération implique le nettoyage des métadonnées du DC et la saisie des rôles de maître d’opérations, également connus sous le nom de rôles FSMO (Flexible Single Master Operations). Pour plus d’informations, veuillez consulter la section Récupération après un USN rollback.

4. Supprimez tous les anciens fichiers VHD du contrôleur de domaine.

Restauration USN non détectée

Le DC est susceptible de ne pas détecter un USN rollback dans les scénarios suivants :

• Le fichier VHD est joint à d’autres machines virtuelles exécutées simultanément dans plusieurs emplacements.

• L’USN sur le DC restauré a augmenté au-delà du dernier USN reçu par l’autre DC.

Dans le scénario du fichier VHD, d’autres DCs pourraient se répliquer avec l’une ou l’autre des VMs, et des changements pourraient survenir sur l’une ou l’autre VM sans être répliqués sur l’autre. Cette divergence dans la forêt est difficile à détecter et entraîne des réactions imprévisibles de l’annuaire. Une telle situation peut se produire à la suite d’une migration P2V si l’ordinateur physique et la machine virtuelle sont exécutés sur le même réseau. Elle peut également avoir lieu si plusieurs contrôleurs de domaine virtuels sont créés à partir du même contrôleur de domaine physique, puis exécutés sur le même réseau.

Dans le scénario d’USN, une plage d’USNs s’applique à deux ensembles différents de changements. Une telle situation peut se produire sur de longues périodes sans être détectée. Lorsque vous modifiez un objet que vous avez créé pendant cette période, le système détecte un objet résiduel et le signale comme l’événement ID 1988 dans le Visualiseur d’événements. Le diagramme suivant montre pourquoi le DC pourrait ne pas détecter l’USN rollback dans ce scénario.

Diagramme qui montre un organigramme pour le processus de détection de rollback dans un exemple de build. Il y a deux contrôleurs de domaine étiquetés « VDC1 » et « DC2 ». La première étape de l’organigramme montre le DC virtuel, VDC1, prendre un instantané lorsque son USN est 2000. Après l’instantané, VDC1 crée 100 utilisateurs, et le VDC1 mis à jour a maintenant un USN de 2100. Les mises à jour sur VDC1 se répliquent sur DC2, qui partage maintenant l’USN de 2100. Cependant, le VDC1 utilise ensuite l’instantané qu’il a pris pour revenir à sa version USN 2000. La version revenue de VDC1 crée 150 nouveaux utilisateurs, ce qui porte son USN à 2150. Le VDC1 mis à jour se réplique sur DC2, mais DC2 ne détecte pas les changements incompatibles parce que son USN est plus élevé que l’USN de DC2 de 2100. Le texte en bas dit, « USN rollback non détecté », ce qui résulte en une divergence non détectée où les USNs 2001 à 2100 ne sont pas les mêmes entre les deux contrôleurs de domaine.

Contrôleurs de domaine en lecture seule

Les contrôleurs de domaine en lecture seule (RODC) sont des DCs qui hébergent des copies en lecture seule des partitions dans une base de données Active Directory. Les RODC contribuent à éviter la plupart des problèmes de restauration USN, car ils ne répliquent pas les modifications sur les autres contrôleurs de domaine. Cependant, si un RODC se réplique à partir d’un DC inscriptible affecté par un USN rollback, le rollback affecte également le RODC.

Nous ne recommandons pas d’utiliser un instantané pour restaurer un RODC. Vous devez uniquement restaurer un RODC en utilisant une application de sauvegarde compatible avec Active Directory. Aussi, comme avec les DCs inscriptibles, vous ne devez pas permettre à un RODC d’être hors ligne pendant plus que la durée de vie de l’objet effacé. Cette condition pourrait en effet entraîner la présence d'objets en attente sur le RODC.

Pour plus d’informations sur l’implémentation des contrôleurs de domaine, consultez le guide détaillé sur les contrôleurs de domaine en lecture seule.

Contenu supplémentaire

Apprenez comment restaurer des DCs virtualisés dans la rubrique Restaurer des contrôleurs de domaine virtualisés.