Erreur de réplication Active Directory 8524 : L’opération DSA ne peut pas continuer 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.

Numéro de base de connaissances d’origine : 2021446
S’applique à : toutes les versions prises en charge de Windows Server

Utilisateurs à domicile : cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous recherchez de l’aide sur un problème, demandez à la Communauté Microsoft.

Symptômes

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

   Serveur de test : <contrôleur de domaine de destination sitename><>
   Test de démarrage : 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 l’échec de la partition> de répertoire,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 l’état 8524.

   Les commandes REPADMIN qui citent généralement l’état 8524 incluent, mais ne sont pas limitées aux éléments suivants :

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

   Un exemple de 8524 échecs de REPADMIN /SHOWREPL est illustré ci-dessous :

   Default-First-Site-Name\CONTOSO-DC1
   Options DSA : IS_GC
   Options de site : (aucun)
   GUID de l’objet DSA : DSA invocationID :
   DC=contoso,DC=com
   Default-First-Site-Name\CONTOSO-DC2 via RPC
   GUID de l’objet DSA :
   La dernière tentative @ AAAA-MM-DD HH :MM :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 échecs consécutifs.
   Dernier succès @ AAAA-MM-DD HH :MM :SS.

   Reste de la sortie /showrepl tronquée

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

   • Vérificateur de cohérence des connaissances NTDS (KCC)
   • Général NTDS
   • Microsoft-Windows-ActiveDirectory_DomainService

   Les événements Active Directory qui citent généralement l’état 8524 incluent, mais ne sont pas limités aux éléments suivants :

   Événement	Origine	Chaîne d’événements
   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 d’annuaire suivante
   Général NTDS	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é constamment.
   NTDS KCC	1,865	Le KCC n’a pas pu former une topologie de réseau d’arborescence complète. Par conséquent, la liste suivante de sites ne peut pas être atteinte à partir du site local
   NTDS KCC	1925	Échec de la tentative d’établissement d’un lien de réplication pour la partition d’annuaire accessible en écriture suivante.
   NTDS KCC	19:26	La tentative d’établissement d’un lien de réplication vers une partition de répertoire en lecture seule avec les paramètres suivants a échoué

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 le journal des événements du service d’annuaire :

   Nom du journal : service d’annuaire
   Source : Microsoft-Windows-ActiveDirectory_DomainService
   Date : <date><d’heure>
   ID d’événement : 2087
   Catégorie de tâche : client RPC DS
   Niveau : Erreur
   Mots clés : Classique
   Utilisateur : LOGON ANONYME
   Ordinateur : <nom> dc.<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 de services de domaine Active Directory de 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. Elle affecte potentiellement l’authentification d’ouverture de session et l’accès aux ressources réseau.

   Nom du journal : service d’annuaire
   Source : Microsoft-Windows-ActiveDirectory_DomainService
   Date : <date><d’heure>
   ID d’événement : 2088
   Catégorie de tâche : client RPC DS
   Niveau : Avertissement
   Mots clés : Classique
   Utilisateur : LOGON ANONYME
   Ordinateur : <nom> dc.<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 répertorié 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 de NetBIOS ou du nom d’ordinateur complet du contrôleur de domaine source.

   La 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 de cette forêt services de domaine Active Directory, y compris l’authentification d’ouverture de session 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.

La 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 catch-all pour toutes les défaillances DNS possibles affectant Active Directory sur les contrôleurs de domaine Windows Server 2003 SP1 post.

Microsoft-Windows-ActiveDirectory_DomainService événement 2087 est un événement partenaire à d’autres événements Active Directory qui citent l’état 8524 si un contrôleur de domaine Active Directory ne peut pas résoudre un contrôleur de domaine distant par son enregistrement CNAME complet (<guid d’objet pour l’objet> Paramètres NTDS source DCs._msdcs.<domaine> racine de forêt) à l’aide du DNS.

Microsoft-Windows-ActiveDirectory_DomainService l’événement 2088 est enregistré lorsqu’un contrôleur de domaine source est correctement résolu par son nom NetBIOS, mais que ce type de secours de résolution de noms se produit uniquement lorsque la résolution de noms DNS échoue.

La présence de l’état 8524 et de l’événement Microsoft-Windows-ActiveDirectory_DomainService 2088 ou 2087 indiquent que la résolution de noms DNS échoue dans Active Directory.

