Aide relative aux tests de clonage des contrôleurs de domaine virtualisés pour les fournisseurs d'applications

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Cette rubrique explique ce que les fournisseurs d’applications doivent prendre en compte pour s’assurer que leur application continue de fonctionner comme prévu une fois le processus de clonage du contrôleur de domaine virtualisé (DC) terminé. Il couvre les aspects du processus de clonage qui intéressent les fournisseurs d’applications et les scénarios qui peuvent justifier des tests supplémentaires. Les fournisseurs d’applications qui ont validé que leur application fonctionne sur des contrôleurs de domaine virtualisés qui ont été clonés sont encouragés à répertorier le nom de l’application dans le contenu de la communauté en bas de cette rubrique, ainsi qu’un lien vers le site web de votre organisation où les utilisateurs peuvent en savoir plus sur la validation.

Vue d’ensemble du clonage de contrôleurs de domaine virtualisé

Le processus de clonage de contrôleur de domaine virtualisé est décrit en détail dans Présentation de la virtualisation des services de domaine Active Directory (AD DS) (niveau 100) et Référence technique du contrôleur de domaine virtualisé (niveau 300). Du point de vue d’un fournisseur d’application, voici quelques considérations à prendre en compte lors de l’évaluation de l’impact du clonage sur votre application :

  • L’ordinateur d’origine n’est pas détruit. Il reste sur le réseau et interagit avec les clients. Contrairement à un renommage où les enregistrements DNS de l’ordinateur d’origine sont supprimés, les enregistrements d’origine du contrôleur de domaine source restent.

  • Pendant le processus de clonage, le nouvel ordinateur s’exécute initialement pendant une courte période sous l’identité de l’ancien ordinateur jusqu’à ce que le processus de clonage soit lancé et apporte les modifications nécessaires. Les applications qui créent des enregistrements sur l’hôte doivent s’assurer que l’ordinateur cloné ne remplace pas les enregistrements concernant l’hôte d’origine pendant le processus de clonage.

  • Le clonage est une fonctionnalité de déploiement spécifique pour les contrôleurs de domaine virtualisés uniquement, et non une extension à usage général permettant de cloner d’autres rôles serveur. Certains rôles serveur ne sont spécifiquement pas pris en charge pour le clonage :

    • Protocole DHCP (Dynamic Host Configuration Protocol)

    • Services de certificats Active Directory (AD CS)

    • Services AD LDS (Active Directory Lightweight Directory Services)

  • Dans le cadre du processus de clonage, la machine virtuelle entière qui représente le contrôleur de domaine d’origine est copiée, de sorte que tout état d’application sur cette machine virtuelle est également copié. Vérifiez que l’application s’adapte à ce changement d’état de l’hôte local sur le contrôleur de domaine cloné, ou si une intervention est nécessaire, telle qu’un redémarrage du service.

  • Dans le cadre du clonage, le nouveau contrôleur de domaine obtient une nouvelle identité de machine et s’approvisionne en tant que contrôleur de domaine réplica dans la topologie. Vérifiez si l’application dépend de l’identité de la machine, comme son nom, son compte, son SID, etc. S’adapte-t-il automatiquement au changement d’identité de la machine sur le clone ? Si cette application met en cache des données, assurez-vous qu’elle ne s’appuie pas sur les données d’identité de l’ordinateur qui peuvent être mises en cache.

Qu’est-ce qui est intéressant pour les fournisseurs d’applications ?

CustomDCCloneAllowList.xml

Un contrôleur de domaine qui exécute votre application ou votre service ne peut pas être cloné tant que l’application ou le service n’est pas :

  • Ajout au fichier CustomDCCloneAllowList.xml à l’aide de l’applet de commande Get-ADDCCloningExcludedApplicationList Windows PowerShell

-Ou-

  • Supprimé du contrôleur de domaine

