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.
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.
-
Merci de votre retour.
Aucune modification n’a été faite dans les partages.
Le résultat de la commande NET SHARE est la suivante :
Il n'y a pas de décalage d'horloge entre le serveur AD et TSE.
Ils sont tous deux synchronisés sur le même serveur NTP.
-
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é Kevin Engel mercredi 5 juin 2019 15:06 Correction image
-
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éussiL'édition de la GPO fonctionne depuis l'AD.
-
Voici le contenu de la zone DNS direct :
Et la zone DNS inversée :
-
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.
-
Voici les zones à vérifier :
Vous devriez trouver votre AD dans chacune de ces zones/sous zones. Tantôt avec son FQDN et tantôt avec son ip uniquement.
-
Bonjour,
Les redémarrages des serveurs ont eu lieu.
Sur l'AD, j'ai les avertissements suivants :
Et côté TSE, c'est les messages suivants :
Pourtant les NSLOOKUP du TSE vers l'AD fonctionnent et l'inverse aussi.
-
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 ??
-
Oui, en effet nous avions un ancien AD qui n'est plus présent sur le réseau. Mais ceci depuis maintenant assez longtemps.
La configuration réseau de l'AD :
La configuration du TSE est la suivante :
-
Oui, l'ancien AD a bien été "dépromoté". Nous ne sommes pas dans le cas que vous présentez.
Je viens de faire le changement de l'adresse IP. Le GPUPDATE /FORCE renvoi le résultat suivant :
-
Le message côté TSe est le suivant :
-
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 :
-
Pardon, il m'avait semblé avoir indiqué que la mise à jour est sur sécurité seulement :
Et les zones DSN sont bien dans l'AD :
-
J'ai pris le premier enregistrement de la première arborescence :
Et c'était un enregistrement de type _ldap.
-
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
-
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
-
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.
-
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 ?
-
Bonjour, Monsieur Barth,
Voici ce que j'ai actuellement dans cette délégation de zone :
-
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é Kevin Engel vendredi 28 juin 2019 08:17