En résumé, l’état de la réplication 8524 est enregistré lorsqu’un contrôleur de domaine de destination ne peut pas résoudre le contrôleur de domaine source par ses enregistrements CNAME et Host « A » ou Host « AAAA » à l’aide du 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ôte sur un ou plusieurs serveurs DNS pour les raisons suivantes :

   • Échec des tentatives d’inscription.
   • 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 son _msdcs.<zone de domaine racine de forêt et (ou) zones de domaine 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 les enregistrements CNAME ou hôte pour le contrôleur de domaine source

4. CNAME et les enregistrements hôtes 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 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érifiez si la version 8524 est causée par un contrôleur de domaine hors connexion ou des métadonnées dc 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 des contrôleurs de domaine de destination d’Active Directory. Un contrôleur de domaine inactif est une installation dc 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 -

Microsoft prend régulièrement en charge les métadonnées obsolètes pour les contrôleurs de domaine inexistants ou les métadonnées obsolètes d’un contrôleur de domaine dont le nom d’ordinateur n’a pas été supprimé d’Active Directory.

Supprimer les métadonnées de contrôleur de domaine obsolètes s’il est présent

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

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

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

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

   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 journalisation 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 NTDS Settings NTDS 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 Paramètres NTDS DCs 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 surbrillance rouge dans la capture d’écran ci-dessous montre l’objet Paramètres NTDS pour CONTOSO-DC2 situé sous le site Default-First-Site-Name.

   

   Cliquez avec le bouton droit sur l’objet Paramètres NTDS 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 tel qu’il est documenté 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 Nettoyer les métadonnées du serveur de contrôleur domaine Active Directory.

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 les informations d’identification d’administrateur d’entreprise à la console des contrôleurs de domaine de destination qui journalise les événements 8524.

