Erreur de réplication Active Directory 8524 : L’opération DSA ne peut pas se poursuivre en raison d’un échec de recherche DNS

Cet article décrit les symptômes, la cause et les étapes de résolution des opérations AD qui échouent avec l’erreur Win32 8524 :

L’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS.

Applicabilité : Windows 10 - toutes les éditions, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 2021446

Utilisateurs à domicile : Cet article s’adresse uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous recherchez de l’aide pour résoudre un problème, demandez à la communauté Microsoft.

Symptômes

1. DCDIAG signale que le test des réplications Active Directory a échoué avec status 8524 :

   Serveur de test : <sitename><destination DC>
   Démarrage du test : réplications
   [Vérification des réplications,contrôleur< de> domaine de destination] Une tentative de réplication récente a échoué : Du contrôleur de <domaine> source au contrôleur de <domaine de destination>
   Contexte de nommage :
   CN=<Chemin d’accès DN pour la partition> de répertoire défaillante,DC=Contoso,DC=Com
   La réplication a généré une erreur (8524) :
   L’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS.

2. REPADMIN signale qu’une tentative de réplication a échoué avec status 8524.

   Les commandes REPADMIN qui citent couramment le status 8524 incluent, mais ne sont pas limitées à :

   • REPADMIN /REPLSUM
   • REPADMIN /SHOWREPS
   • REPADMIN /SHOWREPL

   Voici un exemple de 8524 échecs de REPADMIN/SHOWREPL :

   Nom du premier site par défaut\CONTOSO-DC1
   Options DSA : IS_GC
   Options du site : (aucune)
   GUID de l’objet DSA : DSA invocationID :
   DC=contoso,DC=com
   Nom du premier site par défaut\CONTOSO-DC2 via RPC
   GUID de l’objet DSA :
   La dernière tentative @ AAAA-MM-JJ HH :MM :SS a échoué, résultat 8524 (0x214c) :
   L’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS.
   1 échec(s) consécutif(s).
   Dernier succès @ AAAA-MM-JJ HH :MM :SS.

   Reste de la sortie /showrepl tronquée

3. L’un des événements suivants avec le status 8524 est enregistré dans le journal des événements du service d’annuaire :

   • NTDS Knowledge Consistency Checker (KCC)
   • NTDS General
   • Microsoft-Windows-ActiveDirectory_DomainService

   Les événements Active Directory qui citent couramment le status 8524 incluent, mais sans s’y limiter :

   Événement	Source	Chaîne d’événement
   Microsoft-Windows-ActiveDirectory_DomainService	2023	Ce serveur d’annuaire n’a pas pu répliquer les modifications apportées au serveur d’annuaire distant suivant pour la partition de répertoire suivante
   NTDS General	1655	Active Directory a tenté de communiquer avec le catalogue global suivant et les tentatives ont échoué.
   NTDS KCC	1308	Le KCC a détecté que les tentatives successives de réplication avec le service d’annuaire suivant ont échoué de manière cohérente.
   NTDS KCC	1865	Le KCC n’a pas pu former une topologie de réseau d’arborescence étendue complète. Par conséquent, la liste suivante de sites n’est pas accessible à partir du site local
   NTDS KCC	1925	La tentative d’établissement d’un lien de réplication pour la partition de répertoire accessible en écriture suivante a échoué.
   NTDS KCC	1926	Échec de la tentative d’établissement d’un lien de réplication vers une partition de répertoire en lecture seule avec les paramètres suivants

