Discussion :

[Heffgé]

Bonjour,

Je suis sous Windows 7 intégrale et lorsque je déclare via gpedit le nom d'un script à exécuter au niveau Windows, aussi bien à la mise sous tension qu'à l'arrêt, il ne s'exécute pas.

Initialement je testais avec un script en vbs ce qui m'a conduit à poser une question semblable dans le forum vbscript (ici) mais qui n'a pas eu de réponse. Sans doute parce que le problème n'a rien avoir avec vbs.

En effet, depuis j'ai testé avec un fichier bat rudimentaire :

echo passage dans script >> J:\scr.txt

J: est une partition de test

Dans l'observateur d'événements, au niveau Windows\GPO, je constate qu'une erreur est survenue : code 5, accès refusé.

Pourtant d'après cette page, un script déclaré au niveau Windows s'exécute en mode système et bénéficie de toutes les autorisations.

Je ne rencontre pas ce problème avec un script au niveau utilisateur (ouverture ou fermeture de session). Dois-je en déduire qu'il n'est pas possible d'éxécuter un script local (sans présence d'un serveur de domaine) aussi bien au démarrage qu'à l'arrêt de Windows ? De mémoire je n'avais pas ce problème sous Windows XP.

Vos suggestions seront les bienvenues et je vous en remercie par avance.

[dmganges]

Bonjour,
Je ne viens plus souvent, mais je suis passé par là, et j'ai vu de la lumière...

Perso je lance un .bat à la fermeture de Windows7 en GPO, ça sauvegarde le dernier fichier bookmarks de Firefox et ça envoi un mail avec Perl... Ça se passe bien.
NB : Je suis sur un compte qui a les droits Administrateur.

En ce qui te concerne il faut déterminer :
- si c'est la partition J: qui est inaccessible, ou
- si c'est le script (que ça soit un .bat ou un vbs).

Si tu fermes le PC alors que tu n'es pas Administrateur, essaye :

- En tant qu'administrateur de donner tous les droits à ton script.
Le mien ressemble à la pièce jointe Mime.jpg
NB : Système, Michel et Administrateurs ont Contrôle total.

Si ça fonctionne, on verra après pour les conséquences de sécurité...

Sinon fais un script encore plus simple : qui ne tente pas d'aller sur une autre partition du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
echo passage dans script
timeout 20

Ainsi à la fermeture tu devrais voir l'invite Windows attendre 20 secondes...
(Pas testé)

[Heffgé]

J'ai été absent pendant quelques jours et je viens de découvrir ton message.

Tout d'abord un grand merci pour avoir bien voulu te pencher sur le problème que je rencontre. Avant de te répondre j'ai procédé à quelques tests pour mieux délimiter ses contours et pour l'instant le constat est le suivant :
- aucun problème sous XP (j'ai conservé une machine virtuelle sous XP) ;
- OK pour les scripts au niveau session, ouverture ou fermeture (exécution visible au travers de l'observateur d'événements) ;
- les scripts au niveau machine (démarrage ou arrêt) ne s'exécutent pas.

Le type du script et ce qu'il fait ne semblent pas en cause. J'ai fait un batch encore plus rudimentaire que lors de mes précédents essais. Après avoir créé la variable d'environnement test, au niveau système, je tente de modifier sa valeur :

setx test marche

Bien sûr j'ai testé que lancé manuellement ce script fonctionnait. Dans l'observateur d'événements j'otiens :

Après recherche ce code 5 signifierait un refus d'accès. Puisque j'ai cette même erreur quel que soit le script ce doit être une question de privilèges, soit pour l'accès au fichier qui contient le script, soit pour son exécution. Ça sent l'UAC (ça n'existait pas sous XP) mais je ne vois pas ce qui coince. Ce n'est pas une question d'utilsateur puisque dans cette phase aucune session n'est ouverte (pas encore ouverte au démarrage ou déjà fermée à l'arrêt). On est sous SYSTEM qui as tous les droits.

Je ne sais pas si cela a une importance mais quand je vais dans les propriétés du fichier j'ai ceci :

À ce stade, s'il faut effectivement donner au script le droit de s'exécuter en tant qu'administrateur (qu'il s'agisse d'un bat ou d'un vbs) j'ignore comment le faire puisque dans la fenêtre ci-dessus la case est grisée.

Si tu as d'autres suggestions elles sont bien sûr les bienvenues.

[dmganges]

Bonjour Heffgé,
- Je suis étonné qu'ici ton problème n'ait pas intéressé ici de vrais spécialistes de Windows, probablement à cause des vacances, mais dans quelques jours ils seront tous là car :
- Perso je ne connais pas très bien Windows, je suis un vieux (même très vieux d'Unix, nul n'est parfait) mais j'ai dû m'y mettre par la force des choses... Ceci dit pour t'inviter à être prudent dans ce que je suggèrerai, et à ne pas te faire d'illusion...
- Mais en procédant pas à pas, on pourrait y arriver.

D'abord des remarques sur les images que tu as posté :
1) Dans la deuxième, sur les propriétés de test.bat, le look me semble ancien :
Q1) Ton Windows 7 est-il à jour, avec entre autre le SP1 ? (si mes souvenirs sont bons).
2) Toujours sur propriétés de test.bat :
Q2) Que se passe t-il lorsque tu cliques sur le bouton en dessous de Niveau de privilège ?
- As-tu un mot de passe à saisir ?
- Vois-tu l'ensemble des utilisateurs ? et notamment celui qui a écrit test.bat.

