Meilleur auteur de réponses
Problème application de GPO

Question
-
Bonjour à toutes et tous,
Je viens vers vous afin d'avoir de l'aide sur une problématique que je rencontre chez un de mes clients concernant l’application de GPO.
Nous avons la configuration suivante chez le client :
- 1 serveur AD sous Windows 2012 R2 ;
- 1 serveur TSE sous Windows 2012 R2 ;
La GPO consiste à déplacer les dossiers des profils utilisateurs sur le second disque dur présent sur le serveur TSE.
Cette GPO jusqu'à présent fonctionner, toutefois, ce n'est plus le cas du jour au lendemain.
Lorsque je fais un GPUPDATe /FORCE depuis le TSE voici le résultat :
Dans le journal des évènements, l'erreur est la suivante :
En réalisant un NSLOOKUP depuis le serveur TSE vers le serveur AD, le résultat est le suivant :
J'ai également fait la même chose depuis le serveur AD :
Il ne s'agit donc pas d'un problème de résolution de nom comme l'indique le message d'erreur d'origine.
Il n'y a pas non plus de second AD sur le réseau.
J'ai suivi les différentes pistes disponibles sur les différents forums, sites, etc., mais sans succès.
Quelqu'un a-t-il une idée afin de résoudre ma problématique ?
Je vous remercie par avance de vos retours.
Réponses
-
Bonjour,
Je vous remercie de vos retours.
Je vais faire d'autres tests dans ce sens, mais je pense également faire appel à présent au support Microsoft directement afin de résoudre cette problématique.
Dans tous les cas, je vous remercie de votre temps accorder à mon problème.
Bonne journée.
- Marqué comme réponse COMPTE INACTIF mardi 3 septembre 2019 07:04
- Modifié COMPTE INACTIF mardi 3 septembre 2019 07:05
Toutes les réponses
-
-
Bonjour, Monsieur Barth,
Merci de votre réponse.
Le résultat de la commande DCDIAG est le suivant :
Diagnostic du serveur d'annuaire Exécution de l'installation initiale : Tentative de recherche de serveur associé... Serveur associé : SRV-NOM_CLIENT * Forêt AD identifiée. Collecte des informations initiales terminée. Exécution des tests initiaux nécessaires Test du serveurÿ: Default-First-Site\SRV-NOM_CLIENT Démarrage du test : Connectivity ......................... Le test Connectivity de SRV-NOM_CLIENT a réussi Exécution des tests principaux Test du serveur : Default-First-Site\SRV-NOM_CLIENT Démarrage du test : Advertising ......................... Le test Advertising de SRV-NOM_CLIENT a réussi Démarrage du test : FrsEvent ......................... Le test FrsEvent de SRV-NOM_CLIENT a réussi Démarrage du test : DFSREvent ......................... Le test DFSREvent de SRV-NOM_CLIENT a réussi Démarrage du test : SysVolCheck ......................... Le test SysVolCheck de SRV-NOM_CLIENT a réussi Démarrage du test : KccEvent ......................... Le test KccEvent de SRV-NOM_CLIENT a réussi Démarrage du test : KnowsOfRoleHolders ......................... Le test KnowsOfRoleHolders de SRV-NOM_CLIENT a réussi Démarrage du test : MachineAccount ......................... Le test MachineAccount de SRV-NOM_CLIENT a réussi Démarrage du test : NCSecDesc ......................... Le test NCSecDesc de SRV-NOM_CLIENT a réussi Démarrage du test : NetLogons ......................... Le test NetLogons de SRV-NOM_CLIENT a réussi Démarrage du test : ObjectsReplicated ......................... Le test ObjectsReplicated de SRV-NOM_CLIENT a réussi Démarrage du test : Replications ......................... Le test Replications de SRV-NOM_CLIENT a réussi Démarrage du test : RidManager ......................... Le test RidManager de SRV-NOM_CLIENT a réussi Démarrage du test : Services ......................... Le test Services de SRV-NOM_CLIENT a réussi Démarrage du test : SystemLog ......................... Le test SystemLog de SRV-NOM_CLIENT a réussi Démarrage du test : VerifyReferences ......................... Le test VerifyReferences de SRV-NOM_CLIENT a réussi Exécution de tests de partitions sur ForestDnsZones Démarrage du test : CheckSDRefDom ......................... Le test CheckSDRefDom de ForestDnsZones a réussi Démarrage du test : CrossRefValidation ......................... Le test CrossRefValidation de ForestDnsZones a réussi Exécution de tests de partitions sur DomainDnsZones Démarrage du test : CheckSDRefDom ......................... Le test CheckSDRefDom de DomainDnsZones a réussi Démarrage du test : CrossRefValidation ......................... Le test CrossRefValidation de DomainDnsZones a réussi Exécution de tests de partitions sur Schema Démarrage du test : CheckSDRefDom ......................... Le test CheckSDRefDom de Schema a réussi Démarrage du test : CrossRefValidation ......................... Le test CrossRefValidation de Schema a réussi Exécution de tests de partitions sur Configuration Démarrage du test : CheckSDRefDom ......................... Le test CheckSDRefDom de Configuration a réussi Démarrage du test : CrossRefValidation ......................... Le test CrossRefValidation de Configuration a réussi Exécution de tests de partitions sur NOM_CLIENT Démarrage du test : CheckSDRefDom ......................... Le test CheckSDRefDom de NOM_CLIENT a réussi Démarrage du test : CrossRefValidation ......................... Le test CrossRefValidation de NOM_CLIENT a réussi Exécution de tests d'entreprise sur NOM_CLIENT.local Démarrage du test : LocatorCheck ......................... Le test LocatorCheck de NOM_CLIENT.local a réussi Démarrage du test : Intersite ......................... Le test Intersite de NOM_CLIENT.local a réussi
J'ai bien un partage sur le dossier SYSVOL :
Concernant NETLOGON, quelle vérification puis-je faire ?
Merci par avance de votre retour.
-
Pour vérifier les partages de l'AD il suffit de faire un net share dans une invite de commande
et de vérifier la présence de netlogon et sysvol. Il ne faut surtout pas modifier les partages dans l'image que tu as posté.
Au niveau de l'heure pas de décalage entre les serveurs ?
Tu as configuré la synchro de l'horloge sur l'émulateur PDC ?
-
-
Bonjour,
Les serveurs ont été rebootés ? Depuis le TSE, que donne un nslookup nomdudomaine ?
Les enregistrements DNS concernant l'AD et le TSE sont bons ? une capture d'écran si possible (vous n'aurez sûrement pas l'autorisation de joindre une image, donc utilisez un hébergeur tiers)
-
Bonjour, Spunamo,
Merci de votre retour.
Oui, des redémarrages des serveurs ont eu lieu déjà.
Comme indiquer dans mon message d'origine, les réponses NSLOOKUP depuis le TSE sont correctes.
Les enregistrements DNS concernant l'AD et le TSE également.
- Modifié COMPTE INACTIF mercredi 5 juin 2019 12:47 Erreur de frappe
-
-
En effet, c'était un NSLOOKUP vers l'AD directement.
Le résultat vers le nom de domaine :
C'est un serveur de production, c'est compliqué de faire une telle manipulation sans faire d'arrêt de production.
- Modifié COMPTE INACTIF mercredi 5 juin 2019 15:06 Correction image
-
depuis le ts tu arrives à accéder aux partage netlogon et sysvol avec le nom court, le nom DNS et l'IP ?
\\monDC\netlogon
\\monDC\sysvol
\\monDC.modomaine.local\netlogon
...
\\192.168...\netlogon ?
+
Les DCs n'utilisent pas que l'entregistrement A pour localiser les services, mais également des enregistrements SRV.
Comment sont crée
Quel conf IP sur le DC ? DNS primaire, lui même pas d'autre serveur DNS configuré ?
Sur le DC dcdiag /test:DNS
+
Depuis le DC tu arrives à ouvrir et modifier la GPO ?
\\monDC\netlogon
\\monDC\netlogon
- Modifié Philippe BarthMVP, Moderator mercredi 5 juin 2019 16:29
-
Bonjour, Monsieur Barth,
L'accès aux partages NETLOGON et SYSVOL fonctionne dans l'ensemble des différents tests.
Seule chose, j'ai le dossier NETLOGON qui est vide, mais c'est peut être normal ?
Les DCs n'utilisent pas que l'entregistrement A pour localiser les services, mais également des enregistrements SRV. Comment sont crée
Pardon, mais je n'ai pas compris votre question.
La configuration IP de l'AD est la suivante :
Le résultat du DCDIAG /TEST:DNS est le suivant :
Test du serveur : Default-First-Site\SRV-NOM_CLIENT Démarrage du test : DNS Les tests DNS sont en cours d'exécution et ne sont pas arrêtés. Veuillez patienter quelques minutes... ERROR: NO DNS servers for IPV6 stack was found ......................... Le test DNS de SRV-NOM_CLIENT a réussi Exécution de tests de partitions sur ForestDnsZones Exécution de tests de partitions sur DomainDnsZones Exécution de tests de partitions sur Schema Exécution de tests de partitions sur Configuration Exécution de tests de partitions sur NOM_CLIENT Exécution de tests d'entreprise sur NOM_CLIENT.local Démarrage du test : DNS Résultats des tests des contrôleurs de domaine : Contrôleur de domaine : SRV-NOM_CLIENT.NOM_CLIENT.local Domaine : NOM_CLIENT.local TEST: Records registration (RReg) Carte réseau [00000010] vmxnet3 Ethernet Adapter : Avertissement : Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205 : SRV-NOM_CLIENT.NOM_CLIENT.local Avertissement : Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205 : gc._msdcs.NOM_CLIENT.local Avertissement : Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205 : SRV-NOM_CLIENT.NOM_CLIENT.local Avertissement : Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205 : gc._msdcs.NOM_CLIENT.local Avertissement : inscriptions d'enregistrement introuvables sur certaines cartes réseau SRV-NOM_CLIENT PASS PASS PASS PASS PASS WARN n/a ......................... Le test DNS de NOM_CLIENT.local a réussi
L'édition de la GPO fonctionne depuis l'AD.
-
Bonjour,
Je pense que Philippe BARTH parle des enregistrements DNS situé dans les différents sous domaine de votre domaine. Exemple : _sites.domaine.local
vérifiez chaque sous domaines, et assurez-vous que seul votre AD est présent et qu'il n'y a pas de trace d'un ancien AD par ex.
-
Tu as désactivé IPV6 ? enregistrement AAAA manquant ?
Pardon, mais je n'ai pas compris votre question.
Normal il manque une partie de la phrase :
Explication sur la manière dont sont créés les enregistrements de service (pour information)
A noter que ce n'est pas une bonne idée d'utiliser des plages IPv4 public en interne comme192.120.x.x
- Modifié Philippe BarthMVP, Moderator jeudi 6 juin 2019 15:50
-
Je pense que Philippe BARTH parle des enregistrements DNS situé dans les différents sous domaine de votre domaine. Exemple : _sites.domaine.local
Entre autre, dcdiag /test:dns vérifie les enregistrements de service.
Mais il peut être intéressant de parcourir la zone pour voir s'il n'existe pas des éléments obsolètes.
-
-
-
Bonjour,
Nous vous demandions de contrôler l'état des enregistrements SRV des sous-domaines.
Je vous présente mes excuses concernant le délai de ma réponse.
L'enregistrement des serveurs dans les sous-domaines, c'est bien à cet endroit :
Merci par avance de votre retour.
-
Bonjour,
Tout à fait, contrôlez les enregistrements.
Il vous faut vérifier également dans dc, domains, gc, pdc et leurs sous domaines respectifs.
De plus, à la racine de votre domaine,vous devriez trouver une zone _msdcs ainsi que _sites, _tcp, _udp, _domaindnszones, forestdnszones.
Contrôlez celles-ci également.
- Modifié Spunamo jeudi 20 juin 2019 14:33
-
Très bien, merci de votre retour.
Je vais faire les vérifications dans les sous-dossiers (dc, domains, gc, etc.).
Si mon serveur AD n'est pas présent, je dois le rajouter ?
"De plus, à la racine de votre domaine,vous devriez trouver une zone _msdcs. Contrôlez là également."
Que voulez-vous dire à la racine, c'est à quel emplacement exactement ?
Merci par avance de vos retours.
-
-
Merci de la précision.
J'ai déplié l'ensemble des arborescences afin de faire la vérification.
Il y a bien soit l'adresse IP du serveur qui est présent soit le FQDN.
À noter, je ne sais pas si c'est correct, dans les dossiers du type "_tcp" le FQDN du serveur apparait dans des fichiers du nom tel que "_kerberos" ou "_ldap".
Les enregistrements sont présents à la fois avec de l'IPv4 et de l'IPv6, malgré que l'IPv6 soit désactivé sur l'AD.
-
Tout semble correct.
Les serveurs sont virtuels ou physiques ? Windows Update OK ?
Si vous rebootez les 2 serveurs, l'AD n'affiche pas de message problématique lié au domaine dans son journal d’événement, mais le TSE, si ?
Avez-vous la possibilité de sortir le TSE du domaine et l'y remettre, un soir après la production ? Ou alors de le renommer ?
-
Il s'agit de serveur virtuel sous VMWare.
Je vais faire l'ensemble des mises à jour nécessaires, puis faire le redémarrage des deux serveurs.
En effet, dans l'AD je n'ai pas de message d'erreur, en revanche sur le TSE, oui.
Je vous dirais à la suite du redémarrage.
Concernant la sortie puis l'entrée sur le domaine pour le TSE, je préfère le faire en dernière solution.
-
-
Tu as des erreurs sur des enregistrements DNS, tes zones DNS sont bien intégrés à AD et seul les mises à jours sécurisés sont autorisés ?
exemple _Ldap.tcp.dc. doivent contenir les enregistrements. Si tu as un doutes sur les enregistrements d'un des DCs supprime l'enregistrement et redémarre le service netlogon sur le DC. Au redémarre du service Netlogon un DC recrée tous les enregistrement utiles. _ldap => interroger la base de l'AD _kerberos service d'authentification
plus d'explication :http://www.pbarth.fr/node/35
Sinon dcdiag /test:DNS, tu as des erreurs ??
-
Bonjour,
Avez-vous connaissance d'un autre AD qui aurait été retiré du réseau ?
Quelle est votre conf réseau ? 127.0.0.1 en primary DNS uniquement ?
Quelle est la conf DNS de votre TSE ? uniquement l'ip de l'AD ?
@Philippe, le dcdiag /test:dns a déjà été réalisé, voir plus haut.
-
Bonjour, Monsieur Barth,
Merci de votre retour.
Quand je supprime certain enregistrements et pour suite au redémarrage du service NETLOGON, les enregistrements ne se recréent pas du tout.
Le DCDIAG /test:DNS donne le résultat suivant :
Diagnostic du serveur d'annuaire Exécution de l'installation initialé: Tentative de recherche de serveur associé... Serveur associéé: SRV-NOM_DU_CLIENT * Forêt AD identifiée. Collecte des informations initiales terminée. Exécution des tests initiaux nécessaires Test du serveuré: Default-First-Site\SRV-NOM_DU_CLIENT Démarrage du testé: Connectivity ......................... Le test Connectivity de SRV-NOM_DU_CLIENT a réussi Exécution des tests principaux Test du serveuré: Default-First-Site\SRV-NOM_DU_CLIENT Démarrage du testé: DNS Les tests DNS sont en cours d'exécution et ne sont pas arrêtés. Veuillez patienter quelques minutes... ERROR: NO DNS servers for IPV6 stack was found ......................... Le test DNS de SRV-NOM_DU_CLIENT a réussi Exécution de tests de partitions sur ForestDnsZones Exécution de tests de partitions sur DomainDnsZones Exécution de tests de partitions sur Schema Exécution de tests de partitions sur Configuration Exécution de tests de partitions sur NOM_DU_CLIENT Exécution de tests d'entreprise sur NOM_DU_CLIENT.local Démarrage du testé: DNS Résultats des tests des contrôleurs de domaineé: Contrôleur de domaineé: SRV-NOM_DU_CLIENT.local Domaineé: NOM_DU_CLIENT.local TEST: Records registration (RReg) Carte réseau [00000010] vmxnet3 Ethernet Adapteré: Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: SRV-NOM_DU_CLIENT.local Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: gc._msdcs.NOM_DU_CLIENT.local Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: SRV-NOM_DU_CLIENT.local Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: gc._msdcs.NOM_DU_CLIENT.local Avertissementé: inscriptions d'enregistrement introuvables sur certaines cartes réseau SRV-NOM_DU_CLIENT PASS PASS PASS PASS PASS WARN n/a ......................... Le test DNS de NOM_DU_CLIENT.local a réussi
-
-
Savez-vous si l'ancien AD a été "dépromoté" correctement ? On n'est pas sur un cas du style "j'ai éteints l'AD, on supprime les enregistrements DNS visibles au premier coup d'oeil, et terminé" ?
Dans la conf DNS de votre AD, remplacez l'ip par 127.0.0.1
Si vous lancez un gpupdate /force depuis votre AD, que répond-il ?
-
-
-
-
Vous n'avez pas supprimé accidentellement l'objet ordinateur TSE dans votre AD ?
Que donne le résultat de test.html après la commande (en cmd admin) "gpresult /h test.html" ?
Dans outils d'administration > sites et service Active Directory > déroulez "site-par-défaut" et "servers" : avez-vous un seul serveur d'affiché : votre AD actuel ?- Modifié Spunamo vendredi 21 juin 2019 09:25 ajout dernière question
-
Dans l'AD, j'ai l'ordinateur TSE présent dans une OU à son nom :
En effet, il n'est pas présent dans l'OU "Computers" où j'ai les autres ordinateurs du domaine.
Le résultat dans le rapport est le suivant :
J'ai bien que mon AD dans le sites et service Active Directory. Par contre le NTDS Setting est vide, je ne sais pas si c'est normal :
-
Le NTDS SETTINGS est vide car vous n'avez pas de réplication avec un autre DC, ça me semble OK
Je me focalise sur le message "incohérence de version AD / SYSVOL". Voici le premier résultat google :
Est-ce que la KB3159398 est présente sur l'AD ? et sur le TSE ?
Consultez également ce thread https://social.technet.microsoft.com/Forums/fr-FR/79e5484f-4e07-4eee-964a-df91a47fb16b/incohrence-de-version-ad-sysvol-suite-application-mises-jour-windows-update?forum=windowsserver8fr
- Modifié Spunamo vendredi 21 juin 2019 10:09 deuxième lien ajouté
-
-
Donc l'AD semble bien trouver ses "petits".
Je ne crois pas
Dans le journal du DC il y a des événements qui disent que de enregistrements DNS n'ont pu être crée.
Sur le TS il y a des événements qui disent qu'il ne trouve pas le service d'authentification.
Le group policy indique des erreurs de résolutions de noms.
Zone intégré AD ? Mise à jour sécurisé autorisé (bis) ?
-
Tu as regardé quel enregistrement tu as supprimé, et s'il a été recréé dans la zone ?
Avec les mises à jour sécurisé un ordinateur est propriétaire des enregistrement qu'il a créé. S'il y a un soucis de permission sur cette enregistrement il peut avoir des soucis pour le mettre à jour.
-
-
-
Je suppose qu'avant toutes manips, votre AD est backupé ?
Pour la création de l'enregistrement qui aurait du se faire de façon automatique après le restart du service netlogon, ici un thread traitant du même pb :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DisableDynamicUpdate = 1 is set to 0,
"DisableDynamicUpdate" need to set the value to "0".
Ce qui est étrange dans votre histoire, c'est la façon inopinée dont le pb est apparu : du jour au lendemain.
-
Normalement tu devrais avoir du _ldap qui permet d'intérroger l'annuaire AD et du _kerberos qui permet d'authentifier (ouverture de session). C'est enregistrement sont indispensable !!!
Tu as quoi dans les paramètres de sécurité de ta zone ?
Dans l'état actuel, il n'y a pas de raison de tenter une restauration depuis un backup.
- Modifié Philippe BarthMVP, Moderator vendredi 21 juin 2019 12:09
-
-
Bonjour
Peut etre ce lien vous aidera a trouver le probleme
https://www.it-connect.fr/les-gpo-ne-sappliquent-pas-14-pistes-a-etudier/
- I. Présentation
- II. Les 14 pistes à étudier
- A. Un paramètre non appliqué, vérifiez l’étendue
- B. Le filtre de sécurité
- C. Filtre WMI
- D. Vérifier l’état de la GPO
- E. La délégation
- F. Les héritages : un nid à problèmes...
- G. LSDOU : Kézako ?
- H. Le lien est-il actif ?
- I. Les GPOs « Enforced » - « Appliqué »
- J. Le loopback processing
- K. Attention à la fausse piste...
- L. Le Best Practice Analyzer
- M. L’observateur d’événements
- N. L’outil RSOP
- III. Conclusion
"Marquer comme réponse" les réponses qui ont résolu votre problème
- Modifié Jérôme Sanchez (BLUEINFO) vendredi 21 juin 2019 16:28
-
-
Bonjour, Spunamo,
Le contenu du fichier netlogon est le suivant :
NOM_DU_CLIENT.local. 600 IN A 192.120.0.205 _ldap._tcp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.Default-First-Site._sites.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.gc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 3268 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.Default-First-Site._sites.gc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 3268 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.0a2b3143-0628-4487-b48f-f0f061760cf9.domains._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. gc._msdcs.NOM_DU_CLIENT.local. 600 IN A 192.120.0.205 8b59432f-f043-4962-b879-6cd00540e9cd._msdcs.NOM_DU_CLIENT.local. 600 IN CNAME SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kerberos._tcp.dc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 88 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kerberos._tcp.Default-First-Site._sites.dc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 88 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.dc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.Default-First-Site._sites.dc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kerberos._tcp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 88 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kerberos._tcp.Default-First-Site._sites.NOM_DU_CLIENT.local. 600 IN SRV 0 100 88 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _gc._tcp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 3268 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _gc._tcp.Default-First-Site._sites.NOM_DU_CLIENT.local. 600 IN SRV 0 100 3268 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kerberos._udp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 88 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kpasswd._tcp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 464 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _kpasswd._udp.NOM_DU_CLIENT.local. 600 IN SRV 0 100 464 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. DomainDnsZones.NOM_DU_CLIENT.local. 600 IN A 192.120.0.205 _ldap._tcp.DomainDnsZones.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.Default-First-Site._sites.DomainDnsZones.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. ForestDnsZones.NOM_DU_CLIENT.local. 600 IN A 192.120.0.205 _ldap._tcp.ForestDnsZones.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. _ldap._tcp.Default-First-Site._sites.ForestDnsZones.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local. NOM_DU_CLIENT.local. 600 IN AAAA 2002:c078:cd::c078:cd gc._msdcs.NOM_DU_CLIENT.local. 600 IN AAAA 2002:c078:cd::c078:cd DomainDnsZones.NOM_DU_CLIENT.local. 600 IN AAAA 2002:c078:cd::c078:cd ForestDnsZones.NOM_DU_CLIENT.local. 600 IN AAAA 2002:c078:cd::c078:cd _ldap._tcp.pdc._msdcs.NOM_DU_CLIENT.local. 600 IN SRV 0 100 389 SRV-NOM_DU_CLIENT.NOM_DU_CLIENT.local.
-
-
Bonjour,
Votre fichier netlogon.dns est semblable au mien, on peut considérer que votre DNS contient les enregistrements nécessaires à minima pour l'AD.
Pouvez-vous vérifier les numéros des KB installées le jour J et la veille du problème sur l'AD et le TSE ?
-
Votre fichier netlogon.dns est semblable au mien, on peut considérer que votre DNS contient les enregistrements nécessaires à minima pour l'AD.
Surement pas, soit les enregistrements existe dans la zone DNS soit il n'existe pas, il suffit de vérifier le contenu dans la zone. La zone DNS est stocké dans la partition d'annuaire et non dans ce fichier. S'il n'arrive pas a crée des enregistrements SRV, il y a des erreurs dans l'observateur d'événement. S'il y a des erreurs il est INDISPENSABLE de les corriger.
-
Vérifie aussi que sur système tu as control total
Le fichier Netlogon.dns contient les enregistrements qui devraient existé. Tu peux vérifier ceux qui manque dans ta zone et éventuellement les créer à la main, afin de progresser. Pour ceux qui utilisent des zones DNS non intégrés AD, le fichier netlogon donnent la liste des enregistrements a créer.
- Modifié Philippe BarthMVP, Moderator lundi 24 juin 2019 09:41
-
-
-
-
Je viens de faire les vérifications nécessaires ainsi que la créations des enregistrements manquants.
J'ai également fait un redémarrage du serveur DNS. Malgré ça, quand je fait un NSLOOKUP de ce type :
nslookup _ldap._tcp.dc._msdcs.NOM_DU_CLIENT
J'ai le résultat suivant :
Serveur : localhostAddress: 127.0.0.1*** localhost ne parvient pas à trouver _ldap._tcp.dc._msdcs.NOM_DU_CLIENT : Non-existent domain
Il y a t-il un moyen de repartir d'un DNS propre sans perdre le domaine, etc. ?
-
Il y a t-il un moyen de repartir d'un DNS propre sans perdre le domaine, etc. ?
Dans tous les cas tu ne perds pas le domaine sur une erreur DNS.
Dans le lien que j'ai mis je supprime complètement la zone DNS pour la recréé. Mais je pense que dans l'état actuel le plus simple est de créer manuellement les enregistrements manquant, afin de voir si tu as encore d'autres problèmes.
Une fois l'enregistrement crée il faut que tu vides le cache du serveur DNS(depuis la console dnsmgmt.msc) et le cache du client (ipconfig /flushdns)
-
Bonjour, Monsieur Barth,
J'ai fait la création des enregistrements manquants dans les différentes zones. J'ai vidé le cache DNS depuis la console DNS et via la commande IPCONFIG /flushdns sur le serveur TSE. Malheureusement, le problème est toujours présent.
Dans le journal d'évènement sur le serveur AD, j'ai toujours l'erreur suivante :
Pourtant j'ai bien fait la création de cet enregistrement dans mes zones.
J'ai également refait un NSLOOKUP depuis le serveur TSE et voici le résultat :
Je constate que sur l'interrogation par le nom DNS, le serveur AD répond sur l'IPv6 en priorité.
Pourtant, sur le serveur AD, l'IPv6 n'est pas activé :
Je ne sais pas si cela peut avoir un lien avec mon problème, mais au cas où je vous l'indique.
-
Bonjour,
Et si vous redémarrez le service DNS ?
Concernant votre capture d'écran, cela ne prouve pas qu'IPV6 est désactivé. Voici une doc officielle :
Attention, il est indiqué :
Important Le protocole IPv6 est un élément obligatoire de Windows Vista, Windows Server 2008 et des versions ultérieures de Windows. Nous vous déconseillons de désactiver IPv6 ou ses composants. Si vous le faites, certains composants de Windows risquent de ne plus fonctionner.
-
Bonjour, Spunamo,
Et si vous redémarrez le service DNS ?
Aucun changement, ça fait pareil.
Merci pour le lien, je viens de faire en sorte que l'IPv4 soit prioritaire par rapport à l'IPv6.
Mais je pense qu'un redémarrage du serveur est nécessaire pour que la modification soit prise en compte.
Car depuis le TSE, même après avoir vidé le cache, avec un NSLOOKUP c'est l'IPv6 qui répond en premier.
-
Je ne sais plus ou on est dans les tests ...
Dans ton domaine tu as deux zone importante celle du domaine "domaine.local" et celle de la forêt "_msdcs.mondomaine.local". Ces zones sont gérés par le DC lui même , mais lorsqu'on interroge la zone de la forêt il ne donne pas la bonne réponse alors qu'il fait autorité pour la zone. Netlogon ne crée pas les enregistrement nécessaire dans la zone.
Dans l'image ci dessous tu vois un exemple de la zone de la forêt(encadré bleu). Dans l'encadré orange tu vois la délégation de zone pour le sous domaine _msdcs du domaine domaine.local.
Dans cette délégation de zone à droite, tu dois retrouver le nom de ton serveur (flèche verte). Tu peux vérifier sur ton serveur si c'est information sont à jour ? pas d'ancien serveur qui traine et qui n'existe plus ?
-
-
-
Il s'agit bien du bon serveur, autant au niveau du nom que de l'adresse IP.
- Modifié COMPTE INACTIF mercredi 26 juin 2019 12:12
-
Je suppose qu'avant toutes manips, votre AD est backupé ?
Pour la création de l'enregistrement qui aurait du se faire de façon automatique après le restart du service netlogon, ici un thread traitant du même pb :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DisableDynamicUpdate = 1 is set to 0,
"DisableDynamicUpdate" need to set the value to "0".
Ce qui est étrange dans votre histoire, c'est la façon inopinée dont le pb est apparu : du jour au lendemain.
Je viens d'appliquer ceci, car je ne l'avais pas vue la dernière fois.
Pour faire suite à l'application de cette procédure, j'ai une évolution. Lors je fais un NSLOOKUP de ce type depuis le serveur TSE :
nslookup _ldap._tcp.dc._msdcs.NOM_DU_CLIENT
J'obtiens le résultat suivant :
Serveur : srv-CLIENT.CLIENT.local Address: 192.120.0.205 Nom : _ldap._tcp.dc._msdcs.CLIENT.local
De plus, quand je fait un DCDIAG /test:DNS, le résultat est le suivant :
Diagnostic du serveur d'annuaire Exécution de l'installation initialeé: Tentative de recherche de serveur associé... Serveur associéé: SRV-CLIENT * Forˆt AD identifiée. Collecte des informations initiales terminée. Exécution des tests initiaux nécessaires Test du serveuré: Default-First-Site\SRV-CLIENT Démarrage du testé: Connectivity ......................... Le test Connectivity de SRV-CLIENT a réussi Exécution des tests principaux Test du serveuré: Default-First-Site\SRV-CLIENT Démarrage du testé: DNS Les tests DNS sont en cours d'exécution et ne sont pas arrˆtés. Veuillez patienter quelques minutes... ERROR: NO DNS servers for IPV6 stack was found ......................... Le test DNS de SRV-CLIENT a réussi Exécution de tests de partitions sur ForestDnsZones Exécution de tests de partitions sur DomainDnsZones Exécution de tests de partitions sur Schema Exécution de tests de partitions sur Configuration Exécution de tests de partitions sur NOM_DU_CLIENT Exécution de tests d'entreprise sur NOM_DU_CLIENT.local Démarrage du testé: DNS Résultats des tests des contr“leurs de domaineé: Contr“leur de domaineé: SRV-CLIENT.NOM_DU_CLIENT.local Domaineé: NOM_DU_CLIENT.local TEST: Records registration (RReg) Carte réseau [00000010] vmxnet3 Ethernet Adapteré: Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: SRV-CLIENT.NOM_DU_CLIENT.local Avertissementé: Enregistrement AAAA manquant au niveau du serveur DNS 192.120.0.205é: gc._msdcs.NOM_DU_CLIENT.local Avertissementé: inscriptions d'enregistrement introuvables sur certaines cartes réseau SRV-CLIENT PASS PASS PASS PASS PASS WARN n/a ......................... Le test DNS de NOM_DU_CLIENT.local a réussi
Toutefois, la GPO ne s'applique toujours pas et le message d'erreur est identique :
Mise à jour de la stratégie... La stratégie de l'ordinateur n'a pas pu être mise à jour correctement. Les erreurs suivantes ont été rencontrées : Le traitement de la stratégie de groupe a échoué. Windows n'a pas pu résoudre le nom de l'ordinateur. Cet incident peut avoir une ou plusieurs des causes suivantes : a) Échec de la résolution de nom sur le contrôleur de domaine. b) Latence de réplication Active Directory (un compte créé sur un autre contrôle ur de domaine n'a pas été répliqué sur le contrôleur actuel). La stratégie utilisateur n'a pas pu être mise à jour correctement. Les erreurs suivantes ont été rencontrées : Le traitement de la stratégie de groupe a échoué. Windows n'a pas pu résoudre le nom de l'ordinateur. Cet incident peut avoir une ou plusieurs des causes suivantes : a) Échec de la résolution de nom sur le contrôleur de domaine. b) Latence de réplication Active Directory (un compte créé sur un autre contrôleur de domaine n'a pas été répliqué sur le contrôleur actuel). Pour diagnostiquer la panne, ouvrez le journal des événements ou exécutez GPRESULT /H GPReport.html depuis la ligne de commande pour accéder aux résultats de la stratégie de groupe.
Petite nouveauté, sur le serveur AD, j'ai des erreurs de type "DistributedCOM" dans les journaux d'évènements :
Avez-vous d'autres pistes de résolution messieurs ?
Merci par avance de vos retours.
- Modifié COMPTE INACTIF vendredi 28 juin 2019 08:17
-
C'est pas simple de t'aider sur ton problème dans un forum, cela demande de fouiller un peu partout, eventvwr etc ...
En résumé, le DC ne crée pas correctement tous les enregistrements de service, et tu as crée les enregistrements manquants. Même en créant des enregistrement manuellement les test DNS montrent des noms qui ne sont pas résolus. Sur le TS des alertes de résolution DNS ou de timeout sur la recherche.
Il faut maintenant essayer de supprimer des causes tierces :
profil Parefeu ?
Antivirus ?
Autres services ou logiciel installés sur le DC ?
-
Bonjour,
à tout hasard, le gpupdate /force provoque une erreur que sur le TSE ? Si tu essaies sur un PC du domaine par ex .. ?
Je tenterai de monter un autre AD pour vérifier si la réplication est OK, et si en changeant le DNS spécifié dans le TSE, il arrive à appliquer le gpupdate
L'erreur DCOM serait la conséquence d'un blocage pare-feu à propos de requête DNS (d'après qques recherches google) Pouvez-vous vérifier l'état du pare-feu windows, appli tierce antivirus/firewall, firewall physique ... ?
-
Bonjour, Messieurs,
Merci de vos retours et je vous présente mes excuses pour mon délai de réponse.
Je viens de faire les tests suivants chez le client :
- GPUPDATE depuis un poste qui est dans le domaine : Aucune erreur ;
- Créatio nd'une nouvelle VM, mise sur le domaine, installation du RDS et GPUPDATE : Aucune erreur ;
Le problème viendrait donc du serveur TSE qui est en production et non pas du serveur AD avec le service DNS.
Quelle solution puis-je maintenant mettre en place ? Sortir le serveur TSE du domaine pour le rentrer de nouveau dedans ?
Merci par avance de vos retours.
-
Bonjour, Messieurs,
J'ai eu l’occasion de faire sortir puis rentrer de nouveau le serveur TSE dans le domaine.
Toutefois, ceci n'a pas résolu ma problématique. J'ai également fait les vérifications au niveau des antivirus et pare-feu, mais aucun blocage à ce niveau.
Aurez-vous de nouvelles pistes ?
Merci par avance de vos retours.
-
-
Bonjour, Spunamo,
Merci de votre retour.
Le résultat du GPRESULT est disponible sur le lien suivant : résultat GPRESULT
Fichier ZIP contenant le fichier HTML du rapport.
- Modifié COMPTE INACTIF jeudi 11 juillet 2019 14:30
-
-
-
-
-
-
-
Je viens également de faire d'autres tests sur le serveur TSE.
Notamment avec la commande suivante : GPRESULT /R /USER:NOM_DOMAINE\UTILISATEUR
J'ai fait le test sur un utilisateur qui est présent depuis longtemps sur le serveur et dont je sais que la stratégie s'applique et le résultat est le suivant :
Outil de r‚sultat du systŠme d'exploitation Microsoft (R) Windows (R) v2.0 ¸ 2013 Microsoft Corporation. Tous droits r‚serv‚s. Cr‚‚ le 24/07/2019 … 16:25:27 Données RSOP pour NOM_DU_CLIENT\JEROME sur SRV-TSE01 : mode journalisation ------------------------------------------------------------------------ Configuration du systŠme d'exploitation : Serveur membre Version du systŠme d'exploitation...... : 6.3.9600 Nom du site............................ : N/A Profil itin‚rant : N/A Profil local........................... : C:\Users\JEROME Connexion via une liaison lente ? : Non ParamŠtre de l'ordinateur -------------------------- CN=SRV-TSE01,OU=SRV-TSE,DC=NOM_DU_CLIENT,DC=local Heure de la derniŠre application de la strat‚gie de groupe : 24/07/2019 … 16:20:57 Strat‚gie de groupe appliqu‚e depuis : SRVNOM_DU_CLIENT.NOM_DU_CLIENT.local Seuil de liaison lente dans la strat‚gie de groupe : 500 kbps Nom du domaine.........................ÿ: SRV-TSE01 Type de domaine........................ : <Ordinateur local> Objets Strat‚gie de groupe appliqu‚s ------------------------------------- Strat‚gie de groupe locale L'ordinateur fait partie des groupes de s‚curit‚ suivants --------------------------------------------------------- Niveau obligatoire systŠme Tout le monde Utilisateurs NT AUTHORITY\SERVICE OUVERTURE DE SESSION DE CONSOLE Utilisateurs authentifi‚s Cette organisation BITS CertPropSvc DsmSvc Eaphost hkmsvc IKEEXT iphlpsvc LanmanServer MMCSS MSiSCSI NcaSvc RasAuto RasMan RemoteAccess Schedule SCPolicySvc SENS SessionEnv SharedAccess ShellHWDetection wercplsupport Winmgmt wlidsvc wuauserv LOCAL Administrateurs PARAMÔTRES UTILISATEURS ------------------------ CN=J‚r“me ALLARD,OU=NOM_DU_CLIENT,DC=NOM_DU_CLIENT,DC=local Heure de la derniŠre application de la strat‚gie de groupe : 24/07/2019 … 16:20:34 Strat‚gie de groupe appliqu‚e depuis : SRVNOM_DU_CLIENT.NOM_DU_CLIENT.local Seuil de liaison lente dans la strat‚gie de groupe : 500 kbps Nom du domaineÿ: NOM_DU_CLIENT Type de domaine : Windows 2008 ou sup‚rieur Objets Strat‚gie de groupe appliqu‚s ------------------------------------- OFFICE TSE Default Domain Policy Default Domain Policy Les objets strat‚gie de groupe n'ont pas ‚t‚ appliqu‚s car ils ont ‚t‚ refus‚s ----------------------------------------------------------------------------------- Strat‚gie de groupe locale Filtrage : Non appliqu‚ (vide) Strat‚gie de groupe locale Filtrage : Non appliqu‚ (vide) L'utilisateur fait partie des groupes de s‚curit‚ suivants ---------------------------------------------------------- Utilisa. du domaine Tout le monde Utilisateurs Utilisateurs du Bureau … distance REMOTE INTERACTIVE LOGON INTERACTIF Utilisateurs authentifi‚s Cette organisation LOCAL ADMINISTRATION Identit‚ d‚clar‚e par une autorit‚ d'authentification Niveau obligatoire moyen
Nous pouvons voir que les stratégies s'appliquent correctement sur l'utilisateur. Il s'agit des GPO : OFFICE, TSE et Default Domain Policy.
Si par contre je fais le test sur un nouvel utilisateur et où la GPO ne s'applique pas, le résultat est le suivant :
Information : L'utilisateur "NOM_DU_DOMAINE\JULIEN" n'a pas de données RSOP.
Je ne sais pas si cela peut aider dans la résolution du problème, mais je vous donne l'information au cas où.
Merci par avance de vos retours.
-
-
Bonjour,
Pour cette histoire "d'incohérence AD", consultez ce lien svp :
-
-
-
-
-
Bonjour,
Oui, cette KB est également présente sur l'AD. Les deux serveurs sont up-to-date.
Pour le test que vous proposez, je viens de l'effectuer et elle ne s'applique pas. D'ailleurs, aucune des GPO ne s'applique sur le serveur TSE. Car j'ai également une GPO pour des lecteurs réseau, mais celle-ci ne fonctionne pas non plus.
-
Comme déja dit, il n'est pas simple d'aider sur tous les problèmes depuis un forum et sans visuel.
Tu as regardé autour des autres éléments ?
Il faut maintenant essayer de supprimer des causes tierces SUR LE DC:
profil Parefeu ?
Antivirus ?
Autres services ou logiciel installés sur le DC ?
Il y a quand même plusieurs éléments anormaux entre autre sur la partie DNS et les enregistrements de service. Il serait peut être plus pratique de passer par une intervention externe. J'ai déja eu des cas un peu étrange avec des DC virtualisés, au niveau de l'hyperviseur, avec du teaming sur des cartes réseaux.
L'utilisation d'ip public en interne n'est pas optimal non plus.
-
Bonjour,
Je vous remercie de vos retours.
Je vais faire d'autres tests dans ce sens, mais je pense également faire appel à présent au support Microsoft directement afin de résoudre cette problématique.
Dans tous les cas, je vous remercie de votre temps accorder à mon problème.
Bonne journée.
- Marqué comme réponse COMPTE INACTIF mardi 3 septembre 2019 07:04
- Modifié COMPTE INACTIF mardi 3 septembre 2019 07:05