4. Les contrôleurs de domaine journalisent l’événement de réplication NTDS 2087 et l’événement de réplication NTDS 2088 dans leur journal des événements du service d’annuaire :

   Nom du journal : Service d’annuaire
   Source : Microsoft-Windows-ActiveDirectory_DomainService
   Date : <date><et heure>
   ID d’événement : 2087
   Catégorie de tâche : Client RPC DS
   Niveau : Erreur
   Mots clés : classique
   Utilisateur : OUVERTURE DE SESSION ANONYME
   Ordinateur : <nom du contrôleur de domaine>.<nom de domaine>
   Description :

   services de domaine Active Directory n’a pas pu résoudre le nom d’hôte DNS suivant du contrôleur de domaine source en adresse IP. Cette erreur empêche les ajouts, les suppressions et les modifications dans services de domaine Active Directory de se répliquer entre un ou plusieurs contrôleurs de domaine dans la forêt. Les groupes de sécurité, la stratégie de groupe, les utilisateurs et les ordinateurs et leurs mots de passe sont incohérents entre les contrôleurs de domaine jusqu’à ce que cette erreur soit résolue. Cela affecte potentiellement l’authentification de connexion et l’accès aux ressources réseau.

   Nom du journal : Service d’annuaire
   Source : Microsoft-Windows-ActiveDirectory_DomainService
   Date : <date><et heure>
   ID d’événement : 2088
   Catégorie de tâche : Client RPC DS
   Niveau : Avertissement
   Mots clés : classique
   Utilisateur : OUVERTURE DE SESSION ANONYME
   Ordinateur : <nom du contrôleur de domaine>.<nom de domaine>
   Description :
   services de domaine Active Directory n’avez pas pu utiliser DNS pour résoudre l’adresse IP du contrôleur de domaine source listé ci-dessous. Pour maintenir la cohérence des groupes de sécurité, de la stratégie de groupe, des utilisateurs et des ordinateurs et de leurs mots de passe, services de domaine Active Directory correctement répliqué à l’aide du nom netBIOS ou complet du contrôleur de domaine source.

   Une configuration DNS non valide peut affecter d’autres opérations essentielles sur les ordinateurs membres, les contrôleurs de domaine ou les serveurs d’applications dans cette forêt services de domaine Active Directory, notamment l’authentification de connexion ou l’accès aux ressources réseau.

   Vous devez résoudre immédiatement cette erreur de configuration DNS afin que ce contrôleur de domaine puisse résoudre l’adresse IP du contrôleur de domaine source à l’aide de DNS.

Cause

L’état d’erreur 8524 correspond à la chaîne d’erreur suivante :

L’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS.

Il s’agit d’une erreur fourre-tout pour toutes les défaillances DNS possibles affectant Active Directory sur les contrôleurs de domaine Windows Server 2003 SP1.

Microsoft-Windows-ActiveDirectory_DomainServicel’événement 2087 est un événement partenaire d’autres événements Active Directory qui citent le status 8524 si un contrôleur de domaine Active Directory ne parvient pas à résoudre un contrôleur de domaine distant par son enregistrement CNAME complet (<GUID d’objet pour l’objet> DCs NTDS Settings source._msdcs.<domaine> racine de forêt) à l’aide de DNS.

Microsoft-Windows-ActiveDirectory_DomainService L’événement 2088 est journalisé lorsqu’un contrôleur de domaine source est correctement résolu par son nom NetBIOS, mais ce type de secours de résolution de noms se produit uniquement en cas d’échec de la résolution de noms DNS.

La présence du status 8524 et des événements Microsoft-Windows-ActiveDirectory_DomainService 2088 ou 2087 indiquent que la résolution de noms DNS échoue dans Active Directory.

En résumé, le status de réplication 8524 est journalisé lorsqu’un contrôleur de domaine de destination ne peut pas résoudre le contrôleur de domaine source par ses enregistrements CNAME et Hôte « A » ou « AAAA » à l’aide de DNS. Les causes racines spécifiques sont les suivantes :

1. Le contrôleur de domaine source est hors connexion ou n’existe plus, mais son objet NTDS Settings existe toujours dans la copie des contrôleurs de domaine de destination d’Active Directory.

2. Le contrôleur de domaine source n’a pas pu inscrire les enregistrements CNAME ou hôtes sur un ou plusieurs serveurs DNS pour les raisons suivantes :

   • Les tentatives d’inscription ont échoué.
   • Les paramètres du client DNS sur la source ne pointent pas vers les serveurs DNS qui hébergent, transfèrent ou délèguent leurs _msdcs.<zone de domaine racine de forêt et (ou) zones de domaine de suffixe DNS primaires>.

3. Les paramètres du client DNS sur le contrôleur de domaine de destination ne pointent pas vers les serveurs DNS qui hébergent, transfèrent ou délèguent les zones DNS contenant le CNAME ou les enregistrements hôtes pour le contrôleur de domaine source

4. Les enregistrements CNAME et hôte inscrits par le contrôleur de domaine source n’existent pas sur les serveurs DNS interrogés par le contrôleur de domaine de destination pour les raisons suivantes :

   • Latence de réplication simple
   • Échec de la réplication
   • Échec du transfert de zone

5. Redirecteurs ou délégations non valides. Ils empêchent le contrôleur de domaine de destination de résoudre les enregistrements CNAME ou Host pour les contrôleurs de domaine dans d’autres domaines de la forêt.

6. Les serveurs DNS utilisés par le contrôleur de domaine de destination, le contrôleur de domaine source ou les serveurs DNS intermédiaires ne fonctionnent pas correctement.

Résolution

Vérifier si le 8524 est dû à un contrôleur de domaine hors connexion ou à des métadonnées de contrôleur de domaine obsolètes