Maintenant de mon côté :
C'est vieux, mais il me semble me souvenir avoir eu également des problèmes de droit à résoudre...
Visiblement, j'ai dû ajouter spécifiquement l'utilisateur Michel à partir duquel je me connecte, et qui a écrit Mime.bat
Si dessous dans l'image jointe, on voit au même niveau un répertoire _ASTRO_SITE qui n'a pas besoin de l'utilisateur Michel.
Par contre le répertoire _APPLI (dans lequel j'ai toutes mes applis, dont le répertoire Mime, qui contient Mime.bat :
J'ai visiblement dû ajouter l'utilisateur Michel avec TOUS les droits (coches bleues)

NB : Je suis seul à avoir accès au PC et à écrire des applis, donc je ne me limite pas...

Deux suggestions :
1)
- Copier ton test.bat dans C:\Windows\System32 (si tu es en 32bits) soit SysWOW64 si tu es en 64 bits
- Dans ton script faire la redirection dans l'un de ces répertoires qui convient
Q: Que se passe t-il lorsque tu le lances à la main ?
Q: Idem à travers la GPO Arrêt/Démarrage

2)
- Comme chez moi, directement sur J: (mais il serait bon de faire un répertoire pour y coller ton test.bat) pour ne pas être obligé de faire une gabegie de droits sur toute la partition...
+ s'il n'y est pas, ajouter l'utilisateur qui a écrit test.bat, et lui donner (Bouton Avancé) TOUS les droits (coches bleues)...

Bon courage

PS : Perso chez moi l'UAC est à un niveau pas mal élevé :

[Heffgé]

Ton Windows 7 est-il à jour, avec entre autre le SP1 ?

Mon Windows est bien à jour. Les onglets diffèrent en fonction du type de fichier. Là ce sont d'un bat, les même que ceux d'un exe.

Que se passe t-il lorsque tu cliques sur le bouton en dessous de Niveau de privilège ?

J'ai la fenêtre des options de compatibilité où l'option "Exécuter ce programme ..." est grisée comme dans la précédente.

As-tu un mot de passe à saisir ?

Mon compte d'utilisateur n'est pas protégé par un mot de passe et je suis administrateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Vois-tu l'ensemble des utilisateurs ? et notamment celui qui a écrit test.bat.

Pas à ce niveau et dans l'onglet sécurité tous les groupes déclarés ont le contrôle total par héritage. Mais comme je j'ai dit précédemment le problème n'a a priori aucun rapport avec un compte d'utilisateur puisque au démarrage comme à l'arrêt aucun session n'est ouverte.

Perso chez moi l'UAC est à un niveau pas mal élevé

J'ai le même paramétrage.

Que se passe t-il lorsque tu le lances à la main ?

Aucun problème

Idem à travers la GPO Arrêt/Démarrage

Le script n'est pas exécuté et l'observateur d'événements signale une erreur. Cf. mon précédent message.

