none
Modifier gpo locale en ligne de commande RRS feed

  • Discussion générale

  • Bonjour,

    Je cherche à modifier une GPO locale sur un poste, par le biais d'un logiciel tiers (WAPT)

    gpedit.msc n'est donc pas utilisable dans ce contexte.

    J'ai trouvé comment faire en powershell et cmd (modifier les bonnes clés de registre, le fichier script.ini, et lancer un gpudate /force). Ca fonctionne parfaitement, si je lance ces scripts en tant qu'administrateur directement sur le poste.

    Le probleme est que WAPT utilise le compte system pour lancer les scripts, et apparemment, dans ce contexte, le gpupdate /force rétablit la GPO à son état d'origine, sans tenir compte des changements que j'ai fait dans la BDR, ni au niveau de script.ini (dailleurs il les remodifie).

    Je repete pour éviter les confusions : si je fais la même chose en tant qu'administrateur, pas de probleme, il met bien la GPO à jour avec les nouveaux paramètres.

    J'avoue ne pas être au fait de toutes les subtilités de ces mécanismes, mais y a-t'il moyen de contourner le probleme ?

    Merci d'avance aux avis éclairés

    jeudi 25 avril 2019 10:21

Toutes les réponses

  • A première vue, tu dois disposer d'un agent WAP installé sur le poste qui s'exécute avec le compte "SYSTEM".

    Comme indiqué sur le site :

    https://www.wapt.fr/fr/doc/wapt-common-problems/index.html#problem-installing-a-package

    As tu essayé de changer de compte d'exécution au niveau du service correspondant pour tester ?

    jeudi 25 avril 2019 10:34
  • Comme je le signalais dans mon premier post, effectivement, l'agent WAPT s'éxecute avec le compte SYSTEM.

    J'avais déja lu le lien que tu signales, et on est bien dans ce cas là : si je lance le gpupdate avec le compte administrateur, indépendamment de WAPT, tout fonctionne parfaitement. Avec WAPT, tous les changements dans la BDR se font bien, mais dès qu'il lance le gpupdate, tous les changements sont écrasés, et la conf d'origine est rétablie.

    Mais il ne semble pas y avoir moyen de dire à WAPT d'utiliser le compte administrateur au lieu du compte SYSTEM

    Je ne comprends pas le fonctionnement coté Windows :

    Les changements que j'effectue (BDR et scripts.ini) n'ont aucun effet tant que je ne lance pas un gpupdate.

    Si je reboote la machine (j'ai testé en rebootant plusieurs fois, même), tous mes changements (BDR et scripts.ini) persistent, le script qui se lançait à l'origine ne se lance plus, mais le mien non plus. Au bout de plusieurs reboot, si je lance un gpupdate par WAPT, il me rétablit la conf d'origine, alors que si je le fais à la main, avec le compte admin, il valide mes changements.

    Ce qui me laisse à penser qu'il reste une trace de la conf d'origine quelque part, même après un reboot (mais où? Les recherches dans la BDR n'ont rien donné), d'une part. Et d'autre part, que SYSTEM utilise cette "trace" mais pas le compte administrateur.

    Si quelqu'un a une idée d'où le compte SYSTEM peut aller tirer ses infos... ça m'aiderait grandement à résoudre ce probleme.

    Mais pourquoi aller disperser à tant d'endroits dans le systeme/BDR des infos redondantes, au lieu de tout mettre au même endroit une bonne fois pour toutes ? J'avoue que ça me dépasse ;-)


    • Modifié zeltron82 jeudi 25 avril 2019 11:51
    jeudi 25 avril 2019 11:51
  • Si tu regardes dans les services Windows, il doit bien y avoir l'agent WAPT d'installé. Si c'est le cas, il doit fonctionner en utilisant le compte "system". Tu peux modifier cette connexion en utilisant un compte de type administrateur local. C'est ce que je te disais de faire sur une machine pour tester.

    jeudi 25 avril 2019 12:00
  • Comme je le signalais dans mon premier post, effectivement, l'agent WAPT s'éxecute avec le compte SYSTEM.

    J'avais déja lu le lien que tu signales, et on est bien dans ce cas là : si je lance le gpupdate avec le compte administrateur, indépendamment de WAPT, tout fonctionne parfaitement. Avec WAPT, tous les changements dans la BDR se font bien, mais dès qu'il lance le gpupdate, tous les changements sont écrasés, et la conf d'origine est rétablie.

    Mais il ne semble pas y avoir moyen de dire à WAPT d'utiliser le compte administrateur au lieu du compte SYSTEM

    Je ne comprends pas le fonctionnement coté Windows :

    Les changements que j'effectue (BDR et scripts.ini) n'ont aucun effet tant que je ne lance pas un gpupdate.

    Si je reboote la machine (j'ai testé en rebootant plusieurs fois, même), tous mes changements (BDR et scripts.ini) persistent, le script qui se lançait à l'origine ne se lance plus, mais le mien non plus. Au bout de plusieurs reboot, si je lance un gpupdate par WAPT, il me rétablit la conf d'origine, alors que si je le fais à la main, avec le compte admin, il valide mes changements.

    Ce qui me laisse à penser qu'il reste une trace de la conf d'origine quelque part, même après un reboot (mais où? Les recherches dans la BDR n'ont rien donné), d'une part. Et d'autre part, que SYSTEM utilise cette "trace" mais pas le compte administrateur.

    Si quelqu'un a une idée d'où le compte SYSTEM peut aller tirer ses infos... ça m'aiderait grandement à résoudre ce probleme.

    Mais pourquoi aller disperser à tant d'endroits dans le systeme/BDR des infos redondantes, au lieu de tout mettre au même endroit une bonne fois pour toutes ? J'avoue que ça me dépasse ;-)


    Bonjour, je rencontre le même que vous... et je suis très intéressé si vous avez trouvé une solution :)  
    vendredi 17 avril 2020 12:38