Si l’erreur/l’événement 8524 fait référence à un contrôleur de domaine actuellement hors connexion, mais toujours valide dans la forêt, rendez-le opérationnel.

Si l’erreur/l’événement 8524 fait référence à un contrôleur de domaine inactif, supprimez les métadonnées obsolètes de ce contrôleur de domaine de la copie d’Active Directory des contrôleurs de domaine de destination. Un contrôleur de domaine inactif est une installation de contrôleur de domaine qui n’existe plus sur le réseau, mais son objet NTDS Settings existe toujours dans la copie des contrôleurs de domaine de destination d’Active Directory :

Le support Microsoft recherche régulièrement des métadonnées obsolètes pour les contrôleurs de domaine inexistants, ou des métadonnées obsolètes provenant des promotions précédentes d’un contrôleur de domaine portant le même nom d’ordinateur que celui qui n’a pas été supprimé d’Active Directory.

Supprimer les métadonnées de contrôleur de domaine obsolètes si elles sont présentes

Nettoyage des métadonnées gui à l’aide de sites et services Active Directory (DSSITE. MSC)

1. Démarrez le composant logiciel enfichable Sites et services Active Directory Windows Server 2008 ou Windows Server 2008 R2 (DSSITE). MSC).

   Vous pouvez également le faire en démarrant les sites et services Active Directory sur un ordinateur Windows Vista ou Windows 7 qui a été installé dans le cadre du package Outils d’administration de serveur distant (RSAT).

2. Focus sur DSSITE. Composant logiciel enfichable MSC sur la copie d’Active Directory des contrôleurs de domaine de destination.

   Après avoir démarré DSSITE. Msc, cliquez avec le bouton droit sur « Sites et services Active Directory [<nom du contrôleur de domaine>]

   Sélectionnez le contrôleur de domaine de destination qui journalt l’erreur/l’événement 8524 dans la liste des contrôleurs de domaine visibles dans « Modifier le contrôleur de domaine... » Liste

3. Supprimez l’objet DCs NTDS Settings source référencé dans les erreurs et événements 8524. Utilisateurs et ordinateurs Active Directory (DSA. Composant logiciel enfichable MSC) et supprimez l’objet DCs NTDS Settings source.

   Un objet DCs NTDS Settings s’affiche

   • Sous le conteneur Sites, Nom du site, Serveurs et %server name%
   • Au-dessus de l’objet de connexion entrant affiché dans le volet droit des sites et services Active Directory.

   La mise en surbrillance rouge de la capture d’écran ci-dessous montre l’objet NTDS Settings pour CONTOSO-DC2 situé sous le site Default-First-Site-Name.

   

   Cliquez avec le bouton droit sur l’objet NTDS Settings obsolète que vous souhaitez supprimer, puis sélectionnez « Supprimer ».

   Le nettoyage des métadonnées peut également être effectué à partir du composant logiciel enfichable W2K8/W2K8 R2 Utilisateurs et ordinateurs Active Directory, comme indiqué dans TECHNET.

Nettoyage des métadonnées de ligne de commande à l’aide de NTDSUTIL

La méthode héritée ou de ligne de commande de suppression d’objets NTDS Settings obsolètes à l’aide de la commande de nettoyage des métadonnées NTDSUTIL est documentée dans MSKB 216498.

Exécuter DCDIAG /TEST:DNS sur le contrôleur de domaine source + contrôleur de domaine de destination

DCDIAG /TEST:DNS effectue sept tests différents pour vérifier rapidement l’intégrité DNS d’un contrôleur de domaine. Ce test n’est pas exécuté dans le cadre de l’exécution par défaut de DCDIAG.

1. Connectez-vous avec Enterprise Administration informations d’identification à la console des contrôleurs de domaine de destination qui enregistrent les événements 8524.

2. Ouvrez une invite CMD d’administration privilégiée, puis exécutez DCDIAG /TEST:DNS /F sur le contrôleur de domaine en journalnant le status 8424 et le contrôleur de domaine source à partir duquel le contrôleur de domaine de destination est répliqué.

   Pour exécuter DCDIAG sur tous les contrôleurs de domaine d’une forêt, tapez DCDIAG /TEST:DNS /V /E /F:<File name.txt>.

   Pour exécuter DCDIAG TEST :DNS sur un contrôleur de domaine spécifique, tapez DCDIAG /TEST:DNS /V /S:<DC NAME> /F:<File name.txt>.

3. Recherchez la table récapitulative à la fin de la DCDIAG /TEST:DNS sortie. Identifiez et rapprochez les conditions d’avertissement ou d’échec sur les contrôleurs de domaine appropriés du rapport.