A priori mon PC n'est pas en cause. Ces jours derniers j'ai voulu mettre un script au démarrage sur le PC d'un ami, là aussi un bat et là aussi sous Win 7 pro (pas de GPO en familial). Même punition, même motif. J'avais d'ailleurs aussi testé sur une machine virtuelle fraîchement installée, donc avec le paramétrage brut d'install, sans plus de succès.

Chez toi tu dis que ça fonctionne mais avec quelle version de Windows ? Est-ce une GPO locale ou bien es-tu dans un domaine ?

J'ai épluché les services et les fonctions de Windows à ajouter à la demande mais je n'ai rien trouvé qui pourrait expliquer pourquoi ça ne fonctionne pas.

[dmganges]

Bonjour,
Je suis en Windows7 professionnel service Pack 1 (Et non SP1 comme je l'avais mentionné ci-dessus), j'ai 3 PC dans le même environnement, les 3 lancent Mime.bat (uniquement à l'arrêt).
Mes 3 GPO sont bien en local.

Ce qui m'étonne c'est qu'en te connectant en tant qu'administrateur, tu n'es pas accès à la case Exécuter ce programme en tant qu'administrateur

Essaie de mettre un mot de passe sur ce compte, autant il y a une entourloupe... Pas de mot de passe => Pas assez sécurisé pour accorder des droits exorbitants...

As-tu essayé de mettre tes scripts dans C:\system ?
Juste pour voir s'il réagit autrement... après tu enlèves...

Là je n'ai pas d'autre idée, après le repas peut-être...

[Édit 11:55]
Il faut absolument résoudre le pb d'impossibilité d'accorder les droits système à test.bat.
C'est la raison pour laquelle je te demande le pousser dans C:\system pour voir ce qu'il dit...
C'est aprem je ferai d'autres tests...

[dmganges]

J'ai fait quelques tests.
J'ai essayé de me placer dans la même situation que toi.
J'ai une partition TEMPO qui n'a pas d'autorisation spécifique.
J'y ai mis le test.bat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@echo OFF
echo passage dans script à >> F:\test.log
time /T >> F:\test.log

Et pour lequel je n'ai ajouté aucune autorisation spécifique.

Mais je suis connecté en tant que Michel qui est Administrateur.
NB: Système & Administrateurs héritent d'un contrôle total

Peut-être ai-je une autorisation qui traîne quelque part... mais c'est vieux, je ne me souviens plus...

J'ai ajouté test.bat en GPO aussi bien au démarrage qu'à l'arrêt
Au passage note bien que dans GPO je suis au niveau Configuration ordinateur et non au niveau Configuration utilisateur !

J'ai bien mes passages Arrêt/Redémarrage dans test.log :

passage dans script à
16:08
passage dans script à
16:09

Sur ma page d'accueil, j'ai des raccourcis qui ont besoin d'une autorisation Système,
En tant qu'administrateur je n'ai pas de pb pour cocher cette option (Ex : devcon USB)...

Je pense qu'il faut régler ce problème de droit avant tout.
Il n'est pas normal que ta case soit grisée !

[Heffgé]

Ne m'en veux pas si je ne répond pas immédiatement, je suis actuellement sur des travaux plus manuels. Dans une maison il y a toujours des choses à faire.

Bon, il y a du nouveau. Je viens de refaire un test dans ma machine vituelle avec mon 1er bat de test et ... ça marche. J'avais dû me mélanger les pinceaux lors de mon test précédent. Le problème est donc sur mon Windows.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo passage dans script >> Z:\src.txt

Je pense qu'il faut régler ce problème de droit avant tout. Il n'est pas normal que ta case soit grisée !

C'est une fausse piste car c'est pareil sur une machine virtuelle brute d'installation et aussi sur mon portable avec Win 7 familial. Mes recherches sur la toile semblent confirmer que c'est le cas général. D'autre part cette option ne concerne que les fichiers bat, elle n'existe pas pour un fichier vbs, et mon but est de lancer un script vbs via une GPO locale sous W7 comme je le faisais sous XP. Tous les fichiers bat que je suis amené à lancer pour une raison ou pour une autre s'exécutent sans que j'ai à les autoriser préalablement ou lancement.

Sur cette page on lit :

Startup scripts are run under the Local System account, and they have the full rights that are associated with being able to run under the Local System account.

Pour autant que je comprenne on dispose de tous les privilèges pour faire ce que l'on veut dans les scripts mais encore faut-il qu'ils soient lancés. Hors c'est bien le problème, tout se passe comme s'ils ne se lancaient pas, qu'il s'agisse d'un bat ou d'un vbs.

Dans mon précédent message je disais que j'avais rencontré un problème analogue sur le PC d'un ami. Autant je ne parierais pas sur mon OS, autant le sien n'a pas dû être bidouillé, mais le point commun est Avast alors que ma machine virtuelle n'a pas d'antivirus. Je vais donc faire un test sans ce logiciel et je te tiens un courant.

[dmganges]

Ne m'en veux pas si je ne répond pas immédiatement, je suis actuellement sur des travaux plus manuels. Dans une maison il y a toujours des choses à faire.

Pas de problème ! Sur un forum l'avantage c'est qu'on intervient quand on veut et quand on peut Moi c'est souvent le matin à la fraîche

Il est possible que ma suggestion sur les droits de ton .bat ne soit pas la bonne piste concernant ton problème.
Mais ne pas pouvoir accorder un droit administrateur lorsqu'on est administrateur ne me semble pas cohérent.

J'attends ton essai sans Avast !

Mais au tout début tu as précisé :

Dans l'observateur d'événements, au niveau Windows\GPO, je constate qu'une erreur est survenue : code 5, accès refusé.

A mon sens, mais je ne suis pas un expert Windows, si Avast était en cause, il aurait bloqué le script qu'il considère comme suspect, avant qu'il n'atteigne la couche système et fasse de possibles dégâts...
Là l'erreur code 5, accès refusé, semble indiquer que le script a traversé Avast sans encombre.

Pour info j'utilise Microsoft Security Essentials

[Heffgé]

Pour info j'utilise Microsoft Security Essentials

L'antivirus natif de Microsoft pour Windows 10 semble ne rien avoir à envier aux outils tierce partie mais j'ai cru comprendre que, bizarement, la version n'était pas la même pour Windows 7 et que cette dernière n'offrait pas une protection suffisante. Je suis loin d'être un paranoïaque en matière de sécurité mais j'ai préféré garder Avast.

Mais hélas, toujours le même problème après avoir désactivé tous les agents. Je n'ai pas été jusqu'à la désinstallation mais tu as raison, Avast bloquerait sans doute avant que le problème se manisfeste.

J'ai passé pas mal de temps à parcourir la toile à la recherche de cas présentant une similitude avec le mien mais sans succès. La quasi totalité des fils traitant de problèmes de GPO se rapportent à des cas où les machines appartiennent à un domaine géré par un Windows Server. J'ai aussi fait pas mal de tests dont le dernier est le lancemet au démarrage d'un script vbs on ne peut plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

msgbox "script"

Bien sûr la boîte de dialogue ne s'affiche pas mais sur la machine virtuelle on retrouve la trace de l'exécution, aussi bien dans l'observateur d'événements qu'en exécutant gpresult, alors que sur mon Windows j'ai toujours la même erreur.

J'ai vérifié que "System" avait bien plein accès à toute l'arborescence dans le chemin qui mène au script et je ne comprend toujours pas à quoi correspond cet accès qui est refusé. Le plus troublant est que tout baigne avec les scripts au niveau utilisateur.

Ci dessous le détail de l'événement en format xml mais je ne sais pas interprêter ces données.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-GroupPolicy" Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" />
<EventID>7016</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>2</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2022-09-05T09:10:15.527844800Z" />
<EventRecordID>188740</EventRecordID>
<Correlation ActivityID="{BDDA2D2E-64D9-4BAD-8480-254781C59BC2}" />
<Execution ProcessID="1128" ThreadID="2452" />
<Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
<Computer>Poste-7</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">15</Data>
<Data Name="ErrorCode">5</Data>
<Data Name="CSEExtensionName">Scripts</Data>
<Data Name="CSEExtensionId">{42B5FAAE-6536-11D2-AE5A-0000F87571E3}</Data>
</EventData>
</Event>

Je vais continuer de chercher, notamment quelles différences il peut y avoir avec la machine virtuelle.

[dmganges]

Je suis loin d'être un paranoïaque en matière de sécurité mais j'ai préféré garder Avast.

Perso j'en suis un paranoïaque de la sécurité, Microsoft Security Essentials c'est pour moi le minimum.
Je gère essentiellement à partir de plusieurs sauvegardes physiques que je fais depuis Linux avec GParted.
Au moindre doute, ou après des manips crapuleuses, je restaure...

Bon là je sèche

<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">15</Data>
<Data Name="ErrorCode">5</Data>
<Data Name="CSEExtensionName">Scripts</Data>
<Data Name="CSEExtensionId">{42B5FAAE-6536-11D2-AE5A-0000F87571E3}</Data>
</EventData>
</Event>

Security UserID="S-1-5-18" c'est bien un jeton système, Le 18 correspond en général au premier administrateur créé sur le système

A tout hasard on peut faire un petit contrôle du registre à partir de la chaîne : <Data Name="CSEExtensionId">{42B5FAAE-6536-11D2-AE5A-0000F87571E3}</Data>

Dans Regedit tu recherches la chaîne 42B5FAAE-6536-11D2-AE5A-0000F87571E3
J'ai la même chez moi. On peut en conclure quelle provient de l'installation initiale de Windows7.
Vérifie que tu as les mêmes informations que sur l'image ci-dessous, notamment GPOLink.

C'est vraiment du tâtonnement !

Je vais continuer de chercher, notamment quelles différences il peut y avoir avec la machine virtuelle.

La différence c'est que la machine virtuelle s'installe à partir d'une ISO de Windows, donc de quelque chose de propre...

Autrement dit, je penche pour quelque chose de cassé sur ton Windows7.
Mais plus haut tu as précisé que tu as la même anomalie chez un ami...
Donc c'est vraiment sous toute réserve !

[EDIT 03:10] La chaîne 42B5FAAE-6536-11D2-AE5A-0000F87571E3 correspond à une autre clé, j'ajoute l'image en dessous.
NB : la clé 42B5FAAE-6536-11D2-AE5A-0000F87571E3 se retrouve autant de fois qu'il y a d'utilisateurs sur la machine, mais à chaque fois ce sont les deux mêmes images.

PS : As-tu essayé de pousser ton script dans c:\Windows\System32 OU C:\Windows\SysWOW64 juste pour voir comment il se comporte ?


[EDIT 05:10]
A y être vérifie dans le registre que tu as bien dans :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQMClient\Windows\Users

S-1-5-18
S-1-5-19
S-1-5-20

Info piquée ICI (Troisième image).

[EDIT 05:38]
Tu pourrais également essayer de mettre ton script non pas en GPO, mais dans le Planificateur de tâches. (Quatrième image)
En validant l'Historique
Toujours juste pour voir... s'il y a un problème de droit ou autre
Le rapport dans l'historique sera peut-être plus explicite... ?!

[Heffgé]

Je reprend le fil après avoir fait quelques tests et tenté de suivre tes suggestions.

Je penche pour quelque chose de cassé sur ton Windows7.
Mais plus haut tu as précisé que tu as la même anomalie chez un ami...

Je n'en mettrais pas ma tête à couper. Il faudrait que je puisse refaire des tests calmement mais présentement le PC en question est à 2000 km d'ici ! Il va falloir que j'attende un mois ou deux. Il doit revenir sur mon établi pour un changement de pile.

As-tu essayé de pousser ton script dans c:\Windows\System32 OU C:\Windows\SysWOW64 juste pour voir comment il se comporte ?

J'ai déjà fait ce test. Je ne sais plus où je l'avais casé mais le résultat était identique.

Il me semble que tu m'avais parlé de SFC. Il m'a trouvé des tas de trucs qu'il ne pouvait corriger mais tous concernaient l'installation de Windows Mail (j'ai installé ce courrielleur sans doute de manière peu orthodoxe à l'aide d'un guide trouvé sur la toile). Donc a priori auun rapport avec mon problème si ce n'est une bizarie : accès au fichier journal refusé en mode graphique ! Par contre aucun problème depuis la console en lançant notepad avec le nom du fichier en paramètre. Pas de problème non plus en copiant le fichier dans un autre répertoire.

Il y a vraiment quelque chose de pas net avec l'UAC. Je ne l'ai pas encore fait mais il va falloir que je teste en le désactivant. J'ai toutefois du mal à croire que ça ait quelque effet puisque, encore une fois, aucune session n'est encore ouverte au moment de la tentative d'exécution des scripts de démarrage.

Cette histoire d'Avast me turlupinait quand même. Je l'ai installé sur ma machine virtuelle sans que cela empêche les scripts, batch ou vbs, de s'exécuter. Tu avais raison mais là j'ai eu la démonstration qu'Avast n'y était pour rien.

Dans Regedit tu recherches la chaîne 42B5FAAE-6536-11D2-AE5A-0000F87571E3

Elle est présente dans 6 clés mais ce n'est pas celle-ci qui figure dans HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History. Celle présente est {35378EAC-683F-11D2-A89A-00C04FBBCFA2} et aucun paramètre n'y figure.

vérifie dans le registre que tu as bien dans :

Que dalle !

Tu pourrais également essayer de mettre ton script non pas en GPO, mais dans le Planificateur de tâches.

Aucun problème en tâche planifiée mais l'utilisation de GPO a ses raisons, bonnes ou mauvaises. Le script que je souhaite exécuter (voir copie plus bas) vide le répertoire C:\Windows\Temp. La logique voudrait que cela se fasse à l'arrêt du PC mais, à ma connaissance, ce n'est pas possible via le planificateur de tâches. D'autre part ce script, plus un autre pour les fichiers temporaires utilisateurs éxécuté à la fermeture de session, ont été élaborés sous XP qui nativement ne faisait aucun usage des tâches planifiées. En passant par GPO je pouvais donc désactiver ce service inutile. Et puis ça me paraissait plus élégant sans compter la nostalgie des "exits" sur les outils grand système.

J'ai voulu garder la même logique sous Windows 7 sachant toutefois qu'il n'était plus possible de désactiver le service des tâches planifiées dont Windows se sert abondamment. Là depuis le début teste les scripts au démarrage mais c'est uniquement pas comodité. Le problème que je rencontre est strictement identique avec un script à l'arrêt.

Comme annoncé voici le script en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
'---------------------------------------------------------------------------------------
'                            VIDAGE DOSSIER TEMP DE WINDOWS
'
' 		   Auteur : Heffgé           Date : février 2019
'
' Les suppressions sont effectuées par deux fonctions dédiées, l'une aux sous-dossiers,
' l'autre aux fichiers. Elles sont appelées l'une apès l'autre.
'
'---------------------------------------------------------------------------------------
 
' Déclaration et intialisation variables
'---------------------------------------
Dim MonSysFic, MonProcess, MonShell, MonEnv, MonFic
Dim tmp, nf, nd, force, chemin, col, dossier, fichier, dest
force = True
nf = 0
nd = 0

' Instanciation objets
'---------------------
Set MonSysFic = WScript.CreateObject("Scripting.FileSystemObject")
Set MonShell = WScript.CreateObject("WScript.Shell")
Set MonEnv = MonShell.Environment("PROCESS")

' Supression contenu temp windows
'--------------------------------
tmp = MonEnv("windir") & "\Temp"
nf = nf + Sup_fichiers(tmp)
nd = nd + Sup_dossiers(tmp)

' Coup de balai
'--------------
Set col = Nothing
Set dossier = Nothing
Set fichier = Nothing 
Set MonSysFic = Nothing
Set MonShell = Nothing
Set MonEnv = Nothing

' Fonction suppression de dossiers (retourne nb de dossiers supprimés)
'---------------------------------------------------------------------
Function Sup_dossiers(chemin)
    Set col = MonSysFic.getfolder(chemin).Subfolders
    For Each dossier In col
	    On Error Resume Next
        dossier.Delete(force)
        If Err.Number = 0 Then Sup_dossiers = Sup_dossiers + 1
	Next
End Function

' Fonction suppression de fichiers (retourne nb de fichiers supprimés)
'---------------------------------------------------------------------
Function Sup_fichiers(chemin)
	Set col = MonSysFic.getfolder(chemin).Files
    For Each fichier In col
		On Error Resume Next
		fichier.Delete(force)
		If Err.Number = 0 Then Sup_fichiers = Sup_fichiers + 1
     Next
End Function

[dmganges]

Que dalle !

Ce n'est pas normal !
As-tu, ou peux-tu exploiter l'ajout de clé dans le registre comme préconisé par Microsoft image ci-dessous
Autrement dit quelles sont tes possibilités de restauration... si ça n'est pas efficient...
Mais s'il y a de la casse ça risque de ne pas suffire !

Dans la mesure où sa fonctionne en machine virtuelle et non en installation classique je penche toujours plus pour un Windows7 cassé.
Plutôt que d'y aller à tâtons pendant des plombes, et si la fonctionnalité GPO que tu veux mettre en place est importante pour toi...
As-tu la possibilité :
1) Soit de réinstaller W7 en lieu et place, auquel cas il te faut avoir la possibilité de revenir en arrière, d'où ma question sur ta procédure de sauvegarde. [Perso je préfère les save/restaure physiques que les usines à gaz Windows...]
2) Mieux si tu as du DD en réserve, le mettre à la place du DD actuel pour y fait une installation de W7.
C'est bourrin, un peu long car il faut se peler toutes les MàJ... mais pas compliqué... et au moins on serait fixé !

Toujours juste pour voir dans un premier temps.
Après tu aviserais de l’opportunité...

[Edit 05:10]
Perso en GPO à l'arrêt j'efface les messages de l'observateur d’événements, ce qui nécessite les droits administrateur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
WEVTUTIL EL > .\LOGLIST.TXT
for /f %%a in ( .\LOGLIST.TXT ) do WEVTUTIL CL "%%a"
del .\LOGLIST.TXT
rem timeout 5

J'ai passé ton vbs dans en GPO, il nettoie parfaitement mon C:\Windows\Temp

[Heffgé]

quelles sont tes possibilités de restauration.

Je fais de temps en temps, euphémisme pour dire "pas souvent", une image système avec Aomei Backupper, sachant que l'intégralité de mes données personnelles est sur d'autres partitions.

As-tu, ou peux-tu exploiter l'ajout de clé dans le registre comme préconisé par Microsoft image ci-dessous

J'ai vérifié, j'ai bien ces 3 clés avec exactement les mêmes paramètres que ceux du fichiers reg. Donc ça me semble inutile de le lancer.

C'est bourrin, un peu long car il faut se peler toutes les MàJ

J'ai un ISO qui intègre toutes les MàJ post SP1 mais même si ça raccourcit le temps à y passer ça reste laborieux. Je vais y penser.

Ceci dit je suis quasiment sûr que mon Windows est bancal mais ça me gonfle de devoir faire une réinstall à partir de zéro qui m'obligerait à remettre en place tous mes outils. Je n'ai jamais testé la réinstallation "par dessus".

J'ai passé ton vbs dans en GPO, il nettoie parfaitement mon C:\Windows\Temp

On devrait pouvoir faire pareil et de manière plus simple avec un bat mais je n'ai jamais rien écrit avec ce 'FOR" dont la syntaxe me déconcerte.

si la fonctionnalité GPO que tu veux mettre en place est importante pour toi

Je peux m'en passer et ce n'est finalement qu'une question de satisfaction intellectuelle mais comme ceci est publié sur mon site j'aimerais autant être certain que ça marche à tous les coups.

Question subsidiaire. J'ai dû louper quelque chose dans le maniement des outils de ce forum car les images inclues dans les messages n'apparaissent plus quand je passe en mode réponse. Je suis obligé d'avoir un autre onglet en mode lecture pour les voir.

[dmganges]

Je fais de temps en temps, euphémisme pour dire "pas souvent", une image système avec Aomei Backupper

Je ne connais pas Aomei Backupper.
Si tu le maîtrises, autrement dit si tu as déjà restauré avec, on pourrait tenter une manip très scabreuse juste pour voir :
1) Faire une save du W7 PC actuel.
2) Si le W7 virtuel n'a pas été trop modifié, faire un export de la totalité du registre du W7 machine virtuelle.
3) Injecter le .reg obtenu dans le registre du W7 PC.
. Les clés identiques n'étant pas dupliquées.
- Aller au résultat.
- Si la GPO fonctionne, ça pourrait confirmer, mais pas l'infirmer absolument, que le W7 PC est bancal.
Après à toi de voir, sans perdre de vue que continuer sur un tel PC bancal n'est guère satisfaisant...
4) Éventuellement passer la sauvegarde précédente pour revenir à l'état initial. Mais obligatoirement si tu continues sans GPO sur ce PC.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

