[remote scripting] Pb avec objet Internet.Explorer

Je ne connais pas le script "rscript.wsf " mas je pense que le composant
distant chargé de lancé le script est un service et, comme tous les services
non-interactifs, il utilise la workstation (contexte de sécurité et
d'affichage) des services.

Les 3 écrans (login, bureau et screensaver) de la workstation des services
ne sont pas les écrans de l'utilisateur interactif.

Donc, si mes hypothèses sont bonnes, il est toutes à fait normale de ne pas
voir IE s'afficher dans l'écran de bureau de l'utilisateur interactif
puisqu'il doit être affiché dans l'écran de bureau des services
non-interactifs.

Exécuter du code en remote et vouloir voir le résultat sur l'écran remote
est quelque peu paradoxal, non ?

Potassez la doc de votre script au sujet de la "workstation" host des
composants distants.
--
Paul Bacelar


<pschittn@icqmail.com> wrote in message
news:1141327042.721820.100510@u72g2000cwu.googlegroups.com...
Aux experts en windows scripting,
voila un pb épineux sur lequel je galère depuis un bon moment. En
quelques mots, je souhaiterais, depuis un script éxécuté sur un
serveur, lancé un second script sur une machine distante. Jusque là,
aucun PB, tout baigne, WSH offre tout ce qu'il faut, sauf que dans ce
cas, dans le second script, j'instancie un objet Internet.Explorer(IE)
et bien que l'instanciation réusisse, je n'arrive pas à afficher la
fenêtre IE.
J'ai déjà tordu le PB dans tous les sens, utilisé un composant wsc
enregistré en bonne et due forme pour gérer IE, essayé avec HTA,
ect, ect, dans tous les cas le second script s'éxécute bien sur la
machine distante, je peux le débogguer, mais en aucun cas, je n'arrive
à afficher IE.
Le + étrange est qu'en local, machine serveur = machine distante, la
fenêtre s'affiche sans broncher !!?

Voici quelques points clés des différents scripts utilisés :

1) commande que je lance depuis le serveur :
wscritp //D //X rscript.wsf /h "nomMachineDistante"
/p:"chemin+nomDuScriptExecuteLocalement.wsf"

rscript.wsf :

...
'initializate the execution of the script on the target host
set o_process = o_wsh_ctler.CreateScript(s_cmdLine,
o_dict_hosts.item(i))

'connection succeeds
if err = 0 then
'connect to the remote script to catch errors
wscript.ConnectObject o_process, "o_process_"
o_process.Execute

'pooling till the end of the process execution
While o_process.Status <> 2
wscript.Sleep 100
WEnd

'disconnect from the remote script
wscript.DisconnectObject o_process
...

s_cmdLine : chemin & nom du script à lancer
o_dict_hosts.item(i) : nom de la machine sur laquelle lancer le script

3) script éxécuté localement :

...
'Instantiate an object IE
set oIE = createObject("InternetExplorer.Application")

'Initializate this object
oIE.navigate ""& sScriptPath" & "svgauto.htm" & ""
oIE.width = 400
oIE.height = 380
oIE.toolBar = 0
oIE.menuBar = 0
oIE.statuBar = 0

'Wait till IE is ready
do
wscript.sleep 100
loop while oIE.busy = 1

oIE.visible = true
...

Quand ce script est lancé par un autre script depuis une autre
machine, la ligne oIE.visible, n'a strictement aucun effet alors que
toutes les autres propriétés, width, height, ect sont accessibles en
écriture.

Etonnant non ?

Je pense que DCOM qui est utilisé par WSH derrière tous ces
mécanismes de remote scripting est à l'origine de mon PB mais comment
m'en défaire ?
Coté sécurité, tout a été vérifié, la machine serveur a le même
compte administrateur que la machine distante.

Une idée ?

Merci d'avance

Bonjour et merci de votre aide,

Mon niveau de connaissances DCOM, remote scripting en WSH, coté
système, m'interdit de pousser l'analyse jusque là et malheureusement
la SDK Windows ne fournit pas beaucoup de détails quant aux coulisses
du remote scripting en WSH. Mais ce que vous étayer est, en effet, une
piste sérieuse. Le script, envoyé pour être exécuté sur une
machine cible, s'exécute bien sur cette machine puisqu'au déboggage
rien ne m'est signalé. Par contre, il semblerait que celui s'exécute
dans un contexte différent de celui du bureau interactif.