4. Si DCDIAG n’identifie pas la cause racine, effectuez « le long chemin » en suivant les étapes ci-dessous.

Vérifier la résolution de noms Active Directory à l’aide de PING

Les contrôleurs de domaine de destination résolvent les contrôleurs de domaine sources dans DNS par leurs enregistrements CNAME complets dérivés du GUID de l’objet DCs NTDS Settings distant (l’objet parent des objets de connexion visibles dans le composant logiciel enfichable Sites et services Active Directory). Vous pouvez tester la capacité d’un contrôleur de domaine donné à résoudre un enregistrement CNAME complet du contrôleur de domaine source à l’aide de la commande PING.

1. Recherchez l’objectGUID de l’objet DCs NTDS Settings source dans la copie des contrôleurs de domaine sources d’Active Directory.

   Dans la console du contrôleur de domaine source enregistrant l’erreur/l’événement 8524, tapez :

   repadmin /showrepl <fully qualified hostname of source DC cited in the 8524 error (event)>

   Par exemple, si le contrôleur de domaine référencé dans l’erreur/l’événement 8524 est contoso-DC2 dans le contoso.com domaine, tapez :

   repadmin /showrepl contoso-dc2.contoso.com

   Le champ « GUID d’objet DSA » dans l’en-tête de la repadmin /SHOWREPl commande contient l’objetGUID de l’objet de paramètres NTDS actuel des contrôleurs de domaine source. Utilisez la vue des contrôleurs de domaine sources de son objet paramètres NTDS au cas où la réplication est lente ou échoue. L’en-tête de la repadmin sortie se présente comme suit :

   Nom du premier site par défaut\CONTOSO-DC1
   Options DSA : IS_GC
   Options du site : (aucune)
   GUID de l’objet DSA : 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- cliquez avec le bouton droit + copiez cette chaîne sur Windows
   <- Presse-papiers & y coller la commande PING dans
   <- Étape 4

2. Recherchez l’ObjectGUID du contrôleur de domaine source dans la copie d’Active Directory des contrôleurs de domaine de destination .

   Dans la console du contrôleur de domaine de destination enregistrant l’erreur/l’événement 8524, tapez :

   repadmin /showrepl <fully qualified hostname of destination DC>

   Par exemple, si l’erreur/l’événement de journalisation du contrôleur de domaine 8524 est contoso-DC1 dans le contoso.com domaine, tapez :

   repadmin /showrepl contoso-dc1.contoso.com

   REPADMIN /SHOWREPL la sortie est illustrée ci-dessous. Le champ « GUID d’objet DSA » est répertorié pour chaque contrôleur de domaine source à partir duquel le contrôleur de domaine entrant de destination réplique.

    c:\>repadmin /showreps `contoso-dc1.contoso.com`  
    Default-First-Site-Name\CONTOSO-DC1  
    DSA Options: IS_GC  
    Site Options: (none)  
    DSA object GUID:  
    DSA invocationID:  
     DC=contoso,DC=com  
        Default-First-Site-Name\CONTOSO-DC2 via RPC  
            DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016      <- Object GUID for source DC derived from  
            Last attempt @ 2010-03-24 15:45:15 failed, result 8524 (0x214c):        \ destination DCs copy of Active Directory  
                The DSA operation is unable to proceed because of a DNS lookup failure.
            23 consecutive failure(s).  
            Last success @ YYYY-MM-DD HH:MM:SS.
   

3. Comparez le GUID de l’objet de #2 et #3.

   Si les GUID d’objet sont identiques, le contrôleur de domaine source et le contrôleur de domaine de destination connaissent la même instanciation (la même promotion) du contrôleur de domaine source. S’ils sont différents, déterminez lequel a été créé ultérieurement. L’objet de paramètre NTDS avec la date de création antérieure est probablement obsolète et doit être supprimé.

4. Ping sur le contrôleur de domaine source par son CNAME complet.

   À partir de la console du contrôleur de domaine de destination, testez la résolution de noms d’Active Directory avec un ping de l’enregistrement CNAME complet des contrôleurs de domaine source :

   c:\>ping <ObjectGUID> from source DCs NTDS Settings object._msdcs.<DNS name for Active Directory forest root domain>

   À l’aide de notre exemple de l’objectGUID 8a7baee5... de la repadmin /showreps sortie ci-dessus du contrôleur de domaine contoso-dc1 dans le contoso.com domaine, la syntaxe PING serait la suivante :

   c:\>ping 8a7baee5-cd81-4c8c-9c0f-b10030574016. _msdcs.contoso.com

   Si ping fonctionne, réessayez l’opération ayant échoué dans Active Directory. Si ping échoue, passez à « Résoudre l’échec de recherche DNS 8524 », mais réessayez le test PING après chaque étape jusqu’à ce qu’il soit résolu.