J'ai vérifié, j'ai bien ces 3 clés avec exactement les mêmes paramètres que ceux du fichiers reg. Donc ça me semble inutile de le lancer.

Effectivement !
J'avais interprété ton "Que dalle" par l'absence de S-1-5-18, S-1-5-19 & S-1-5-20

Ceci dit je suis quasiment sûr que mon Windows est bancal mais ça me gonfle de devoir faire une réinstall à partir de zéro qui m'obligerait à remettre en place tous mes outils.

Je comprends !
Mais si tu es quasiment sûr, encore une fois, plutôt que de douter du système à la moindre occasion... il vaut autant le reconstruire au plus tôt.
Ou alors, tu retestes sur le PC qui est à 2000 Km, et toi tu fais sans GPO.

Je n'ai jamais testé la réinstallation "par dessus"

Moi non plus !
Mais il me semble qu'à l'installation il propose une option "Réparer le système", l'as-tu vu ? essayé ?

je n'ai jamais rien écrit avec ce 'FOR" dont la syntaxe me déconcerte

Moi aussi !
Je n'ai jamais pu m'habituer aux scripts Windows, que ça soit .bat ou .vbs
Le peu dont j'ai eu besoin pour aller vite et ne pas faire d'usine à gaz en Perl ou en C++, je l'ai pompé sur le net

