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 un problème où les réplications Active Directory échouent avec l’erreur Win32 8524 : « l’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS. »

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

Utilisateurs à domicile : Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous avez besoin d’aide pour résoudre un problème, Posez la question à la communauté Microsoft.

Symptômes

Cet article décrit les symptômes, les causes 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. »

  1. DCDIAG signale que le test de réplication Active Directory a échoué avec l’État 8524 :

    Serveur d’évaluation : <sitename><destination DC>
    Test de démarrage : réplications
    [Vérification des réplications, <destination DC> ] Une tentative de réplication récente a échoué : de <source DC> à <destination DC>
    Contexte d’appellation :
    CN = <DN path for failing directory partition> , 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.

    REPADMIN les commandes qui citent communément l’État 8524 incluent notamment :

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

    Vous trouverez ci-dessous un exemple de 8524 échecs à partir de REPADMIN/SHOWREPL :

    Default-First-Site-Name\CONTOSO-DC1
    Options DSA : IS_GC
    Options de site : (aucune)
    GUID de l’objet DSA : identificateur d’invocation DSA :
    DC = contoso, DC = com
    Default-First-Site-Name\CONTOSO-DC2 via RPC
    GUID de l’objet DSA :
    Dernière tentative @ YYYY-MM-DD HH : MM : SS failed, result 8524 (0x214c) :
    L’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS.
    1 échec (s) consécutif (s).
    Dernière réussite @ YYYY-MM-DD HH : MM : SS.

    Reste de la sortie/showrepl tronquée

  3. Les événements KCC NTDS, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService avec l’État 8524 sont consignés dans le journal des événements du service d’annuaire.

    Les événements Active Directory qui citent communément l’État 8524 incluent notamment :

    É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 sur le serveur d’annuaire distant suivant pour la partition d’annuaire suivante

    NTDS général 1655 Active Directory a tenté de communiquer avec le catalogue global suivant et les tentatives ont échoué.

    KCC NTDS 1308 Le vérificateur de cohérence des connaissances (KCC) a détecté que les tentatives successives de réplication avec le service d’annuaire suivant ont échoué.

    KCC NTDS 1865 Le vérificateur de cohérence des connaissances (KCC) n’a pas pu former une topologie de réseau à arborescence complète. Par conséquent, la liste de sites suivante est inaccessible à partir du site local.

    KCC NTDS 1925 Échec de la tentative d’établissement d’un lien de réplication pour la partition d’annuaire inscriptible suivante.

    KCC NTDS 1926 Échec de la tentative d’établissement d’un lien de réplication vers une partition d’annuaire en lecture seule avec les paramètres suivants :

  4. Les contrôleurs de domaine consignent les événements de réplication NTDS 2087 et/ou 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><time>
    ID d’événement : 2087
    Catégorie de tâche : client DS RPC
    Level : erreur
    Mots-clés : classique
    Utilisateur : ouverture de session anonyme
    Ordinateur : <dc name> .<domain name>
    Description :

    Les services de domaine Active Directory n’ont 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 apportées aux 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, ce qui pourrait affecter l’authentification de connexion et l’accès aux ressources réseau.

    Reste de l’événement tronqué, reportez-vous à la rubrique MSKB 824449 for Full Text.

    Nom du journal : service d’annuaire
    Source : Microsoft-Windows-ActiveDirectory_DomainService
    Date : <date><time>
    ID d’événement : 2088
    Catégorie de tâche : client DS RPC
    Level : Warning
    Mots-clés : classique
    Utilisateur : ouverture de session anonyme
    Ordinateur : <dc name> .<domain name>
    Description :

    Les services de domaine Active Directory n’ont pas pu utiliser DNS pour résoudre l’adresse IP du contrôleur de domaine source mentionné 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, les services de domaine Active Directory ont correctement répliqués à l’aide du nom d’ordinateur 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 de cette forêt des services de domaine Active Directory, y compris l’authentification de connexion ou l’accès aux ressources réseau.

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

    Reste de l’événement tronqué, reportez-vous à la rubrique MSKB 824449 for Full Text.

Cause

L’état d’erreur 8524 correspond à la chaîne d’erreur « l’opération DSA ne peut pas continuer en raison d’un échec de recherche DNS. » Il s’agit d’une erreur de rattrapage pour tous les échecs DNS possibles affectant Active Directory sur les contrôleurs de domaine post Windows Server 2003 SP1.