Je ne connais pas le script "rscript.wsf " mas je pense que le composant
distant chargé de lancé le script est un service et, comme tous les se rvices
non-interactifs, il utilise la workstation (contexte de sécurité et
d'affichage) des services.

C'est probablement le cas mais je doute que ceci soit paramétrable. Le
mécanisme de remote scripting offert par WSH est assez succint et,
peut être, est-il limité à l'exécution de scripts non interactifs ?
Je vais tout de même me pencher davantage sur la question.
Le script, "rscript.wsf ", est un script, WSH, que j'ai créé pour
pouvoir lancer un second script WSH ou autre sur n'importe quelle
machine de notre réseau local. Ce script, ajouté à toutes les
possibilités offertes par WMI m'a permis de collecter de nombreuses
informations et de réaliser diverses tâches administratives de
manière totalement transparente pour les utilisateurs, sans avoir à
me déplacer devant les machines en question. Mais jusqu'à présent je
ne lançais que des scripts non interactifs. En parcourant diverses
sources d'info. sur Internet j'ai remarqué qu'il était possible de
piloter, depuis un script, une petite interface graphique grâce à
l'objet activeX "Internet.Explorer". C'est exactement ce que je tente
d'implémenter aujourd'hui mais avec la difficulté supplémentaire que
de pouvoir le faire à distance en réutilisant mon mécanisme de
lancement de scripts.

Dans ce script, j'utilise l'objet WSHController et sa méthode
CreateScript(script_à_exécuter, host_distant) pour lancer le script :

set o_wsh_ctler = CreateObject("WSHController")

'initializate the execution of the script on the target host
set o_process = o_wsh_ctler.CreateScript(s_cmdLine,
o_dict_hosts.item(i))

'connection succeeds
if err = 0 then
'connect to the remote script to catch errors
wscript.ConnectObject o_process, "o_process_"
o_process.Execute

Malheureusement, je ne pense pas que cet objet ne permette de choisir
le bureau sur lequel sur lequel sera exécuté le script. Il existe
d'autres possiblités d'imlpémenter ce même mécanisme :
- Avec WMI,
set objSvc = GetObject("winmgmts:" &
"{impersonationLevel=impersonate}!\" & o_dict_hosts.item(0) &
"rootcimv2:Win32_Process)

- Avec l'objet WbemScripting.SWbemLocator,
set objLoc = WScript.CreateObject("WbemScripting.SWbemLocator")
sa méthode ConnectServer,
Set objSvc = objLoc.ConnectServer(host,, "domainlogin", "pwd")
et la méthode get,
set oProcess = objSvc.get("Win32_Process")

Je vais étudier ces autres possibilités + en profondeur.

Les 3 écrans (login, bureau et screensaver) de la workstation des servic es
ne sont pas les écrans de l'utilisateur interactif.

Merci pour l'info.

Donc, si mes hypothèses sont bonnes, il est toutes à fait normale de n e pas
voir IE s'afficher dans l'écran de bureau de l'utilisateur interactif
puisqu'il doit être affiché dans l'écran de bureau des services
non-interactifs.

En effet.

Exécuter du code en remote et vouloir voir le résultat sur l'écran r emote
est quelque peu paradoxal, non ?

Dans mon cas de figure le coté "remote" de cette appli. ne
m'intéresse pas tant pour l'interface graphique affichée en remote
mais plutôt pour connaître l'option choisie par l'utilisateur, grâce
à cette interface graphique. En fait, derrière ce mécanisme, se
cache une autre interaction + importante, moteur de sauvegarde <->
Utilisateur de la machine sauvegardée. Je m'explique, nous avons un
système de sauvegarde (BrightStore Arcserve) qui effectue des
sauvegardes journalières de nos machines en réseau. Ces sauvegardes
sont lancées vers 13H00 et je souhaiterais que l'utilisateur, soit
prévenu de la sauvegarde et qu'il puisse soit refuser
exceptionnellement la sauvegarde soit la repousser. Le moteur de
sauvegarde offre la possibilité pour chaque "job" d'éffectué une
"pré"-opération en donnant accès à l'interpréteur de commandes
Windows. Pour chaque job on peut également paramétrer des codes de
retour de commandes qui soit ordonneront la sauvegarde soit la
refuseront. Cette fameuse pré-opération est ma commande wscritp
rscript.wsf /h "remote_host" /p:"GUI_script"
ou
rscript.wsf est chargé de lancer un script sur une machine distante et
de faire remonter un code de retour au moteur de job
/h est le nom de la machine distante
/p est le script chargé de piloter l'interface graphique pour que
l'utilisateur choisisse ou non la sauvegarde.

Potassez la doc de votre script au sujet de la "workstation" host des
composants distants.
--
Paul Bacelar

<pschi...@icqmail.com> wrote in message


news:1141327042.721820.100510@u72g2000cwu.googlegroups.com...

Après une rapide recherche sur le Web, mes hypothèses se sont confirmées.

Le script est bien exécuté dans un bac à sable des services avec comme
utilisateur, l'identité de l'appelant.

Un moyen de passer outre est d'instancier ces objets COM dans des processus
qui ont accès au bureau interactif comme les services qui sont marqués comme
tel (voir les options des services sur la machine hôte). En résumé, le
script pilotera un autre service pour faire l'affichage.

Je pense que développer un service de notification sera plus simple que
d'utiliser le Remoting script.
--
Paul Bacelar

<pschittn@icqmail.com> wrote in message
news:1141383188.592053.71690@v46g2000cwv.googlegroups.com...
Bonjour et merci de votre aide,

Mon niveau de connaissances DCOM, remote scripting en WSH, coté
système, m'interdit de pousser l'analyse jusque là et malheureusement
la SDK Windows ne fournit pas beaucoup de détails quant aux coulisses
du remote scripting en WSH. Mais ce que vous étayer est, en effet, une
piste sérieuse. Le script, envoyé pour être exécuté sur une
machine cible, s'exécute bien sur cette machine puisqu'au déboggage
rien ne m'est signalé. Par contre, il semblerait que celui s'exécute
dans un contexte différent de celui du bureau interactif.

Je ne connais pas le script "rscript.wsf " mas je pense que le composant
distant chargé de lancé le script est un service et, comme tous les
services
non-interactifs, il utilise la workstation (contexte de sécurité et
d'affichage) des services.

C'est probablement le cas mais je doute que ceci soit paramétrable. Le
mécanisme de remote scripting offert par WSH est assez succint et,
peut être, est-il limité à l'exécution de scripts non interactifs ?
Je vais tout de même me pencher davantage sur la question.
Le script, "rscript.wsf ", est un script, WSH, que j'ai créé pour
pouvoir lancer un second script WSH ou autre sur n'importe quelle
machine de notre réseau local. Ce script, ajouté à toutes les
possibilités offertes par WMI m'a permis de collecter de nombreuses
informations et de réaliser diverses tâches administratives de
manière totalement transparente pour les utilisateurs, sans avoir à
me déplacer devant les machines en question. Mais jusqu'à présent je
ne lançais que des scripts non interactifs. En parcourant diverses
sources d'info. sur Internet j'ai remarqué qu'il était possible de
piloter, depuis un script, une petite interface graphique grâce à
l'objet activeX "Internet.Explorer". C'est exactement ce que je tente
d'implémenter aujourd'hui mais avec la difficulté supplémentaire que
de pouvoir le faire à distance en réutilisant mon mécanisme de
lancement de scripts.

Dans ce script, j'utilise l'objet WSHController et sa méthode
CreateScript(script_à_exécuter, host_distant) pour lancer le script :

set o_wsh_ctler = CreateObject("WSHController")

'initializate the execution of the script on the target host
set o_process = o_wsh_ctler.CreateScript(s_cmdLine,
o_dict_hosts.item(i))

'connection succeeds
if err = 0 then
'connect to the remote script to catch errors
wscript.ConnectObject o_process, "o_process_"
o_process.Execute

Malheureusement, je ne pense pas que cet objet ne permette de choisir
le bureau sur lequel sur lequel sera exécuté le script. Il existe
d'autres possiblités d'imlpémenter ce même mécanisme :
- Avec WMI,
set objSvc = GetObject("winmgmts:" &
"{impersonationLevel=impersonate}!\" & o_dict_hosts.item(0) &
"rootcimv2:Win32_Process)

- Avec l'objet WbemScripting.SWbemLocator,
set objLoc = WScript.CreateObject("WbemScripting.SWbemLocator")
sa méthode ConnectServer,
Set objSvc = objLoc.ConnectServer(host,, "domainlogin", "pwd")
et la méthode get,
set oProcess = objSvc.get("Win32_Process")

Je vais étudier ces autres possibilités + en profondeur.

Les 3 écrans (login, bureau et screensaver) de la workstation des services
ne sont pas les écrans de l'utilisateur interactif.

Merci pour l'info.

Donc, si mes hypothèses sont bonnes, il est toutes à fait normale de ne pas
voir IE s'afficher dans l'écran de bureau de l'utilisateur interactif
puisqu'il doit être affiché dans l'écran de bureau des services
non-interactifs.

En effet.

Exécuter du code en remote et vouloir voir le résultat sur l'écran remote
est quelque peu paradoxal, non ?

Dans mon cas de figure le coté "remote" de cette appli. ne
m'intéresse pas tant pour l'interface graphique affichée en remote
mais plutôt pour connaître l'option choisie par l'utilisateur, grâce
à cette interface graphique. En fait, derrière ce mécanisme, se
cache une autre interaction + importante, moteur de sauvegarde <->
Utilisateur de la machine sauvegardée. Je m'explique, nous avons un
système de sauvegarde (BrightStore Arcserve) qui effectue des
sauvegardes journalières de nos machines en réseau. Ces sauvegardes
sont lancées vers 13H00 et je souhaiterais que l'utilisateur, soit
prévenu de la sauvegarde et qu'il puisse soit refuser
exceptionnellement la sauvegarde soit la repousser. Le moteur de
sauvegarde offre la possibilité pour chaque "job" d'éffectué une
"pré"-opération en donnant accès à l'interpréteur de commandes
Windows. Pour chaque job on peut également paramétrer des codes de
retour de commandes qui soit ordonneront la sauvegarde soit la
refuseront. Cette fameuse pré-opération est ma commande wscritp
rscript.wsf /h "remote_host" /p:"GUI_script"
ou
rscript.wsf est chargé de lancer un script sur une machine distante et
de faire remonter un code de retour au moteur de job
/h est le nom de la machine distante
/p est le script chargé de piloter l'interface graphique pour que
l'utilisateur choisisse ou non la sauvegarde.

Potassez la doc de votre script au sujet de la "workstation" host des
composants distants.
--
Paul Bacelar

<pschi...@icqmail.com> wrote in message


news:1141327042.721820.100510@u72g2000cwu.googlegroups.com...