Résoudre l’échec de la recherche DNS 8524 : le long chemin à parcourir

Si l’erreur/les événements 8524 ne sont pas causés par des métadonnées dc obsolètes et que le test PING CNAME échoue, vérifiez l’intégrité DNS de :

• Contrôleur de domaine source
• Contrôleur de domaine de destination
• Serveurs DNS utilisés par les contrôleurs de domaine source et de destination

En résumé, vérifiez que :

• Le contrôleur de domaine source a inscrit les enregistrements CNAME et hôte avec un DNS valide.
• Le contrôleur de domaine de destination pointe vers des serveurs DNS valides.
• Les enregistrements d’intérêt enregistrés par les contrôleurs de domaine source peuvent être résolus par les contrôleurs de domaine de destination.

Le texte du message d’erreur dans l’événement 2087 du client RPC DS documente une action de l’utilisateur pour résoudre l’erreur 8524. Voici un plan d’action plus détaillé :

1. Vérifiez que le contrôleur de domaine source pointe vers des serveurs DNS valides

   Sur le contrôleur de domaine source, vérifiez que les paramètres du client DNS pointent exclusivement vers des serveurs DNS opérationnels qui hébergent, transfèrent ou délèguent the_msdcs.<zone de domaine> racine de forêt (autrement dit, tous les contrôleurs de domaine dans la forêt contoso.com inscrivent les enregistrements CNAME dans the_msdcs.contoso.com zone)

   AND

   Zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com inscrit les enregistrements hôtes dans contoso.com zone).

   AND

   Le domaine de suffixe DNS principal des ordinateurs s’il est différent du nom de domaine Active Directory (voir l’article Technet Disjoint Namespace).

   Les options permettant de vérifier qu’un serveur DNS héberge, transfère ou délègue (autrement dit, peut résoudre) ces zones.

   • Démarrez l’outil de gestion DNS pour votre DNS et vérifiez les serveurs DNS vers lesquels le contrôleur de domaine source pointe pour la résolution de noms héberge les zones en question.

   • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS vers utilisant le contrôleur de domaine source peuvent résoudre les requêtes pour les zones DNS en question.

     Exécuter IPCONFIG /ALL sur la console du contrôleur de domaine source

     c:\>ipconfig /all
     …
     DNS Servers . . . . . . . . . . . : 10.45.42.99 <- Primary DNS Server IP>
                                                10.45.42.101<- Secondary DNS Server IP>
     

     Exécutez les requêtes NSLOOKUP suivantes :

     c:\>nslookup -type=soa  <Source DC DNS domain name> <source DCs primary DNS Server IP >
     c:\>nslookup -type=soa  < Source DC DNS domain name > <source DCs secondary DNS Server IP >
     c:\>nslookup -type=soa  <_msdcs.<forest root DNS domain> <source DCs primary DNS Server IP >
     c:\>nslookup -type=soa  <_msdcs.<forest root DNS domain> <source DCs secondary DNS Server IP >
     

     Par exemple, si un contrôleur de domaine dans le CHILD.CONTOSO.COM domaine de la contoso.com forêt est configuré avec les adresses IP du serveur DNS principal et secondaire « 10.45.42.99 » et « 10.45.42.101 », la syntaxe NSLOOKUP est la suivante :

     c:\>nslookup -type=soa  child.contoso.com 10.45.42.99
     c:\>nslookup -type=soa  child.contoso.com 10.45.42.101
     c:\>nslookup -type=soa  _msdcs.contoso.com 10.45.42.99
     c:\>nslookup -type=soa  _msdcs.contoso.com 10.45.42.101
     

   Remarques :

   • La requête SOA pour la zone _mscs.contoso.com est résolue correctement si le DNS ciblé dispose d’un bon redirecteur ou d’une délégation ou pour the_msdcs.<zone> racine de forêt. Il ne se résout pas correctement si le _msdcs.<la zone> racine de forêt sur le serveur DNS en cours d’interrogation est un sous-domaine non délégué de la zone> racine de <forêt qui est la relation de zone créée par les domaines Windows 2000.
   • Les enregistrements CNAME sont toujours inscrits dans le _msdcs.<zone> racine de forêt, même pour dc dans les domaines non racines.
   • La configuration du client DNS d’un contrôleur de domaine ou d’un ordinateur membre pour qu’il pointe vers un serveur DNS de faip pour la résolution de noms n’est pas valide. La seule exception est que le fournisseur de services Internet a été contracté (c’est-à-dire payant) et qu’il héberge, transfère ou délégue actuellement des requêtes DNS pour votre forêt Active Directory.
   • Les serveurs DNS du fournisseur de services Internet n’acceptent généralement pas les mises à jour DNS dynamiques. Par conséquent, les enregistrements CNAME, Host et SRV peuvent devoir être inscrits manuellement.

