none
Gpupdate /force ne fonctionne pas

    Question

  • Bonjour,

    J'ai un souci avec mes stratégies de groupes,  j'aimerai changer le partage vers lequel pointe une lettre. Ce qui m'ennuie c'est que le gpupdate /force ne  fonctionne pas, en tout cas lorsque je change un paramètre dans la stratégie il n'en tient pas compte au moment ou je saisi cette commande. Idem si je change la stratégie sur l'OU il ne le remarque pas instantanément.

    Par contre la stratégie fonctionne bien puisque après une dizaine de minute celle-ci s'applique.

    Je ne comprends pas bien ce qu'il se passe j'aimerais pouvoir forcer l'application de la modification à l'ouverture de session pour que le changement soit transparent pour les utilisateurs (Je ferais ça en soirée).

    (Ps j'ai testé la stratégie pour attendre que le réseau soit bien initié au démarrage et j'ai exécuté l'invite de commande en tant qu'admin.)

    Merci à tous.

    mardi 12 septembre 2017 08:09

Réponses

  • Merci pour tes pistes, j'ai 4 contrôleur de domaine sur 2 sites différents ( 2x2008 & 2x2012). Lorsque je fais la modification de ma gpo je vérifie de bien la retrouver sur mes 4 contrôleurs de domaine avant de lancer le gpupdate /force

    Tu vérifies comment ? Tu peux ouvrir la console sur n'importe quel DC, même un DC avec une erreur dans sysvol, vu que par défaut il n'affiche pas les infos locales mais les infos du DC qui a le rôle émulateur PDC (1seul / domaine)

    mardi 12 septembre 2017 11:40
    Modérateur
  • Bonjour,

    J'ai trouvé comment forcer la réplication des GPO entre mes 4 contrôleurs de domaine. Il suffit de faire la modification désirée sur un contrôleur puis d’exécuter la commande suivante dans une console Powershell en tant qu'admin : repadmin /syncall NOM-DC-AVEC-NOUVELLE-GPO /APed

    Ça marche à tout les coups sur mes serveurs.

    Sinon tu avais raison Philippe toutes les consoles Gpo affiche la même chose, pour vérifier qu'un serveur a bien récupéré les Gpo il faut faire clique droit sur le nom du domaine dans la console puis Modifier le contrôleur de domaine... et choisir le bon contrôleur après avoir coché Ce contrôleur de domaine au lieu du PDC.

    Merci à tous de m'avoir mis sur la piste.

    PS: Par contre je viens de me rendre compte que si je fais une modif dans une Gpo ça ne la prends pas en compte sur les autres contrôleurs (Suppression d'un lecteur réseau, modification du chemin de partage...) Je vais surement faire une copie de ma Gpo avec un nom différent et mes nouveaux paramètres puis lorsqu'elle sera appliquée je supprimerais l'ancienne et je renommerais la nouvelle comme l'ancienne (Sauf si quelqu'un à une meilleure idée).

    • Marqué comme réponse Ardnaxele mercredi 20 septembre 2017 07:30
    • Modifié Ardnaxele mercredi 20 septembre 2017 07:55
    mercredi 20 septembre 2017 07:29
  • La commanderepadmin /syncall NOM-DC-AVEC-NOUVELLE-GPO /APed va forcer la réplication des infos de l'annuaire, une partie des infos des GPO y est stocké. La commande ne résout pas un problèmes de synchro de sysvol (réplication de fichier et pas de l'annuaire).

    Si ta commande a résolue le problème cela signifie que ton soucis est la latence de réplication entre les DCs.

    En lui demandant de répliquer immédiatement pour l"ensemble des DC de la forêts Tu peux gagner plusieurs heures surtout en muti-site ou le délai standard est de 180 minutes entre les sites. Dans une structure complexe sur plus de 10 sites et s'il n'y a pas de maillage complet entre les sites, tu peux facilement avoir un décalage de 24Heures !!! 

    A première vue ton principal problème est de ne pas tenir compte des temps de latence dans un environnement multi sites, qui sont NORMAUX.

    Voir : http://pbarth.fr/node/127

    Si tu veux vérifier tes contrôleurs de domaine utilise Dcdiag ...



    mercredi 20 septembre 2017 10:39
    Modérateur

Toutes les réponses

  • Tu as combien de contrôleur de domaine ? Attention à la latence de réplication. Pas d'erreur sur la réplication de sysvol dans dcdiag ?

    Le GPUpdate montre une erreur ?

    Tu verra dans le lien comment utiliser l'observateur d'événement pour déterminer les stratégies appliquées :

    http://pbarth.fr/node/182

    mardi 12 septembre 2017 08:33
    Modérateur
  • Bonjour Philippe,

    Merci pour tes pistes, j'ai 4 contrôleur de domaine sur 2 sites différents ( 2x2008 & 2x2012). Lorsque je fais la modification de ma gpo je vérifie de bien la retrouver sur mes 4 contrôleurs de domaine avant de lancer le gpupdate /force (Qui n'affiche pas d'erreur dans le prompt).

    Dans l'observateur d'événements je vois ceci sur les Gpo utilisateurs:

    Démarrage du traitement d’extension Group Policy Drive Maps.
    Liste des objets de stratégie de groupe applicables : (Des modifications ont été détectées.)
    USR-Default-NEW (J'ai remplacé la USER-DEFAULT-NEW par USER-DEFAULT qu'il ne détecte pas donc.)

    Le message "(Des modifications ont été détectées.)" serait lié au changement ?

    Sinon le dcdiag m'affiche ceci (tout le reste est ok):

     Démarrage du test : DFSREvent
        Erreurs ou avertissements détectés au cours des dernières 24 heures
        après le partage de SYSVOL. Des problèmes liés à l'échec de la
        réplication SYSVOL peuvent provoquer des problèmes de Stratégie de
        groupe.
        ......................... Le test DFSREvent
         de SERVEUR-AD1 a réussi

    Je vais creuser pour voir si ça viendrait de là.

    mardi 12 septembre 2017 10:26
  • Merci pour tes pistes, j'ai 4 contrôleur de domaine sur 2 sites différents ( 2x2008 & 2x2012). Lorsque je fais la modification de ma gpo je vérifie de bien la retrouver sur mes 4 contrôleurs de domaine avant de lancer le gpupdate /force

    Tu vérifies comment ? Tu peux ouvrir la console sur n'importe quel DC, même un DC avec une erreur dans sysvol, vu que par défaut il n'affiche pas les infos locales mais les infos du DC qui a le rôle émulateur PDC (1seul / domaine)

    mardi 12 septembre 2017 11:40
    Modérateur
  • Bonjour,

    Selon le résultat fourni par la commande dcdiag, il semble que vous avez des problèmes de réplication sysvol, essayer de consulter le journal d'événement pour avoir plus de détails , les problème de réplication sysvol peuvent impacter l'application des GPOs.

    Essayer depuis un poste de travail impacté de lancer la commande ci-dessous pour vérifier si les paramètres GPO sont bien appliqués:

    GPRESULT /H D:\GPReport.html

    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    mardi 12 septembre 2017 11:57
    Modérateur
  • Hello,

    En complément des excellents commentaires précédents, je relève ceci : j'ai 4 contrôleur de domaine sur 2 sites différents ( 2x2008 & 2x2012).

    Pourquoi 2 versions de contrôleurs de domaine différentes ? Honnêtement, je ne saurai pas dire si il y a un risque de problème (théoriquement non sur vos versions) mais je serai tenté de regarder de ce coté également.

    mardi 12 septembre 2017 12:04
  • Merci à tous pour vos réponses.

    Donc pour Philippe:

    Je vérifie dans les consoles de gestion des stratégies de groupes sur les 4 serveurs, ce n'est pas bon comme démarche?

    Pour Thameur:

    Je vérifie à chaque fois après le gpudate via gpresult /r les stratégies ne sont jamais appliquées sur le coup. De plus je cherche depuis plusieurs jours je n'ai rien noté de particulier dans les journaux d'événements.

    Pour Loïc:

    Je suis dans ma société depuis 4 mois donc je n'ai pas encore tout l'historique mais le niveau fonctionnel de la forêt est bien à 2008 R2 donc ça devrait logiquement fonctionner.

    Je vais regarder le fonctionnement du soft frsdiag pour voir s'il m'en dit plus sur l'avertissement du dcdiag.



    • Modifié Ardnaxele mardi 12 septembre 2017 13:32
    mardi 12 septembre 2017 13:25
  • Dans le journal d'événement , il faut chercher dans la partie DFS replication pour trouver les messages d'erreur lié à la réplication DFS-R:


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    mardi 12 septembre 2017 17:32
    Modérateur
  • Je vérifie dans les consoles de gestion des stratégies de groupes sur les 4 serveurs, ce n'est pas bon comme démarche?

    Je ne sais pas exactement comment tu vérifies, mais le fait d'aller consulter une GPO en ouvrant la console sur les différents DC ne garantie rien.

    Tu peux utiliser l'observateur d'événement comme expliqué par Thameur.

    Tu peux également te servir de Dcdiag. Par défaut dcdiag test le DC sur lequel il est exécuté ou le DC spécifié dans la commande. /a permet de tester tous les DC 'un sites, /e tous les DC. /i permet de n'avoir que les erreurs.

    Un autre moyen pour sysvol est de vérifier la réplication et de créer un fichier testDCx.txt dans le dossier netlogon d'un DC et de vérifier si le fichier apparait sur les autres.

    Pour la réplication des l'objects de l'annuaire c'est repadmin ou AD replication status tool.

    mardi 12 septembre 2017 18:11
    Modérateur
  • Bonjour,

    J'ai trouvé comment forcer la réplication des GPO entre mes 4 contrôleurs de domaine. Il suffit de faire la modification désirée sur un contrôleur puis d’exécuter la commande suivante dans une console Powershell en tant qu'admin : repadmin /syncall NOM-DC-AVEC-NOUVELLE-GPO /APed

    Ça marche à tout les coups sur mes serveurs.

    Sinon tu avais raison Philippe toutes les consoles Gpo affiche la même chose, pour vérifier qu'un serveur a bien récupéré les Gpo il faut faire clique droit sur le nom du domaine dans la console puis Modifier le contrôleur de domaine... et choisir le bon contrôleur après avoir coché Ce contrôleur de domaine au lieu du PDC.

    Merci à tous de m'avoir mis sur la piste.

    PS: Par contre je viens de me rendre compte que si je fais une modif dans une Gpo ça ne la prends pas en compte sur les autres contrôleurs (Suppression d'un lecteur réseau, modification du chemin de partage...) Je vais surement faire une copie de ma Gpo avec un nom différent et mes nouveaux paramètres puis lorsqu'elle sera appliquée je supprimerais l'ancienne et je renommerais la nouvelle comme l'ancienne (Sauf si quelqu'un à une meilleure idée).

    • Marqué comme réponse Ardnaxele mercredi 20 septembre 2017 07:30
    • Modifié Ardnaxele mercredi 20 septembre 2017 07:55
    mercredi 20 septembre 2017 07:29
  • La commanderepadmin /syncall NOM-DC-AVEC-NOUVELLE-GPO /APed va forcer la réplication des infos de l'annuaire, une partie des infos des GPO y est stocké. La commande ne résout pas un problèmes de synchro de sysvol (réplication de fichier et pas de l'annuaire).

    Si ta commande a résolue le problème cela signifie que ton soucis est la latence de réplication entre les DCs.

    En lui demandant de répliquer immédiatement pour l"ensemble des DC de la forêts Tu peux gagner plusieurs heures surtout en muti-site ou le délai standard est de 180 minutes entre les sites. Dans une structure complexe sur plus de 10 sites et s'il n'y a pas de maillage complet entre les sites, tu peux facilement avoir un décalage de 24Heures !!! 

    A première vue ton principal problème est de ne pas tenir compte des temps de latence dans un environnement multi sites, qui sont NORMAUX.

    Voir : http://pbarth.fr/node/127

    Si tu veux vérifier tes contrôleurs de domaine utilise Dcdiag ...



    mercredi 20 septembre 2017 10:39
    Modérateur
  • Bonjour,

    Concernant le Sysvol synchroniser en dfs c'est tout bête mais il suffisait de fermer les session sur les différents contrôleur de domaine. J'ai fait tellement de test dans les différentes consoles de stratégie de groupes de tous les serveurs que certains fichiers devaient être locké ce qui bloquait tout le processus de réplication.

    Merci à tous.

    jeudi 28 septembre 2017 15:20