locked
Problème script de démarrage via GPO RRS feed

  • Question

  • Bonjour,


    Sur un domaine W2000, je souhaite désinstaller office 2003 PRO sur des clients XP et Seven.

     

    J'ai donc mis en place une GPO sur le composant ordinateur, paramètres windows, scripts, qui lance un .bat au démarrage de l'ordinateur.

    Ce .bat est censé désinstaller Office 2003.

    Voici son contenu:

    msiexec.exe /x "\\serveur\Office\Office_2003_SP3\pro11.msi" /L*v "d:\log.txt"

    Lorsque je lance cette commande depuis un client, pas de problème, ça désinstalle.

    Mais via la GPO, il ne se passe rien !

    Dans ma GPO, j'ai:

    - activé l'installation avec des droits élevés

    - activé l'exécution de scripts de session simultanément

    - activé la boucle de rappel de la stratégie de groupe utilisateur (mode fusionner)

     

    Les logs de msiexec mentionnent une erreur 1619, j'ai donc donné au compte "système" les droits d'accès au dossier de partage de mon MSI de désinstallation, mais ça ne change rien.

    Je suis à court d'idée, mais peut être pourrez vous m'orienter vers une nouvelle voie ?

     

    Merci !

    mercredi 20 mars 2013 11:06

Réponses

  • Bonjour,

    Vous devriez essayer avec cette méthode (qui évitera sûrement les problèmes d'accès) : http://blogs.technet.com/b/odsupport/archive/2011/04/07/how-to-automate-the-uninstallation-of-office-2003-products.aspx

    Cdt,

    
    mercredi 20 mars 2013 13:38
  •    

    J'ai donc mis en place une GPO sur le composant ordinateur, paramètres windows, scripts, qui lance un .bat au démarrage de l'ordinateur.

    - activé la boucle de rappel de la stratégie de groupe utilisateur (mode fusionner)

    => a quoi sert la boucle de rappel si vous définissez des paramètres aux niveaux ordinateurs et non utilisateurs ?
    => Votre Gpo s'applique a une OU contenant les ordinateurs ou les utilisateurs ? Si c'est les utilisateurs ce n'est pas logique car vous utilisez des paramètres utilisateurs.

    => la console GPMC avec l'assistant de résultat de stratégie de groupe permet de vérifier les GPO appliquées. Sinon il y a GP result.


    Leslogs de msiexec mentionnent une erreur 1619, j'ai donc donné au compte "système" les droits d'accès au dossier de partage de mon MSI de désinstallation, mais ça ne change rien.
    Je suis à court d'idée, mais peut être pourrez vous m'orienter vers une nouvelle voie ?

    Le compte système est différent entre chaque ordinateur. Le compte système n'est pas un compte de domaine, donc forcément celui de l'ordinateur sur lequel le script s'execute n'as pas de droits.
    sinon crée un compte spécifique, faites un net use ... /user avec un compte neutre puis executer depuis le lecteur connecté.



    Rien ne se passe à l'ouverture du pc comme à l'ouverture de la session.

    Si vous faites une GPO sur des paramètres ordinateurs il n'y a pas de lien avec l'ouverture de session, la session est lié à l'utilisateur. Les GPO sur des paramètres ordinateurs n'ont pas besoin d'attendre l'ouverture de session.


    dimanche 24 mars 2013 08:09

Toutes les réponses

  • Bonjour,

    Vous devriez essayer avec cette méthode (qui évitera sûrement les problèmes d'accès) : http://blogs.technet.com/b/odsupport/archive/2011/04/07/how-to-automate-the-uninstallation-of-office-2003-products.aspx

    Cdt,

    
    mercredi 20 mars 2013 13:38
  • Oui c'est cette commande que j'ai dans mon .bat, simplement j'ai stipulé l'emplacement du .msi au lieu du GUID d'office.

    Les deux commandes (avec msi et avec guid) ne fonctionnent pas, de toutes façon.

    Rien ne se passe à l'ouverture du pc comme à l'ouverture de la session.

    mercredi 20 mars 2013 15:06
  •    

    J'ai donc mis en place une GPO sur le composant ordinateur, paramètres windows, scripts, qui lance un .bat au démarrage de l'ordinateur.

    - activé la boucle de rappel de la stratégie de groupe utilisateur (mode fusionner)

    => a quoi sert la boucle de rappel si vous définissez des paramètres aux niveaux ordinateurs et non utilisateurs ?
    => Votre Gpo s'applique a une OU contenant les ordinateurs ou les utilisateurs ? Si c'est les utilisateurs ce n'est pas logique car vous utilisez des paramètres utilisateurs.

    => la console GPMC avec l'assistant de résultat de stratégie de groupe permet de vérifier les GPO appliquées. Sinon il y a GP result.


    Leslogs de msiexec mentionnent une erreur 1619, j'ai donc donné au compte "système" les droits d'accès au dossier de partage de mon MSI de désinstallation, mais ça ne change rien.
    Je suis à court d'idée, mais peut être pourrez vous m'orienter vers une nouvelle voie ?

    Le compte système est différent entre chaque ordinateur. Le compte système n'est pas un compte de domaine, donc forcément celui de l'ordinateur sur lequel le script s'execute n'as pas de droits.
    sinon crée un compte spécifique, faites un net use ... /user avec un compte neutre puis executer depuis le lecteur connecté.



    Rien ne se passe à l'ouverture du pc comme à l'ouverture de la session.

    Si vous faites une GPO sur des paramètres ordinateurs il n'y a pas de lien avec l'ouverture de session, la session est lié à l'utilisateur. Les GPO sur des paramètres ordinateurs n'ont pas besoin d'attendre l'ouverture de session.


    dimanche 24 mars 2013 08:09
  •    

    J'ai donc mis en place une GPO sur le composant ordinateur, paramètres windows, scripts, qui lance un .bat au démarrage de l'ordinateur.

    - activé la boucle de rappel de la stratégie de groupe utilisateur (mode fusionner)

    => a quoi sert la boucle de rappel si vous définissez des paramètres aux niveaux ordinateurs et non utilisateurs ?
    => Votre Gpo s'applique a une OU contenant les ordinateurs ou les utilisateurs ? Si c'est les utilisateurs ce n'est pas logique car vous utilisez des paramètres utilisateurs.

    => la console GPMC avec l'assistant de résultat de stratégie de groupe permet de vérifier les GPO appliquées. Sinon il y a GP result.


    Leslogs de msiexec mentionnent une erreur 1619, j'ai donc donné au compte "système" les droits d'accès au dossier de partage de mon MSI de désinstallation, mais ça ne change rien.
    Je suis à court d'idée, mais peut être pourrez vous m'orienter vers une nouvelle voie ?

    Le compte système est différent entre chaque ordinateur. Le compte système n'est pas un compte de domaine, donc forcément celui de l'ordinateur sur lequel le script s'execute n'as pas de droits.
    sinon crée un compte spécifique, faites un net use ... /user avec un compte neutre puis executer depuis le lecteur connecté.



    Rien ne se passe à l'ouverture du pc comme à l'ouverture de la session.

    Si vous faites une GPO sur des paramètres ordinateurs il n'y a pas de lien avec l'ouverture de session, la session est lié à l'utilisateur. Les GPO sur des paramètres ordinateurs n'ont pas besoin d'attendre l'ouverture de session.


    Alors...

    Effectivement la boucle de rappel ne sert pas à grand chose dans ce cas. Je l'ai retirée.

    Ma GPO s'applique sur une OU test qui contient à la fois l'utilisateur et l'ordinateur de test.

    La console GPMC m'indique que ma GPO est bien appliquée, tant sur les paramètres ordinateur qu'utilisateur.

    Pour le net use /user:

    J'ai testé en modifiant mon script de démarrage ordinateur comme ceci:

    net use p: \\serveur\office_2003_sp3 /user:admin password
    msiexec.exe /x "p:\pro11.msi" /qb
    pause

    Le lecteur n'est pas connecté lorsque j'ouvre la session utilisateur, et il ne se passe toujours rien.

    Cependant quand j'exécute mon .bat en local, ça fonctionne.

    En résumé tous les scripts fonctionnent en local, ma GPO s'applique (GPMC me le confirme), mais l'association GPO-script ne fait rien...

    vendredi 29 mars 2013 14:00
  • Complèment à ce que j'ai ajouté un peu plus haut...

    J'ai supposé que le lecteur réseau n'avait pas le temps de se créer avant que le msiexec ne s'enclenche.

    J'ai donc rajouté un start /wait devant mon net use, mais là encore ça ne change rien.

    Ma session utilisateur s'ouvre (alors qu'avec le paramètre "executer les scripts d'ouverture de session simultanément" ça ne devrait pas être le cas avant la désinstallation !) et j'ai un message me disant que les lecteurs réseau (dont le P: du net use) n'ont pas été reconnectés.

    En tâche de fond, msiexec s'exécute, mais concrètement rien ne se passe.

    D'après moi, tel que ma stratégie est concue, au démarrage de l'ordinateur avant le ctrl-alt-suppr:

    - le net use s'éxecute, attend le mappage du lecteur P (puisque start /wait)

    - le msiexec doit prendre le relais et désinstaller office 2003 (car paramètre "toujours installer avec des droits élevés" activé sur ordinateur et utilisateur)

    - pendant ce temps je ne dois même pas pouvoir ouvrir de session utilisateur (paramètre "executer les scripts d'ouverture de session simultanément")

    - puis lorsque j'ouvre la session de l'utlisateur, le lecteur P; doit être connecté, et office désinstallé.

    Qu'en pensez vous ?

    vendredi 29 mars 2013 14:24