2. Vérifiez que le contrôleur de domaine source a inscrit son enregistrement CNAME

   Utilisez l’étape 1 de « Vérifier la résolution de noms Active Directory à l’aide de PING » pour localiser le CNAME actuel du contrôleur de domaine source.

   Exécutez ipconfig /all sur la console du contrôleur de domaine source pour déterminer vers quels serveurs DNS le contrôleur de domaine source pointe pour la résolution de noms.

   c:\>ipconfig /all
   …
   DNS Servers . . . . . . . . . . . : 10.45.42.99                        <primary DNS Server IP
                                              10.45.41.101                      <secondary DNS Server IP
   

   Utilisez NSLOOKUP pour interroger les serveurs DNS actuels pour obtenir l’enregistrement CNAME des contrôleurs de domaine source (trouvé via la procédure dans « Vérifier la résolution de noms Active Directory à l’aide de PING »).

   c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs primary DNS Server IP >
   c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs secondary DNS Server IP>
   

   Dans l’exemple, l’objet NTDS SettingsGUID pour contoso-dc2 dans le domaine contoso.com est 8a7baee5-cd81-4c8c-9c0f-b10030574016. Il pointe vers « 10.45.42.99 » comme principal pour la résolution de noms DNS. La syntaxe NSLOOKUP serait la suivante :

   c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 10.45.42.99
   c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 10.45.42.101
   

   Si le contrôleur de domaine source n’a pas inscrit son enregistrement CNAME sur les serveurs DNS vers 1000 pour la résolution de noms, exécutez la commande suivante à partir du contrôleur de domaine source. Ensuite, revérifier l’inscription de l’enregistrement CNAME :

   c:\>net stop netlogon & net start netlogon
   

   Remarques :

   • Les enregistrements CNAME sont toujours inscrits dans le _msdcs.<zone> racine de forêt, même pour dc dans les domaines non racines.
   • Les enregistrements CNAME sont enregistrés par le service NETLOGON au démarrage du système d’exploitation, au démarrage du service NETLOGON et à intervalles récurrents ultérieurement.
   • Chaque promotion d’un contrôleur de domaine portant le même nom peut créer un nouvel objet NTDS Settings avec un objectGUID différent qui inscrit donc un enregistrement CNAME différent. Vérifiez l’inscription de l’enregistrement CNAME basé sur la dernière promotion du contrôleur de domaine source par rapport à l’objet objectGUID pour l’objet NTDS Settings sur le contrôleur de domaine de destination si la source a été promue plus de 1 fois.
   • Les problèmes de minutage au démarrage du système d’exploitation peuvent retarder la réussite de l’inscription DNS dynamique.
   • Si l’enregistrement CNAME d’un contrôleur de domaine a été correctement inscrit, mais disparaît ultérieurement, case activée KB953317. Dupliquer des zones DNS dans différentes étendues de réplication ou un nettoyage DNS trop agressif par le serveur DNS.
   • Si l’inscription de l’enregistrement CNAME échoue sur les serveurs DNS vers lesquels le contrôleur de domaine source pointe pour la résolution de noms, passez en revue les événements NETLOGN dans le journal des événements SYSTEM pour les échecs d’inscription DNS.