Je peux m'en passer

Chez moi je te confirme qu'il passe, mais j'ai peut-être de supers autorisations dont je ne me rappelle plus d'où elles viennent...
Si tu le valides encore une fois sur un autre PC, c'est bon.

Je suis allé voir ton site, plein de bonnes choses
Mais attention aux caractères accentués.
Je te conseille de passer en UTF8 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<head>
  <meta charset="UTF-8" />
  ...
  ...
</head>

Et de sauvegarder ton code HTML également en UTF8 (Voir images)

Question subsidiaire. J'ai dû louper quelque chose

Alors moi aussi, c'est pareil

[Heffgé]

Je pense avoir trouvé le coupable. A priori c'est Zone Alarm. Vas-t-en savoir pourquoi.

J'ai viré Avast de ma machine virtuelle, pas la peine de traîner ce boulet, et j'ai installé Zone Alarm, juste le pare-feu. Et là même problème que sur ma propre machine : script non exécuté, erreur 5, accès refusé.

Il va falloir que je refasse le test pour confirmer ce diagnostic mais ça ressemble quand même beaucoup à la bonne piste. Si c'est bien le problème j'essaierai de les contacter.

PS : ben non. Pourtant je n'ai pas rêvé mais impossible de reproduire le problème, avec ou sans Zone Alarme sur la machine virtuelle. Ça aurait été trop beau.

