Discussion :

[cerkyr]

Bonjour,

J'ai essayé de passer le commandes avec :
c:\windows\System32\
ou
%systemroot\sysnative\

Mon problème est de pouvoir lancer des scripts en 32 ou 64 bits (cela m'est égal) sur un Windows Seven Pro 64 bits, avec le compte local SYSTEM.
Mes scripts fonctionnent sauf la partie HTA; le process MSHTA.exe est bien exécuté et présent, et le fichier HTA est bien en mémoire.
Mais pas d'affichage du fichier HTA.

Process Explorer (SysInternals) me confirme bien que les scripts sont en 32 bits.
Est-ce que c'est le mode 32 bits qui empêche l'affichage du HTA sur le Windows Seven Pro 64 bits ?

Pourquoi ?

(Ce même type de script fonctionne parfaitement en Windows XP 32 bits)

Cdlt,

[Andnotor]

Un service n'a pas de bureau et ne peut rien afficher.
Ca fonctionnais sous XP parce que le premier utilisateur connecté partageait la session 0 avec les services. Depuis Vista, les sessions utilisateurs démarrent à 1.

[cerkyr]

Bonjour,

Un script, exécuté dans une tâche planifiée, lancée au logon de l'utilisateur , par le compte System, ne peut afficher une page HTA ??!
Cela fonctionne très bien sur XP, pourquoi pas sur Windows Seven 64 bits ?

Je ne comprends pas votre réponse.
Pouvez-vous expliquer d'avantage ?

Cdlt,

[Andnotor]

Une tâche planifiée SYSTEM est lancée par un service en session 0. Tu peux afficher la colonne "ID de session" dans le gestionnaire de tâches pour le constater.

Les "bureaux" (il y en a trois par utilisateur : bureau proprement dit, logon et écran de veille) sont propres à chaque session et il n'est pas possible d'afficher des informations sur le bureau d'une session qui n'est pas la sienne. Elles sont isolées.

Comme déjà dit, cela fonctionnait sous XP parce que le premier utilisateur connecté (et uniquement celui-là) partageait la session 0 avec les services. On était dans la même session donc pas de problème. Ouvre une deuxième session utilisateur en parallèle et tu verras que rien ne s'affichera puisque ce dernier sera en session 1.

Cela a changé depuis Vista par soucis de sécurité. Les services sont seuls à tourner en session 0 (32 ou 64 bits, peu importe).

[cerkyr]

Donc, nous avons ici une régression.
Donc, comment faire ?

[Andnotor]

Donc, nous avons ici une régression.

Ce n'est pas une régression, plutôt une erreur de conception XP corrigée.

Donc, comment faire ?

La question est pourquoi as-tu besoin du compte système ?

[cerkyr]

Est-il possible d'ouvrir un fichier HTA au travers d'un service Windows ?

[cerkyr]

Ce n'est pas une régression, plutôt une erreur de conception XP corrigée.

Si la fonction existait, c'est qu'elle était utile aux Admins pour déployer.
Je n'ai donc pas du tout le même avis.
Je me garderais bien de dire ce que je pense de WSUS et SCCM, et des choix constatés par nous et effectués par Microsoft en la matière.
(tout comme la méthode d'interception de l'arrêt qui fonctionnait sur XP et n'est pas rendu publique par Microsoft depuis Windows Seven)

La question est pourquoi as-tu besoin du compte système ?

Parce notre outil de télédistribution utilise ce compte et uniquement ce compte; c'est incontournable depuis des années.
Tous les autres mots de passe, même les comptes Admin et de Services, ont une date d'expiration, et là pour la sécurité, je n'ai pas le choix, et c'est ainsi depuis des années.

[cerkyr]

La tentative d'essai au travers d'un service Windows en mode 32 et et mode 64 bits, ne fonctionne pas.
Le process MSHTA.exe est bien lancé, mais le message n'apparait pas.
Le process explorer montre la ligne de commande et cette ligne de commande fonctionne dans le bureau de Windows.
Donc, encore, ECHEC.

[Andnotor]

Si la fonction existait, c'est qu'elle était utile aux Admins pour déployer.

Pas vraiment. C'est plutôt un héritage malheureux des versions précédentes mono-utilisateur.

(tout comme la méthode d'interception de l'arrêt qui fonctionnait sur XP et n'est pas rendu publique par Microsoft depuis Windows Seven)

Je ne vois pas ce que tu entends par là. En programmation, WM_POWERBROADCAST nous donne toutes ces informations.

Parce notre outil de télédistribution utilise ce compte et uniquement ce compte; c'est incontournable depuis des années.

Pour la télédistribution, ça parait logique. Ce qui ne l'est pas est qu'il veuille ensuite lancer un interface graphique sous ce même utilisateur. Il y a clairement une erreur de conception de cet outil (même à l'époque XP).

Malheureusement, je crains qu'il n'y ait pas de solution...

La tentative d'essai au travers d'un service Windows en mode 32 et et mode 64 bits, ne fonctionne pas.

Mais c'est ton programme ou un programme tiers

[cerkyr]

La solution a été de constituer un script permettant de :
+ créer une GPO locale pour exécuter un script à l'arrêt.
+ créer un CA COF pour afficher les messages aux utilisateurs.
...le tout dans l'environnement 0, après la fermeture de la session utilisateur (environnement 1) et avant extinction du pc (ou reboot).
Microsoft n'a pas voulu aider car cela rentre en concurrence avec SCCM et WSUS. (je les cite)