3. Vérifiez que le contrôleur de domaine source a inscrit ses enregistrements d’hôte

   À partir de la console du contrôleur de domaine source, exécutez ipconfig /all pour déterminer vers quels serveurs DNS le contrôleur de domaine source pointe pour la résolution de noms.

   c:\>ipconfig /all
   …
   DNS Servers . . . . . . . . . . . : 10.45.42.99 <- Primary DNS Server IP>
                                              10.45.42.101<- Secondary DNS Server IP>
   

   Utilisez NSLOOKUP pour interroger les serveurs DNS actuels pour l’enregistrement de l’hôte.

   c:\>nslookup -type=A+AAAA  <fully qualified hostname of source DC> <source DCs primary DNS Server IP >
   c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC> <source DCs secondary DNS Server IP>
   

   En suivant l’exemple pour le nom d’hôte de contoso-dc2 dans le domaine contoso.com est 8a7baee5-cd81-4c8c-9c0f-b10030574016 et pointe vers self (127.0.0.1) comme principal pour la résolution de noms DNS, la syntaxe NSLOOKUP serait :

   c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.99
   c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.101
   

   Répétez la commande NSLOOKUP sur l’adresse IP du serveur DNS secondaire des contrôleurs de domaine source.

   Pour inscrire dynamiquement les enregistrements « A » de l’hôte, tapez la commande suivante à partir de la console de l’ordinateur :

   c:\>ipconfig /registerdns
   

   Remarques :

   • Les ordinateurs Windows 2000 à Windows Server 2008 R2 inscrivent tous les enregistrements « A » de l’hôte IPv4.
   • Les ordinateurs Windows Server 2008 et Windows Server 2008 R2 inscrivent tous les enregistrements « AAAA » de l’hôte IPv6.
   • Les enregistrements « A » et « AAAA » de l’hôte sont enregistrés dans la zone de suffixe DNS principale des ordinateurs.
   • Désactivez les cartes réseau qui n’ont pas de câbles réseau attachés.
   • Désactivez l’inscription des enregistrements d’hôte sur les cartes réseau qui ne sont pas accessibles aux contrôleurs de domaine et aux ordinateurs membres sur le réseau.
   • La désactivation du protocole IPv6 n’est pas prise en charge en décochant la case IPv6 dans les propriétés carte réseau.

4. Vérifiez que le contrôleur de domaine de destination pointe vers des serveurs DNS valides

   Sur le contrôleur de domaine de destination, vérifiez que les paramètres du client DNS pointent exclusivement vers les serveurs DNS actuellement en ligne qui hébergent, transfèrent et délèguent les _msdcs.<zone de domaine> racine de forêt (autrement dit, tous les contrôleurs de domaine de la forêt contoso.com enregistrent les enregistrements CNAME dans the_msdcs.contoso.com zone).

   AND

   Zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com inscrit les enregistrements hôtes dans contoso.com zone).

   AND

   Le domaine de suffixe DNS principal des ordinateurs s’il est différent du nom de domaine Active Directory (voir l’article Technet Disjoint Namespace).

   Les options permettant de vérifier qu’un serveur DNS héberge, transfère ou délègue (autrement dit, « peut résoudre ») ces zones sont les suivantes :

   • Démarrez l’outil de gestion DNS pour votre DNS et vérifiez les serveurs DNS vers lesquels le contrôleur de domaine source pointe pour la résolution de noms héberge les zones en question.

     OR

   • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS vers utilisant le contrôleur de domaine source peuvent résoudre les requêtes pour les zones DNS en question.

     Exécutez IPCONFIG /ALL sur la console du contrôleur de domaine de destination :

     c:\>ipconfig /all
     …
     DNS Servers . . . . . . . . . . . : 10.45.42.102 <- Primary DNS Server IP>
                                                           10.45.42.103<- Secondary DNS Server IP>
     

     Exécutez les requêtes NSLOOKUP suivantes à partir de la console du contrôleur de domaine de destination :

     c:\>nslookup -type=soa  <Source DC DNS domain name> <destinatin DCs primary DNS Server IP >
     c:\>nslookup -type=soa  < Source DC DNS domain name > <destination DCs secondary DNS Server IP >
     c:\>nslookup -type=soa  _msdcs.<forest root DNS domain> <destination DCs primary DNS Server IP >
     c:\>nslookup -type=soa  _msdcs.<forest root DNS name> <destination DCs secondary DNS Server IP>
     

   Par exemple, si un contrôleur de domaine dans le domaine CHILD.CONTOSO.COM de la forêt contoso.com est configuré avec les adresses IP du serveur DNS principal et secondaire « 10.45.42.102 » et « 10.45.42.103 », la syntaxe NSLOOKUP est

   c:\>nslookup -type=soa  child.contoso.com 10.45.42.102
   c:\>nslookup -type=soa  child.contoso.com 10.45.42.103
   c:\>nslookup -type=soa  _msdcs.contoso.com 10.45.42.102
   c:\>nslookup -type=soa  _msdcs.contoso.com 10.45.42.103
   

   Remarques :

   • La requête SOA pour la zone _mscs.contoso.com est résolue correctement si le DNS ciblé dispose d’un bon redirecteur ou d’une délégation ou pour the_msdcs.<zone> racine de forêt. Il ne se résout pas correctement si the_msdcs.<la zone> racine de forêt sur le serveur DNS en cours d’interrogation est un sous-domaine non délégué de la zone> racine de <forêt qui est la relation de zone créée par les domaines Windows 2000.
   • Les enregistrements CNAME sont toujours inscrits dans le _msdcs.<zone> racine de forêt, même pour dc dans les domaines non racines.
   • La configuration du client DNS d’un contrôleur de domaine ou d’un ordinateur membre pour qu’il pointe vers un serveur DNS de faip pour la résolution de noms n’est pas valide. La seule exception est que le fournisseur de services Internet a été contracté (c’est-à-dire payant) et qu’il héberge, transfère ou délégue actuellement des requêtes DNS pour votre forêt Active Directory.
   • Les serveurs DNS du fournisseur de services Internet n’acceptent généralement pas les mises à jour DNS dynamiques. Par conséquent, les enregistrements CNAME, Host et SRV peuvent devoir être inscrits manuellement.
   • Le programme de résolution DNS sur les ordinateurs Windows est « collant » par conception. Il utilise des serveurs DNS qui répondent aux requêtes, que ces serveurs DNS hébergent, transfèrent ou délèguent les zones requises. Rétabli, le programme de résolution DNS ne bascule pas et n’interroge pas un autre serveur DNS tant que le DNS actif est réactif, même si la réponse du serveur DNS est « Je n’héberge pas l’enregistrement que vous recherchez ou même héberge une copie de la zone pour cet enregistrement ».