[dmganges]

Dommage, c'était une bonne piste !
J'imagine que tu n'as plus d’outils de surveillance tiers...
Comme je n'en utilise pas, je suis passé à côté de cette possibilité.
Là pour le moment je suis à sec d'idée
Si j'ai une lumière, je reviens

[Heffgé]

J'imagine que tu n'as plus d’outils de surveillance tiers..

Je n'ai effectivement qu'Avast et Zone Alarm. Dailleurs ce sont les deux seuls logiciels en démarrage automatique.

c'était une bonne piste !

Tellement bonne que j'ai voulu quand même en avoir le cœur net.

Cette fois-ci j'ai travaillé directment sur mon Windows. J'ai désinstallé ZA et testé : aucun proplème d'exécution de scripts au démarrage. J'ai fait plusieurs redémarrage pour être sûr que je n'avais pas la berlue, tous concluants.

J'ai ensuite réinstallé la même version de ZA que celle mise sur ma machine virtuelle, 32 bits et a priori plus ancienne que celle désinstallée. Et miracle, maintenant les scripts s'exécutent ! Là aussi j'ai recommencé plusieurs fois pour être sûr de moi.

C'était donc bien Zone Alarm qui empêchait que les scripts s'exécutent, peut-être à cause d'un mauvais paramétrage. Mais je ne saurais jamais comment ça pouvait agir.

En tout cas je te remercie vivement pour ton suivi. Même si c'est moi qui ait fini par flairer l'embrouille, je me suis senti moins seul devant ce problème et tes conseils m'ont poussé à persévérer.

Heffgé..

[dmganges]

SUPER
Merci pour le retour
J'ai supprimé les images inutiles...