none
Problème application de GPO RRS feed

  • 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.

    mercredi 5 juin 2019 06:47

Toutes les réponses

  • Commencez par :

    Dcdiag sur le serveur ?

    partage sysvol et netlogon OK sur le DC ?

    mercredi 5 juin 2019 09:05
    Modérateur
  • 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.

    mercredi 5 juin 2019 09:30
  • 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 ?

    http://www.pbarth.fr/node/87

    mercredi 5 juin 2019 10:13
    Modérateur
  • 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.

    mercredi 5 juin 2019 10:29
  • 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)

    mercredi 5 juin 2019 11:50
  • 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é Kevin Engel mercredi 5 juin 2019 12:47 Erreur de frappe
    mercredi 5 juin 2019 12:24
  • Bonjour, 

    Dans votre message initial, je ne vois pas de nslookup nomdudomaine

    Essayez de sortir le TSE du domaine et de l'y remettre.

    mercredi 5 juin 2019 14:25
  • 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
    mercredi 5 juin 2019 14:38
  • 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 

    mercredi 5 juin 2019 16:17
    Modérateur
  • 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.

    jeudi 6 juin 2019 10:07
  • 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.

    jeudi 6 juin 2019 11:59
  • 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)

    http://www.pbarth.fr/node/35


    A noter que ce n'est pas une bonne idée d'utiliser des plages IPv4 public en interne comme192.120.x.x

    jeudi 6 juin 2019 12:17
    Modérateur
  • 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. 

    jeudi 6 juin 2019 12:19
    Modérateur
  • Voici le contenu de la zone DNS direct :

    Et la zone DNS inversée :

    jeudi 6 juin 2019 15:52
  • Bonjour,

    Nous vous demandions de contrôler l'état des enregistrements SRV des sous-domaines.

    vendredi 7 juin 2019 10:21
  • 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.

    jeudi 20 juin 2019 13:25
  • 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
    jeudi 20 juin 2019 13:59
  • 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.

    jeudi 20 juin 2019 14:13
  • 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.

    jeudi 20 juin 2019 14:36
  • 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.

    jeudi 20 juin 2019 14:47
  • 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 ?

    jeudi 20 juin 2019 15:03
  • 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.

    jeudi 20 juin 2019 15:19
  • 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.

    vendredi 21 juin 2019 07:03
  • 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 ??

    vendredi 21 juin 2019 07:25
    Modérateur
  • 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.

    vendredi 21 juin 2019 08:16
  • 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
    

    vendredi 21 juin 2019 08:17
  • 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 :

    vendredi 21 juin 2019 08:23
  • 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 ?

    vendredi 21 juin 2019 08:27
  • 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 :

    vendredi 21 juin 2019 08:41
  • Donc l'AD semble bien trouver ses "petits".

    Et côté TSE, message identique ou message indiquant qu'il ne peut pas joindre l'AD ?

    vendredi 21 juin 2019 09:01
  • Le message côté TSe est le suivant :

    vendredi 21 juin 2019 09:11
  • 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
    vendredi 21 juin 2019 09:16
  • 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 :

    vendredi 21 juin 2019 09:49
  • 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 :

    https://social.technet.microsoft.com/Forums/fr-FR/296d6152-d006-4641-9be9-8fb6d56a82ce/gpo-wind2012-std-r2-incoherence-de-version-ad-sysvol?forum=windowsserver8fr

    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é
    vendredi 21 juin 2019 10:05
  • La KB3159398 est présente sur les deux serveurs.

    vendredi 21 juin 2019 10:09
  • 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) ?

    vendredi 21 juin 2019 10:10
    Modérateur
  • 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.

    vendredi 21 juin 2019 10:12
    Modérateur
  • 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 :

    vendredi 21 juin 2019 10:16
  • J'ai pris le premier enregistrement de la première arborescence  :

    Et c'était un enregistrement de type _ldap.

    vendredi 21 juin 2019 10:19
  • 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 :

    https://social.technet.microsoft.com/Forums/en-US/9283c4ee-519b-4497-b93a-3b4c7e86771c/srv-not-created-automaticly-for-ldaptcpdc?forum=winserverDS

    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.

    vendredi 21 juin 2019 10:32
  • 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.

    vendredi 21 juin 2019 12:07
    Modérateur
  • Pouvez-vous svp, faire un copier/coller du fichier C:\Windows\System32\config\netlogon.dns (il répertorie les enregistrements SRV géré par netlogon)

    vendredi 21 juin 2019 12:26
  • Bonjour, Monsieur Barth,

    Les paramètres de sécurité de la zone sont identiques à votre capture d'écran.

    lundi 24 juin 2019 06:39
  • 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.
    

    lundi 24 juin 2019 06:42
  • Bonjour, Monsieur Sanchez,

    Merci du lien, je l'avais déjà consulté avant d'ouvrir ce sujet.


    lundi 24 juin 2019 06:47
  • 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 ?

    lundi 24 juin 2019 08:21
  • 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.

    https://support.microsoft.com/en-nz/help/816587/how-to-verify-that-srv-dns-records-have-been-created-for-a-domain-cont

    https://blogs.msdn.microsoft.com/servergeeks/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory/

    lundi 24 juin 2019 08:53
    Modérateur
  • 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.


    lundi 24 juin 2019 09:36
    Modérateur
  • Dans ce cas, Kevin ENGEL doit comparer le netlogon.dns avec les enregistrements visibles dans sa console DNS ?
    lundi 24 juin 2019 09:37
  • Dans ce cas, Kevin ENGEL doit comparer le netlogon.dns avec les enregistrements visibles dans sa console DNS ?

    Oui et en toute logique les écarts devraient correspondre aux erreurs dans le journal.

    lundi 24 juin 2019 09:45
    Modérateur
  • Merci de vos retours Messieurs.

    Je vais faire les différentes vérifications et je reviens vers vous.
    lundi 24 juin 2019 12:08
  • 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. ?

    lundi 24 juin 2019 14:54
  • 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)


    lundi 24 juin 2019 15:25
    Modérateur
  • 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.

    mardi 25 juin 2019 07:04
  • 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 :

    https://support.microsoft.com/fr-fr/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users

    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.

    mardi 25 juin 2019 07:19
  • 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.

    mardi 25 juin 2019 10:07
  • 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 ?


    mardi 25 juin 2019 19:22
    Modérateur
  • Bonjour, Monsieur Barth,

    Voici ce que j'ai actuellement dans cette délégation de zone :

    mercredi 26 juin 2019 06:43
  • Les parties importantes sont grisés, c'est à vous de confirmer qu'il y a bien le nom du bon serveur ...
    mercredi 26 juin 2019 11:50
    Modérateur
  • Il s'agit bien du bon serveur, autant au niveau du nom que de l'adresse IP.


    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 :

    https://social.technet.microsoft.com/Forums/en-US/9283c4ee-519b-4497-b93a-3b4c7e86771c/srv-not-created-automaticly-for-ldaptcpdc?forum=winserverDS

    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.



    vendredi 28 juin 2019 08:16
  • 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 ?

    dimanche 30 juin 2019 07:27
    Modérateur
  •  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 ... ?

    lundi 1 juillet 2019 09:04
  • 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.


    jeudi 4 juillet 2019 12:56
  • 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.

    jeudi 11 juillet 2019 06:33
  • Bonjour, Pouvez-vous partager le gpresult du srv-tse ? (pas un copier-coller, mais un lien plutôt..)
    jeudi 11 juillet 2019 07:18
  • 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.


    jeudi 11 juillet 2019 14:30
  • Bonjour,

    Avez-vous de nouvelles propositions de résolution ?

    Merci par avance.

    jeudi 18 juillet 2019 15:51
  • Bonjour,

    Votre GPRESULT indique "Incohérence de version AD" pour chaque GPO appliquée sur le SRV-TSE01.

    Visitez ce lien svp : https://support.microsoft.com/en-us/help/2866345/ad-sysvol-version-mismatch-message-is-displayed-unexpectedly-in-the-gr


    vendredi 19 juillet 2019 08:28
  • Bonjour, Spunamo,

    Merci de votre retour.

    Je vais faire l'application de cette KB, car elle n'est en effet pas présente sur le serveur TSE.

    Je vous fais un retour dès que c'est fait.

    vendredi 19 juillet 2019 10:04
  • Si tu es sur de la partie DNS, car certaines de tes erreurs sont bizarre.

    Toujours des erreurs dans GPuodate /force ?

    Essye de sauvegarder depuis la console GPMC.msc, de supprimer la GPO en erreur et de la restaurer depuis la sauvegarde.

    vendredi 19 juillet 2019 11:32
    Modérateur
  • Bonjour, Spunamo,

    J'ai appliqué la KB, mais sans aucun changement sur le problème.

    lundi 22 juillet 2019 13:39
  • Bonjour, Monsieur Barth,

    Je viens de faire la sauvegarde, suppression et restauration de la GPO, mais le problème est toujours présent malheureusement.

    mercredi 24 juillet 2019 13:37
  • 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.

    mercredi 24 juillet 2019 14:34