5. Vérifiez que le serveur DNS utilisé par le contrôleur de domaine de destination peut résoudre les enregistrements CNAME et HOST des contrôleurs de domaine sources

   À partir de la console du contrôleur de domaine de destination, exécutez ipconfig /all pour déterminer les serveurs DNS vers lesquels le contrôleur de domaine de destination pointe pour la résolution de noms :

   DNS Servers that destination DC points to for name resolution:
   
   c:\>ipconfig /all
   …
     DNS Servers . . . . . . . . . . . : 10.45.42.102 <- Primary DNS Server IP>
                                                10.45.42.103<- Secondary DNS Server IP>
   

   À partir de la console du contrôleur de domaine de destination, utilisez NSLOOKUP pour interroger les serveurs DNS configurés sur le contrôleur de domaine de destination pour les enregistrements CNAME et hôte des contrôleurs de domaine source :

   c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs primary DNS Server IP >
   c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs secondary DNS Server IP>
   c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs primary DNS Server IP >
   c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs secondary DNS Server IP>
   

   Dans l’exemple, contoso-dc2 dans le domaine contoso.com avec le GUID 8a7baee5-cd81-4c8c-9c0f-b10030574016 dans le domaine racine de la Contoso.com forêt pointe vers les serveurs DNS « 10.45.42.102 » et « 10.45.42.103 ». La syntaxe NSLOOKUP serait la suivante :

   c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 10.45.42.102
   c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 10.45.42.103
   c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.102
   c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.102  
   

6. Passer en revue la relation entre les serveurs DNS utilisés par les contrôleurs de domaine source et de destination

   Si les serveurs DNS utilisés par la source et la destination hébergent des copies intégrées ad du _msdcs.<zones de suffixe> DNS primaire et <racine> de forêt, case activée pour :

   • Latence de réplication entre le DNS où l’enregistrement a été inscrit et le DNS où l’enregistrement est interrogé.
   • Échec de réplication entre le DNS où l’enregistrement est inscrit et le DNS interrogé.
   • La zone DNS qui héberge l’enregistrement d’intérêt reste dans des étendues de réplication différentes et donc dans un contenu différent, ou est CNF/conflict-mangled sur un ou plusieurs contrôleurs de domaine.

   Si les zones DNS utilisées par le contrôleur de domaine source et de destination sont stockées dans des copies principales et secondaires des zones DNS, case activée pour :

   • La case à cocher « Autoriser les transferts de zone » n’est pas activée sur le DNS qui héberge la copie principale de la zone.
   • La case à cocher « Seuls les serveurs suivants » est activée, mais l’adresse IP du DNS secondaire n’a pas été ajoutée à la liste d’autorisation sur le DNS principal.
   • La zone DNS sur le DNS Windows Server 2008 hébergeant la copie secondaire de la zone est vide en raison de KB953317.

   Si les serveurs DNS utilisés par le contrôleur de domaine source et de destination ont des relations parent/enfant, case activée pour :

   • Délégations non valides sur le DNS qui possède la zone parente qui délégue à la zone subordonnée.
   • Adresses IP de redirecteur non valides sur le serveur DNS qui tente de résoudre la zone DNS supérieure (exemple : un contrôleur de domaine dans child.contoso.com tente de résoudre les enregistrements d’hôte dans conto.com zone restant sur des serveurs DNS dans le domaine racine).

Collecte de données

Si vous avez besoin d’aide du support Microsoft, nous vous recommandons de collecter les informations en suivant les étapes mentionnées dans Collecter des informations à l’aide de TSS pour les problèmes de réplication Active Directory.