2. Ouvrez une invite CMD privilégiée d’administration, puis exécutez DCDIAG /TEST:DNS /F sur le contrôleur de domaine qui journalisera l’état 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 le tableau de synthèse à 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, prenez « 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 d’objet de l’objet paramètres NTDS distants (objet parent pour les 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 source d’Active Directory.

   À partir de la console du contrôleur de domaine source qui journalisation l’erreur/é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/événement 8524 est contoso-DC2 dans le contoso.com domaine, tapez :

   repadmin /showrepl contoso-dc2.contoso.com

   Le champ « GUID de l’objet DSA » dans l’en-tête de la repadmin /SHOWREPl commande contient l’objectGUID de l’objet de paramètres NTDS actuel des contrôleurs de domaine source. Utilisez la vue source des contrôleurs de domaine de son objet paramètres NTDS au cas où la réplication était lente ou défaillante. L’en-tête de la repadmin sortie ressemble à ceci :

   Default-First-Site-Name\CONTOSO-DC1
   Options DSA : IS_GC
   Options de site : (aucun)
   GUID de l’objet DSA : 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- cliquez avec le bouton droit + copiez cette chaîne dans Windows
   <- Presse-papiers & collez-y la commande PING dans
   <- étape 4

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

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

   repadmin /showrepl <fully qualified hostname of destination DC>

   Par exemple, si l’erreur/é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 indiqué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 de destination est répliqué.

    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 de #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, chiffrez celui qui a été créé ultérieurement. L’objet de paramètre NTDS avec la date de création précédente 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 des contrôleurs de domaine sources complets CNAME :

   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’objet 8a7baee5... objectGUID de la repadmin /showreps sortie ci-dessus à partir du contrôleur de domaine contoso-dc1 dans le contoso.com domaine, la syntaxe PING serait :

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

   Si le test ping fonctionne, réessayez l’opération défaillante dans Active Directory. En cas d’échec ping, passez à « Résoudre l’échec de recherche DNS 8524 », mais réessayez le test PING après chaque étape jusqu’à ce qu’elle soit résolue.

Résoudre l’échec de recherche DNS 8524 : long chemin autour

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 des éléments suivants :

• 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 sources sont résolvables par les contrôleurs de domaine de destination.

Le texte du message d’erreur dans l’événement client RPC DS 2087 documente une action 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 les 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 inscrire des enregistrements CNAME dans the_msdcs.contoso.com zone)

   ET

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

   ET

   Le domaine de suffixe DNS principal des ordinateurs 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 (c’est-à-dire « peut résoudre ») de telles zones.

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

   • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS que le contrôleur de domaine source pointe 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 serait :

     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. Elle ne se résout pas correctement si le _msdcs.<la zone> racine de forêt sur le serveur DNS interrogé est un sous-domaine non délégué de 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 pointer vers un serveur DNS ISP pour la résolution de noms n’est pas valide. La seule exception est que l’ISP a été contracté (c’est-à-dire payant) et héberge actuellement, transfère ou délègue des requêtes DNS pour votre forêt Active Directory.
   • Les serveurs DNS ISP n’acceptent généralement pas les mises à jour DNS dynamiques, de sorte que les enregistrements CNAME, Host et SRV doivent ê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 les serveurs DNS auxquels 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 l’enregistrement CNAME des contrôleurs de domaine source (trouvé via la procédure « 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 est 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 auxquels il pointe pour la résolution de noms, exécutez la commande suivante à partir du contrôleur de domaine source. Vérifiez ensuite 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 pendant le démarrage du système d’exploitation, le démarrage du service NETLOGON et les intervalles récurrents ultérieurement.
   • Chaque promotion d’un contrôleur de domaine portant le même nom peut créer un objet NTDS Settings avec un objetGUID différent qui inscrit donc un enregistrement CNAME différent. Vérifiez l’inscription de l’enregistrement CNAME en fonction de la dernière promotion du contrôleur de domaine source par rapport à l’objet objectGUID pour l’objet Paramètres NTDS sur le contrôleur de domaine de destination si la source a été promue plus de 1x.
   • Les problèmes de minutage pendant le 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 enregistré, mais disparaît ultérieurement, vérifiez KB953317. Les zones DNS dupliquées dans différentes étendues de réplication ou trop agressives DNS scavenging by the DNS Server.
   • Si l’inscription d’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érifier que le contrôleur de domaine source a inscrit ses enregistrements hôtes

   À partir de la console du contrôleur de domaine source, exécutez ipconfig /all pour déterminer les serveurs DNS auxquels 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 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>
   

   La poursuite de l’exemple de nom d’hôte pour contoso-dc2 dans le domaine contoso.com est 8a7baee5-cd81-4c8c-9c0f-b10030574016 et pointe vers elle-même (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 :

   • Windows 2000 via les ordinateurs 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 inscrits 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.
   • Il n’est pas pris en charge pour désactiver le protocole IPv6 en décochant la case IPv6 dans les propriétés de la 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 en ligne qui hébergent, transfèrent et délèguent le _msdcs.<zone de domaine> racine de forêt (autrement dit, toutes les contrôleurs de domaine dans la forêt contoso.com inscrivent des enregistrements CNAME dans the_msdcs.contoso.com zone).

   ET

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

   ET

   Le domaine de suffixe DNS principal des ordinateurs 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 (c’est-à-dire « peut résoudre ») ces zones sont les suivantes :

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

     OU

   • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS que le contrôleur de domaine source pointe 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 serait

   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. Elle ne se résout pas correctement si the_msdcs.<la zone> racine de forêt sur le serveur DNS interrogé est un sous-domaine non délégué de 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 pointer vers un serveur DNS ISP pour la résolution de noms n’est pas valide. La seule exception est que l’ISP a été contracté (c’est-à-dire payant) et héberge actuellement, transfère ou délègue des requêtes DNS pour votre forêt Active Directory.
   • Les serveurs DNS ISP n’acceptent généralement pas les mises à jour DNS dynamiques. Il est donc possible que les enregistrements CNAME, Host et SRV soient inscrits manuellement.
   • Le programme de résolution DNS sur les ordinateurs Windows est par conception « sticky ». Il utilise des serveurs DNS qui sont réactifs aux requêtes, que ce soit si ces serveurs DNS hébergent, transfèrent ou délèguent les zones requises. Restated, le programme de résolution DNS ne bascule pas et interroge 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ébergez 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 source

   À 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 des contrôleurs de domaine source et des enregistrements hôtes :

   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 GUID 8a7baee5-cd81-4c8c-9c0f-b10030574016 dans le Contoso.com domaine racine de forêt pointe vers les serveurs DNS « 10.45.42.102 » et « 10.45.42.103 ». La syntaxe NSLOOKUP est 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. Passez 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 les copies intégrées à AD source et de destination de l'_msdcs.<zones de suffixe> DNS primaires et <racine> de forêt, recherchez :

   • 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 hébergeant l’enregistrement d’intérêt reste dans différentes étendues de réplication et, par conséquent, 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 primaires et secondaires de zones DNS, recherchez :

   • 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 verte 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, recherchez :

   • Délégations non valides sur le DNS propriétaire de la zone parente qui est délégation à la zone subordonnée.
   • Adresses IP du redirecteur non valides sur le serveur DNS qui tente de résoudre la zone DNS supérieure (par exemple, un contrôleur de domaine dans child.contoso.com essayant de résoudre les enregistrements hôtes dans conto.com zone restant sur les 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.