Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles RONSIN
xho7 , le dim. 23 oct. 2005 00:54:07, écrivait ceci:
Bonjour, Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs. Regedit HKEY_CLASSES_ROOTVBSFileShellOpenCommand par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut %SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce niveau l'exécution de script. Si c'est volontaire, il faut vérifier que l'appli de controle est toujours valide, sinon rétablir avec la valeur par défaut.
-- Embryon de site : http://gilles.ronsin.free.fr Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0 Il est impossible pour un optimiste d'être agréablement surpris.
xho7 <xho7@NospaMfree.fr.invalid>, le dim. 23 oct. 2005 00:54:07,
écrivait ceci:
Bonjour,
Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en
double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs.
Regedit
HKEY_CLASSES_ROOTVBSFileShellOpenCommand
par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut
%SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce
niveau l'exécution de script. Si c'est volontaire, il faut vérifier que
l'appli de controle est toujours valide, sinon rétablir avec la valeur
par défaut.
--
Embryon de site : http://gilles.ronsin.free.fr
Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0
Il est impossible pour un optimiste d'être agréablement surpris.
xho7 , le dim. 23 oct. 2005 00:54:07, écrivait ceci:
Bonjour, Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs. Regedit HKEY_CLASSES_ROOTVBSFileShellOpenCommand par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut %SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce niveau l'exécution de script. Si c'est volontaire, il faut vérifier que l'appli de controle est toujours valide, sinon rétablir avec la valeur par défaut.
-- Embryon de site : http://gilles.ronsin.free.fr Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0 Il est impossible pour un optimiste d'être agréablement surpris.
Xho7
xho7 , le dim. 23 oct. 2005 00:54:07, écrivait ceci:
Bonjour,
Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs. Regedit HKEY_CLASSES_ROOTVBSFileShellOpenCommand par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut %SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce niveau l'exécution de script. Si c'est volontaire, il faut vérifier que l'appli de controle est toujours valide, sinon rétablir avec la valeur par défaut.
Giles, merci de ta réponse.
Je me rends compte que ce matin (tôt mais tard) j'avais été plutôt lapidaire. Qqs précisions complémentaires donc.
Ma babasse tourne sous WinXP SP2 home tous correctifs déployés.
J'avais réinstallé le run time vbs il y a qqs temps après qu'un pgm aussi indélicat qu'inutile ne l'ai désinstallé en même temps que lui-même. J'ai réinstallé à partir d'ici si mes souvenirs sont bons : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyIDÇ17d943-7e4b-4622-86eb-95a22b832caa Après les pgm qui reposaient sur des ocx re-fonctionnaient.
J'avais il y a pas mal de temps aussi lancé un script qui éttait sensé vous protéger compte les virus en vbs ou dans shs, mais il me semble bien que l'ai viré ensuite. Presque sûr même.
Pour faire suite à tes conseils voici ce que j'ai fait et où j'en suis .
J'ai vérifié la clé REG_SZ ; elle contenait : C:WINDOWSPatchVbsShs.exe VBS "%1" %*
Hum. J'avais pourtant déjà restauré les params dans les options des dossiers et j'avais déjà vu et corrigé cette entrée zarbie. J'ai remplacé la valeur par celle que tu indiques et j'ai fait une recherche de toute autre entrée avec PatchVbsShs.exe dans la base des reg et j'en ai trouvé une autre que j'ai modifiée avec wscript.exe
Le pb n'était pas résolu.
J'ai vérifié qu'aucun anti<que chose> n'était actif et j'ai désactivé l'antispyware Beta de Microsoft en cours sur la babasse : tjs pas résolu.
J'ai alors ouvert les proprétés du vbs de test que j'ai créé : oh ! surprise, la fenêtre disait qu'il n'était associé à aucun programme ; je l'ai donc associé avec le WScript.exe de Windows/system32 et je peux maintenant exécuter mon test : strChaine1 = "Ceci est un test" strChaine2 = " - Nous allons voir si ça fonctionne" strChaine3 = strChaine1 & strChaine2 Msgbox strChaine3
La Msgbox s'affiche !
En revanche, lorsque je "clique droit > Modifier" j'ai à nouveau le message "Pas autorisé". Bon j'ouvre dans jEdit et c'est bon, mais c'est tout de même zarbi cette affaire, surtout que je ne peux tjs pas exécuter les fichiers *.wsf
Si tu as une autre bonne idée je reste preneur, mais je te remercie d'emblée puisque je devrais pouvoir commencer à tester qqs scipts que j'envisage pour automatiser des opérations sur de postes clients.
5 ioux.
-- Xho7
"Faire et défaire c'est tpujours travailler" Ducon
xho7 <xho7@NospaMfree.fr.invalid>, le dim. 23 oct. 2005 00:54:07,
écrivait ceci:
Bonjour,
Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en
double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs.
Regedit
HKEY_CLASSES_ROOTVBSFileShellOpenCommand
par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut
%SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce
niveau l'exécution de script. Si c'est volontaire, il faut vérifier que
l'appli de controle est toujours valide, sinon rétablir avec la valeur
par défaut.
Giles, merci de ta réponse.
Je me rends compte que ce matin (tôt mais tard) j'avais été plutôt
lapidaire. Qqs précisions complémentaires donc.
Ma babasse tourne sous WinXP SP2 home tous correctifs déployés.
J'avais réinstallé le run time vbs il y a qqs temps après qu'un pgm
aussi indélicat qu'inutile ne l'ai désinstallé en même temps que
lui-même. J'ai réinstallé à partir d'ici si mes souvenirs sont bons :
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyIDÇ17d943-7e4b-4622-86eb-95a22b832caa
Après les pgm qui reposaient sur des ocx re-fonctionnaient.
J'avais il y a pas mal de temps aussi lancé un script qui éttait sensé
vous protéger compte les virus en vbs ou dans shs, mais il me semble
bien que l'ai viré ensuite. Presque sûr même.
Pour faire suite à tes conseils voici ce que j'ai fait et où j'en suis .
J'ai vérifié la clé REG_SZ ; elle contenait :
C:WINDOWSPatchVbsShs.exe VBS "%1" %*
Hum. J'avais pourtant déjà restauré les params dans les options des
dossiers et j'avais déjà vu et corrigé cette entrée zarbie.
J'ai remplacé la valeur par celle que tu indiques et j'ai fait une
recherche de toute autre entrée avec PatchVbsShs.exe dans la base des
reg et j'en ai trouvé une autre que j'ai modifiée avec wscript.exe
Le pb n'était pas résolu.
J'ai vérifié qu'aucun anti<que chose> n'était actif et j'ai désactivé
l'antispyware Beta de Microsoft en cours sur la babasse : tjs pas résolu.
J'ai alors ouvert les proprétés du vbs de test que j'ai créé : oh !
surprise, la fenêtre disait qu'il n'était associé à aucun programme ; je
l'ai donc associé avec le WScript.exe de Windows/system32 et je peux
maintenant exécuter mon test :
strChaine1 = "Ceci est un test"
strChaine2 = " - Nous allons voir si ça fonctionne"
strChaine3 = strChaine1 & strChaine2
Msgbox strChaine3
La Msgbox s'affiche !
En revanche, lorsque je "clique droit > Modifier" j'ai à nouveau le
message "Pas autorisé". Bon j'ouvre dans jEdit et c'est bon, mais c'est
tout de même zarbi cette affaire, surtout que je ne peux tjs pas
exécuter les fichiers *.wsf
Si tu as une autre bonne idée je reste preneur, mais je te remercie
d'emblée puisque je devrais pouvoir commencer à tester qqs scipts que
j'envisage pour automatiser des opérations sur de postes clients.
5 ioux.
--
Xho7
"Faire et défaire c'est tpujours travailler"
Ducon
xho7 , le dim. 23 oct. 2005 00:54:07, écrivait ceci:
Bonjour,
Salut,
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Il faut regarder quelle est l'appli déclarée pour lancer les vbs. Regedit HKEY_CLASSES_ROOTVBSFileShellOpenCommand par défaut tu devrais avoir une valeur REG_EXPAND_SZ qui vaut %SystemRoot%System32WScript.exe "%1" %*
Il est possible que certains outils de sécurité interceptent à ce niveau l'exécution de script. Si c'est volontaire, il faut vérifier que l'appli de controle est toujours valide, sinon rétablir avec la valeur par défaut.
Giles, merci de ta réponse.
Je me rends compte que ce matin (tôt mais tard) j'avais été plutôt lapidaire. Qqs précisions complémentaires donc.
Ma babasse tourne sous WinXP SP2 home tous correctifs déployés.
J'avais réinstallé le run time vbs il y a qqs temps après qu'un pgm aussi indélicat qu'inutile ne l'ai désinstallé en même temps que lui-même. J'ai réinstallé à partir d'ici si mes souvenirs sont bons : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyIDÇ17d943-7e4b-4622-86eb-95a22b832caa Après les pgm qui reposaient sur des ocx re-fonctionnaient.
J'avais il y a pas mal de temps aussi lancé un script qui éttait sensé vous protéger compte les virus en vbs ou dans shs, mais il me semble bien que l'ai viré ensuite. Presque sûr même.
Pour faire suite à tes conseils voici ce que j'ai fait et où j'en suis .
J'ai vérifié la clé REG_SZ ; elle contenait : C:WINDOWSPatchVbsShs.exe VBS "%1" %*
Hum. J'avais pourtant déjà restauré les params dans les options des dossiers et j'avais déjà vu et corrigé cette entrée zarbie. J'ai remplacé la valeur par celle que tu indiques et j'ai fait une recherche de toute autre entrée avec PatchVbsShs.exe dans la base des reg et j'en ai trouvé une autre que j'ai modifiée avec wscript.exe
Le pb n'était pas résolu.
J'ai vérifié qu'aucun anti<que chose> n'était actif et j'ai désactivé l'antispyware Beta de Microsoft en cours sur la babasse : tjs pas résolu.
J'ai alors ouvert les proprétés du vbs de test que j'ai créé : oh ! surprise, la fenêtre disait qu'il n'était associé à aucun programme ; je l'ai donc associé avec le WScript.exe de Windows/system32 et je peux maintenant exécuter mon test : strChaine1 = "Ceci est un test" strChaine2 = " - Nous allons voir si ça fonctionne" strChaine3 = strChaine1 & strChaine2 Msgbox strChaine3
La Msgbox s'affiche !
En revanche, lorsque je "clique droit > Modifier" j'ai à nouveau le message "Pas autorisé". Bon j'ouvre dans jEdit et c'est bon, mais c'est tout de même zarbi cette affaire, surtout que je ne peux tjs pas exécuter les fichiers *.wsf
Si tu as une autre bonne idée je reste preneur, mais je te remercie d'emblée puisque je devrais pouvoir commencer à tester qqs scipts que j'envisage pour automatiser des opérations sur de postes clients.
5 ioux.
-- Xho7
"Faire et défaire c'est tpujours travailler" Ducon
Jean-Claude BELLAMY
Dans le message :, xho7 a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait 'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con) configurée de travers (par qui, çà c'est une autre histoire!), qui interdit l'exécution de scripts. Je t'invite donc à aller faire un tour du côté des clefs HKCUSOFTWAREMicrosoftWindows Script HostSettings HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une REG_DWORD) Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition : 0 -> exécution de tous les scripts 1 -> dans le cas de script non signé, il est demandé à l'utilisateur s'il veut l'exécuter. 2 -> exécution suelement des scripts signés
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :MPG.1dc4e17b835ca49e989686@news.free.fr,
xho7 <xho7@NospaMfree.fr.invalid> a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de
solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en
double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque
cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait
'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con)
configurée de travers (par qui, çà c'est une autre histoire!), qui interdit
l'exécution de scripts.
Je t'invite donc à aller faire un tour du côté des clefs
HKCUSOFTWAREMicrosoftWindows Script HostSettings
HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une
REG_DWORD)
Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition :
0 -> exécution de tous les scripts
1 -> dans le cas de script non signé, il est demandé
à l'utilisateur s'il veut l'exécuter.
2 -> exécution suelement des scripts signés
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - Jean-Claude.Bellamy@wanadoo.fr
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :, xho7 a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait 'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con) configurée de travers (par qui, çà c'est une autre histoire!), qui interdit l'exécution de scripts. Je t'invite donc à aller faire un tour du côté des clefs HKCUSOFTWAREMicrosoftWindows Script HostSettings HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une REG_DWORD) Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition : 0 -> exécution de tous les scripts 1 -> dans le cas de script non signé, il est demandé à l'utilisateur s'il veut l'exécuter. 2 -> exécution suelement des scripts signés
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Gilles RONSIN
Xho7 , le dim. 23 oct. 2005 14:52:35, écrivait ceci:
Re,
Si tu as une autre bonne idée je reste preneur, mais je te remercie d'emblée puisque je devrais pouvoir commencer à tester qqs scipts que j'envisage pour automatiser des opérations sur de postes clients. Regarde quand même les clés citées par Me JCB (expert Es-Scripting en
tout genre) Sinon tu peux taper dans une ligne de commande
wscript //h:wscript
pour rétablir wscript comme moteur par défaut...
-- Embryon de site : http://gilles.ronsin.free.fr Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0 Il est impossible pour un optimiste d'être agréablement surpris.
Xho7 <Xho7@nospamplease.nospam>, le dim. 23 oct. 2005 14:52:35,
écrivait ceci:
Re,
Si tu as une autre bonne idée je reste preneur, mais je te
remercie d'emblée puisque je devrais pouvoir commencer à tester
qqs scipts que j'envisage pour automatiser des opérations sur de
postes clients.
Regarde quand même les clés citées par Me JCB (expert Es-Scripting en
tout genre)
Sinon tu peux taper dans une ligne de commande
wscript //h:wscript
pour rétablir wscript comme moteur par défaut...
--
Embryon de site : http://gilles.ronsin.free.fr
Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0
Il est impossible pour un optimiste d'être agréablement surpris.
Xho7 , le dim. 23 oct. 2005 14:52:35, écrivait ceci:
Re,
Si tu as une autre bonne idée je reste preneur, mais je te remercie d'emblée puisque je devrais pouvoir commencer à tester qqs scipts que j'envisage pour automatiser des opérations sur de postes clients. Regarde quand même les clés citées par Me JCB (expert Es-Scripting en
tout genre) Sinon tu peux taper dans une ligne de commande
wscript //h:wscript
pour rétablir wscript comme moteur par défaut...
-- Embryon de site : http://gilles.ronsin.free.fr Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0 Il est impossible pour un optimiste d'être agréablement surpris.
Xho7
Dans le message :, xho7 a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait 'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con) configurée de travers (par qui, çà c'est une autre histoire!), qui interdit l'exécution de scripts. Je t'invite donc à aller faire un tour du côté des clefs HKCUSOFTWAREMicrosoftWindows Script HostSettings HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une REG_DWORD) Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition : 0 -> exécution de tous les scripts 1 -> dans le cas de script non signé, il est demandé à l'utilisateur s'il veut l'exécuter. 2 -> exécution suelement des scripts signés
Merci JCB (je viens de faire la relation avec la dernière réponse de Gilles et en allant sur ton site) pour cette piste. J'ai vérifié les clés que tu indiques et il n'y avait rien d'anormal : --> 1 J'ai mis - transitoirement - 0, sans changement pour l'édition des .vbs et l'exécution des .wsf
Pour ce qui concerne une stratégie de sécurité, il n'y a pas de console pour modifier ça sur XP home édition ? Non ? Si une modif a été faite c'est donc vraisemblablement par un programme, ce qui est fort possible quand je pense à tout ce qui a été installé/désinstallé sur cette babasse depuis qu'elle s'est animée...
Je vais passer un peu de temps sur ton site qui est une mine !
-- Xho7
"Faire et défaire c'est toujours travailler" Ducon
Dans le message :MPG.1dc4e17b835ca49e989686@news.free.fr,
xho7 <xho7@NospaMfree.fr.invalid> a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de
solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en
double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque
cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait
'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con)
configurée de travers (par qui, çà c'est une autre histoire!), qui interdit
l'exécution de scripts.
Je t'invite donc à aller faire un tour du côté des clefs
HKCUSOFTWAREMicrosoftWindows Script HostSettings
HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une
REG_DWORD)
Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition :
0 -> exécution de tous les scripts
1 -> dans le cas de script non signé, il est demandé
à l'utilisateur s'il veut l'exécuter.
2 -> exécution suelement des scripts signés
Merci JCB (je viens de faire la relation avec la dernière réponse de
Gilles et en allant sur ton site) pour cette piste. J'ai vérifié les
clés que tu indiques et il n'y avait rien d'anormal : --> 1
J'ai mis - transitoirement - 0, sans changement pour l'édition des .vbs
et l'exécution des .wsf
Pour ce qui concerne une stratégie de sécurité, il n'y a pas de console
pour modifier ça sur XP home édition ? Non ? Si une modif a été faite
c'est donc vraisemblablement par un programme, ce qui est fort possible
quand je pense à tout ce qui a été installé/désinstallé sur cette
babasse depuis qu'elle s'est animée...
Je vais passer un peu de temps sur ton site qui est une mine !
--
Xho7
"Faire et défaire c'est toujours travailler"
Ducon
Dans le message :, xho7 a pris la peine d'écrire ce qui suit :
Bonjour,
J'ai un pb simple à décrire mais pour lequel je n'ai pas trouvé de solution.
Lorsque j'exécute un VBScript, par une fenêtre de commande ou en double clic, j'ai systèmatiquement un mesage : Accès refusé
Même lorsque le fichier.vbs est vide, son extension en .vbs provoque cet "Accès refusé".
Si qqu'un avait une idée, voire même la solution :) ça serait 'achement sympa.
Oh ce truc, çà sent à plein une SSALC (stratégie de sécurité à la con) configurée de travers (par qui, çà c'est une autre histoire!), qui interdit l'exécution de scripts. Je t'invite donc à aller faire un tour du côté des clefs HKCUSOFTWAREMicrosoftWindows Script HostSettings HKLMSOFTWAREMicrosoftWindows Script HostSettings
et examine (si elle existe) la valeur de l'entrée "TrustPolicy" (c'est une REG_DWORD) Suivant sa valeur, les scripts sont exécutés ou non ou sous-condition : 0 -> exécution de tous les scripts 1 -> dans le cas de script non signé, il est demandé à l'utilisateur s'il veut l'exécuter. 2 -> exécution suelement des scripts signés
Merci JCB (je viens de faire la relation avec la dernière réponse de Gilles et en allant sur ton site) pour cette piste. J'ai vérifié les clés que tu indiques et il n'y avait rien d'anormal : --> 1 J'ai mis - transitoirement - 0, sans changement pour l'édition des .vbs et l'exécution des .wsf
Pour ce qui concerne une stratégie de sécurité, il n'y a pas de console pour modifier ça sur XP home édition ? Non ? Si une modif a été faite c'est donc vraisemblablement par un programme, ce qui est fort possible quand je pense à tout ce qui a été installé/désinstallé sur cette babasse depuis qu'elle s'est animée...
Je vais passer un peu de temps sur ton site qui est une mine !
-- Xho7
"Faire et défaire c'est toujours travailler" Ducon