L’événement Microsoft-Windows-ActiveDirectory_DomainService 2087 est un événement partenaire pour d’autres événements Active Directory qui citent l’État 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 ( <object guid for source DCs NTDS Settings object> ._msdcs <forest root domain> ).

L’événement Microsoft-Windows-ActiveDirectory_DomainService 2088 est journalisé lorsqu’un contrôleur de domaine source est résolu avec succès par son nom NetBIOS mais que la résolution de nom de secours se produit uniquement lorsque la résolution de noms DNS échoue.

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

En résumé, l’état de réplication 8524 est enregistré lorsqu’un contrôleur de domaine de destination ne parvient pas à résoudre le contrôleur de domaine à l’aide de son enregistrement CNAMe et héberge des enregistrements « A » ou « AAAA » de l’hôte à l’aide de DNS. Les causes racines spécifiques sont les suivantes :

  1. Le contrôleur de périphérique source est hors connexion ou n’existe plus, mais son objet Paramètres NTDS existe toujours dans la copie des contrôleurs de destination d’Active Directory.
  2. Le contrôleur de domaine source n’a pas pu inscrire les enregistrements CNAMe ou d’hôte sur un ou plusieurs serveurs DNS car les tentatives d’inscription ont échoué ou les paramètres du client DNS sur la source ne pointent pas vers les serveurs DNS qui hébergent, redirigent ou délèguent son _msdcs. <forest root domain zone and (or) primary DNS suffix domain zones> .
  3. Les paramètres de client DNS sur le contrôleur de domaine de destination ne pointent pas vers des serveurs DNS qui hébergent, transfèrent ou délèguent les zones DNS contenant les enregistrements CNAMe ou d’hôte pour le contrôleur de domaine source.
  4. CNAMe et les enregistrements d’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 en raison de la latence de réplication simple, d’un échec de réplication ou d’un échec de transfert de zone.
  5. Les redirecteurs ou les délégations non valides empêchent le contrôleur de domaine de destination de résoudre des enregistrements CNAMe ou d’hôte pour des 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 provoqué par un contrôleur de contexte de périphérique ou des métadonnées de contrôleur de ligne périmés

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

Si l’erreur ou l’événement 8524 fait référence à une installation DC inactive qui n’existe plus sur le réseau mais dont l’objet Paramètres NTDS existe toujours dans la copie des DC de destination d’Active Directory, supprimez les métadonnées périmées de ce contrôleur de la copie d’Active Directory des contrôleurs de destination.

Microsoft CSS trouve régulièrement des métadonnées obsolètes pour des contrôleurs de contenu inexistants ou des métadonnées périmées de promotions précédentes d’un contrôleur de contrôleur avec le même nom d’ordinateur qui n’a pas été supprimé d’Active Directory.

Supprimer les métadonnées DC périmées si présentes

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

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

    Vous pouvez également effectuer cette opération 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 des outils d’administration de serveur distant.

  2. Concentrez-vous sur DSSITE. Composant logiciel enfichable MSC sur la copie des DC de destination d’Active Directory.

    Après le démarrage de DSSITE. MSC, cliquez avec le bouton droit sur « sites et services Active Directory » [ <DC Name> ]

    Sélectionnez le contrôleur de domaine de destination qui consigne l’erreur ou l’événement 8524 dans la liste des contrôleurs de domaine visible dans le «modifier le contrôleur de domaine... inscrit

  3. Supprimez l’objet Paramètres NTDS des contrôleurs de code source référencé dans les événements 8524 erreurs et événements. Utilisateurs et ordinateurs Active Directory (DSA. MSC) et supprimez l’objet Paramètres NTDS source DCs.

    Un objet Paramètres NTDS DCs apparaît sous les sites, le nom de site, le conteneur de serveurs et le conteneur% Server Name% et au-dessus de l’objet Connection 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.

    Paramètres NTDS sélectionnés

    Cliquez avec le bouton droit sur l’objet Paramètres NTDS périmés que vous souhaitez supprimer, puis cliquez sur « supprimer ».

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

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

La méthode de ligne de commande héritée ou héritée de suppression d’objets Paramètres NTDS périmés à l’aide de la commande NTDSUTIL metadata cleanup est documentée dans MSKB 216498.

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