La première fois que l’utilisateur exécute l’applet de commande Get-ADDCCloningExcludedApplicationList, il retourne une liste de services et d’applications qui s’exécutent sur le contrôleur de domaine, mais qui ne figurent pas dans la liste par défaut des services et applications pris en charge pour le clonage. Par défaut, votre service ou votre application ne sera pas répertorié. Pour ajouter votre service ou votre application à la liste des applications et services qui peuvent être cloné en toute sécurité, l’utilisateur exécute à nouveau Get-ADDCCloningExcludedApplicationList applet de commande avec l’option -GenerateXML afin de l’ajouter au fichier CustomDCCloneAllowList.xml. Pour plus d’informations, consultez Étape 2 : Exécuter l’applet de commande Get-ADDCCloningExcludedApplicationList.

Interactions système distribuées

En règle générale, les services isolés sur l’ordinateur local réussissent ou échouent lors de la participation au clonage. Les services distribués doivent être préoccupés par la présence simultanée de deux instances de l’ordinateur hôte sur le réseau pendant une courte période. Cela peut se manifester en tant qu’instance de service essayant d’extraire des informations d’un système partenaire où le clone s’est inscrit en tant que nouveau fournisseur de l’identité. Ou les deux instances de service peuvent envoyer des informations dans la base de données AD DS en même temps avec des résultats différents. Par exemple, il n’est pas fixe avec quel ordinateur il sera communiqué lorsque deux ordinateurs dotés du service WTT (Windows Testing Technologies) se trouvent sur le réseau avec le contrôleur de domaine.

Pour le service serveur DNS distribué, le processus de clonage évite soigneusement de remplacer les enregistrements DNS du contrôleur de domaine source lorsque le contrôleur de domaine clone démarre avec une nouvelle adresse IP.

Vous ne devez pas compter sur l’ordinateur pour supprimer toute l’ancienne identité jusqu’à la fin du clonage. Une fois le nouveau contrôleur de domaine promu dans le nouveau contexte, sélectionnez Les fournisseurs Sysprep sont exécutés pour nettoyer l’état supplémentaire de l’ordinateur. Par exemple, à ce stade, les anciens certificats de l’ordinateur sont supprimés et les secrets de chiffrement auxquels l’ordinateur peut accéder sont modifiés.

Le facteur le plus important qui varie le moment du clonage est le nombre d’objets à répliquer à partir du contrôleur de domaine principal. Un média plus ancien augmente le temps nécessaire pour terminer le clonage.

Étant donné que votre service ou votre application est inconnu, il reste en cours d’exécution. Le processus de clonage ne modifie pas l’état des services non Windows.

En outre, le nouvel ordinateur a une adresse IP différente de celle de l’ordinateur d’origine. Ces comportements peuvent entraîner des effets secondaires sur votre service ou votre application en fonction de la façon dont le service ou l’application se comporte dans cet environnement.

Scénarios supplémentaires suggérés pour les tests

Échec du clonage

Les fournisseurs de services doivent tester ce scénario, car en cas d’échec du clonage, l’ordinateur démarre en mode de réparation des services d’annuaire (DSRM), une forme de mode sans échec. À ce stade, l’ordinateur n’a pas terminé le clonage. Certains états ont peut-être changé et d’autres peuvent rester à partir du contrôleur de domaine d’origine. Testez ce scénario pour comprendre l’impact qu’il peut avoir sur votre application.

Pour provoquer un échec de clonage, essayez de cloner un contrôleur de domaine sans lui accorder l’autorisation d’être cloné. Dans ce cas, l’ordinateur aura uniquement modifié les adresses IP et aura toujours la majorité de son état à partir du contrôleur de domaine d’origine. Pour plus d’informations sur l’octroi d’une autorisation de cloner un contrôleur de domaine, consultez Étape 1 : Accorder au contrôleur de domaine virtualisé source l’autorisation de cloner.

Clonage d’émulateur PDC

Les fournisseurs de services et d’applications doivent tester ce scénario, car il y a un redémarrage supplémentaire lorsque l’émulateur PDC est cloné. En outre, la majorité du clonage est effectuée sous une identité temporaire pour permettre au nouveau clone d’interagir avec l’émulateur PDC pendant le processus de clonage.

Contrôleurs de domaine accessibles en écriture et en lecture seule

Les fournisseurs de services et d’applications doivent tester le clonage à l’aide du même type de contrôleur de domaine (c’est-à-dire, sur un contrôleur de domaine accessible en écriture ou en lecture seule) sur lequel le service est prévu pour s’exécuter.