DCDIAG/TEST : DNS effectue sept tests différents pour identifier rapidement l’état de 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 à la console des contrôleurs de domaine de destination en consignant les événements 8524 avec les informations d’identification d’administrateur d’entreprise.

  2. Ouvrez une invite CMD avec privilèges d’administration et exécutez «DCDIAG/TEST : DNS/F sur le contrôleur de domaine de journalisation l’État 8424 et le contrôleur de domaine source à partir duquel répliquer le contrôleur de domaine de destination.

    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 type de contrôleur de domaine spécifique "DCDIAG/TEST : DNS/V/S : <DC NAME> /f : <File name.txt> .

  3. Localisez le tableau récapitulatif à la fin de la sortie de DCDIAG/TEST : DNS. Identifier et concilier les conditions d’avertissement ou d’échec sur les contrôleurs de session pertinents du rapport.

  4. Si DCDIAG n’identifie pas la cause première, prenez le temps de suivre 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 en fonction de leurs enregistrements CNAMe complets qui sont dérivés du GUID d’objet de l’objet Paramètres NTDS des contrôleurs de domaine à distance (objet parent aux objets connection visibles dans le composant logiciel enfichable sites et services Active Directory). Vous pouvez tester la capacité d’un contrôleur de base de données pour résoudre un enregistrement CNAMe complet de contrôleur de contrôleur de code source à l’aide de la commande PING.

  1. Localisez le objectGUID de l’objet Paramètres NTDS des DC source dans la copie des contrôleurs de journal source d’Active Directory.

    À partir de la console de la journalisation DC source, erreur/événement 8524, tapez :

    c : \>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 8524 ou l’événement est contoso-DC2 dans le contoso.com domaine, tapez :

    c : \>repadmin/showrepl contoso-dc2.contoso.com

    Le champ « GUID d’objet DSA » de l’en-tête de la commande/SHOWREPl distante contient le objectGUID de l’objet Paramètres NTDS actuel des contrôleurs de domaine source. Utilisez la vue DCs source de son objet Paramètres NTDS en cas de réplication lente/défectueuse. L’en-tête de la sortie de repadmin ressemblera à ceci :

    Default-First-Site-Name\CONTOSO-DC1
    Options DSA : IS_GC
    Options de site : (aucune)
    GUID de l’objet DSA : 8a7baee5-CD81-4c8c-9c0f-b10030574016 <-cliquez avec le bouton droit + copier cette chaîne dans la fenêtre
    <-Clipboard & collez-y la commande PING dans
    <-étape 4

  2. Localisez l’ObjectGUID du contrôleur de périphérique source dans la copie des contrôleurs de destination d’Active Directory.

    À partir de la console de la journalisation DC de destination, erreur/événement 8524, tapez :

    c : \>repadmin/showrepl <fully qualified hostname of destination DC>>

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

    c : \>repadmin/showrepl contoso-dc1.contoso.com

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

     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 à partir de #2 et de #3.

    Si les GUID d’objet sont identiques, le contrôleur de contexte de périphérique de base de contrôle et le contrôleur de périphérique de destination connaissent la même instanciation (la même promotion) du contrôleur de contrôleur de source. S’ils sont différents, déterminez celui qui 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. Exécutez une commande PING sur le contrôleur de contrôleur de source par son nom CNAMe complet.

    À partir de la console du contrôleur de destination, testez la résolution de noms Active Directory avec un PING de l’enregistrement CNAMe complet du contrôleur de contrôleur de code 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 8a7baee5... objectGUID à partir de la sortie de repadmin/showreps ci-dessus du contrôleur de domaine contoso-DC1 dans le contoso.com domaine, la syntaxe ping est la suivante :

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

    Si la commande ping fonctionne, recommencez l’opération qui a échoué dans Active Directory. Si la commande PING échoue, passez à la section « résolution de 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 la recherche DNS 8524 : la solution

Si les erreurs/événements 8524 ne sont pas causés par des métadonnées de DC périmées et que le test PING CNAMe échoue, Vet l’intégrité DNS du contrôleur de domaine source, le contrôleur de domaine de destination et les serveurs DNS utilisés par les contrôleurs de domaine source et de destination. En résumé, vérifiez les éléments suivants :

  • 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 code source peuvent être résolus par des contrôleurs 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. Un plan d’action plus détaillé suit :

  1. Vérifier 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 le serveur DNS opérationnel qui héberge, transfère ou délègue the_msdcs.<forest root domain> zone (autrement dit, tous les contrôleurs de la forêt contoso.com enregistrent des enregistrements CNAMe dans la zone the_msdcs. contoso. com)

    AND

    La zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com enregistrer les enregistrements d’hôte dans la zone contoso.com).

    AND

    Le domaine de suffixe DNS principal des ordinateurs s’il est différent du nom de domaine Active Directory (Voir l' espace de noms disjointde l’article TechNet).

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

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

    • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS vers lesquels pointe 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 périphérique 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 de 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 redirecteur ou d’une délégation corrects ou pour le _msdcs. <forest root zone> . Cette requête ne sera pas résolue correctement si le _msdcs.<forest root zone> sur le serveur DNS interrogé est un sous-domaine non délégué de <forest root zone> qui est la relation de zone créée par les domaines Windows 2000.

    Les enregistrements CNAMe sont toujours enregistrés dans le _msdcs. <forest root zone> , même pour le contrôleur de domaine dans les domaines non racines.

    La configuration du client DNS d’un contrôleur de domaine ou d’un ordinateur membre afin de pointer vers un serveur DNS de fournisseur de services Internet pour la résolution de noms n’est pas valide, sauf si ce dernier a été contracté (c’est-à-dire payant) et s’il héberge, transfère ou délègue des requêtes DNS pour votre forêt Active Directory.

    Les serveurs DNS d’un fournisseur de services Internet n’acceptent généralement pas les mises à jour DNS dynamiques de sorte que les enregistrements CNAMe, hôte et SRV doivent être enregistrés manuellement.

  2. Vérifier que le contrôleur de contexte source a inscrit son enregistrement CNAMe

    Utilisez l’étape 1 de la section « vérifier la résolution de noms Active Directory à l’aide de PING » pour localiser le nom CNAMe actuel du contrôleur de contrôleur de base.

    Exécutez « ipconfig/all » sur la console du contrôleur de domaine source pour déterminer les serveurs DNS vers lesquels 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 sources (trouvé via la procédure dans la section « 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>
    

    Suite à l’exemple où l’objectGUID des paramètres NTDS de contoso-DC2 dans le domaine contoso.com est 8a7baee5-CD81-4c8c-9c0f-b10030574016 et 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 enregistré son enregistrement CNAMe sur les serveurs DNS auxquels il pointe, exécutez la commande suivante à partir de l’invite de commandes du contrôleur de domaine source, puis vérifiez de nouvel enregistrement l’enregistrement CNAMe :

    c:\>net stop netlogon & net start netlogon
    

    Remarques :

    Les enregistrements CNAMe sont toujours enregistrés dans le _msdcs. <forest root zone> , même pour le contrôleur de domaine 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 périodiques plus tard.

    Chaque promotion d’un contrôleur de DC portant le même nom peut créer un objet Paramètres NTDS avec un objectGUID différent qui, par conséquent, enregistre un autre enregistrement CNAMe. Vérifiez l’inscription de l’enregistrement CNAMe en fonction de la dernière promotion du contrôleur de contexte de périphérique (DC) source et de l’objectGUID pour l’objet de paramètres NTDS sur le contrôleur de destination si la source a été promue de plus de 1x.

    Des problèmes de synchronisation pendant le démarrage du système d’exploitation peuvent retarder l’enregistrement DNS dynamique.

    Si un enregistrement CNAMe DCs a été enregistré avec succès mais disparaît plus tard, vérifiez MSKB 953317, les zones DNS en double dans des étendues de réplication différentes ou le nettoyage DNS excessivement agressif par le serveur DNS.

    Si l’enregistrement CNAMe de l’enregistrement échoue sur les serveurs DNS vers lesquels le contrôleur de domaine source pointe pour la résolution de noms, consultez les événements NETLOGN dans le journal des événements système pour les échecs d’enregistrement DNS.

  3. Vérifier que le contrôleur de contrôleur de base a inscrit ses enregistrements d’hôte

    À partir de la console du contrôleur de domaine source, exécutez ipconfig/all afin de déterminer les serveurs DNS vers lesquels 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 d’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 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 est la suivante :

    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 du contrôleur de domaine.

    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 de l’hôte IPv4 « A ».

    Les ordinateurs Windows Server 2008 et Windows Server 2008 R2 inscrivent tous les enregistrements de l’hôte IPv6 « AAAA ».

    Les enregistrements « A » et « AAAA » de l’hôte sont inscrits dans la zone suffixe DNS principal des ordinateurs.

    Désactivez les cartes réseau auxquelles aucun câble réseau n’est connecté.

    Désactivez l’enregistrement des enregistrements d’hôte sur les cartes réseau qui ne sont pas accessibles aux contrôleurs de session et aux ordinateurs membres sur le réseau.

    Il n’est pas possible de désactiver le protocole IPv6 en désactivant la case à cocher IPv6 dans les propriétés de la carte réseau.

  4. Vérifier 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 le serveur DNS actuellement en ligne qui héberge, transfère et délègue le _msdcs.<forest root domain> zone (autrement dit, tous les contrôleurs de la forêt contoso.com enregistrent des enregistrements CNAMe dans la zone the_msdcs. contoso. com).

    AND

    La zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com enregistrer les enregistrements d’hôte dans la zone contoso.com).

    AND

    Le domaine de suffixe DNS principal des ordinateurs s’il est différent du nom de domaine Active Directory (Voir l' espace de noms disjointde l’article TechNet).

    Options permettant de valider le fait 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 que les serveurs DNS vers lesquels le contrôleur de domaine source pointe vers la résolution de noms hébergent les zones en question.

      OR

    • Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS vers lesquels pointe 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 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 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 contexte dans l’enfant. Le domaine 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 sera

    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 redirecteur ou d’une délégation corrects ou pour the_msdcs. <forest root zone> . Cette requête ne sera pas résolue correctement si le _msdcs.<forest root zone> sur le serveur DNS interrogé est un sous-domaine non délégué de <forest root zone> qui est la relation de zone créée par les domaines Windows 2000.

    Les enregistrements CNAMe sont toujours enregistrés dans le _msdcs. <forest root zone> , même pour le contrôleur de domaine dans les domaines non racines.

    La configuration du client DNS d’un contrôleur de domaine ou d’un ordinateur membre afin de pointer vers un serveur DNS de fournisseur de services Internet pour la résolution de noms n’est pas valide, sauf si ce dernier a été contracté (c’est-à-dire payant) et s’il héberge, transfère ou délègue des requêtes DNS pour votre forêt Active Directory.

    Les serveurs DNS d’un fournisseur de services Internet n’acceptent généralement pas les mises à jour DNS dynamiques de sorte que les enregistrements CNAMe, hôte et SRV doivent être enregistrés manuellement.

    La résolution DNS sur les ordinateurs Windows est par conception « rémanente » de l’utilisation des serveurs DNS qui répondent aux requêtes, que ces serveurs DNS hébergent, transfèrent ou délèguent les zones requises. Restated, la résolution DNS ne basculera pas et interroger 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 ».

    La configuration du client DNS d’un contrôleur de domaine ou d’un ordinateur membre pour pointer vers un serveur DNS de fournisseur de services Internet pour la résolution de noms n’est pas valide, sauf si ce dernier a été contracté (c’est-à-dire payant) pour héberger, transférer ou déléguer des requêtes DNS pour votre forêt Active Directory.

  5. Vérifier que le serveur DNS utilisé par le contrôleur de domaine de destination peut résoudre les enregistrements d’hôte et CNAMe 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 pointe le contrôleur de domaine 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 d’hôte et CNAME des contrôleurs de domaine sources :

    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>
    

    Suite à l’exemple où contoso-DC2 dans le domaine contoso.com avec le GUID 8a7baee5-CD81-4c8c-9c0f-b10030574016 dans le domaine racine de la forêt Contoso.com 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. Examiner 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 de l’hôte source et de destination hébergeant la _msdcs.<forest root> et <primary DNS suffix> zones, vérifiez les éléments suivants :

    • Latence de réplication entre le DNS où l’enregistrement a été enregistré et le DNS dans lequel l’enregistrement est interrogé.
    • Échec de la réplication entre le DNS où l’enregistrement est enregistré et le DNS interrogé.
    • La zone DNS hébergeant l’enregistrement d’intérêts demeure dans des étendues de réplication différentes et, par conséquent, dans différents contenus, ou est de la valeur CNF/en conflit 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, vérifiez les éléments suivants :

    • 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 « uniquement les serveurs suivants » est activée, mais l’adresse IP du serveur DNS secondaire n’a pas été ajoutée à la liste verte sur le serveur DNS principal.
    • La zone DNS sur le DNS Windows Server 2008 hébergeant la copie secondaire de la zone est vide en raison du MSKB 953317.

    Si les serveurs DNS utilisés par le contrôleur de domaine source et de destination ont des relations parent/enfant, vérifiez les éléments suivants :

    • Délégations non valides sur le DNS qui possède la zone parente qui est propriétaire de la zone secondaire.
    • Des adresses IP de redirecteur non valides sur le serveur DNS essaient de résoudre la zone DNS supérieure (par exemple : un contrôleur de domaine dans child.contoso.com qui tente de résoudre les enregistrements d’hôte dans la zone conto.com restent sur les serveurs DNS dans le domaine racine).