Y a t'il l'=E9quivalent des cl=E9s run runonce ..... =E0 l'arr=EAt=20
de windows (faire executer un programme au moment ou l'on=20
fait un shutdown, avant, de windows)
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
Eric Giffard
jerome wrote:
Bonjour, Y a t'il l'équivalent des clés run runonce ..... à l'arrêt de windows (faire executer un programme au moment ou l'on fait un shutdown, avant, de windows) merci Jérôme
Bonjour Si tu es en domaine, ça se passe dans les stratégies du domaine. Sinon, tu as des softs comme Lastchance (gratuit) qui le font (http://www.fileware.com/products.htm#LastChance)
A bientôt Enlever les ~ pour une réponse
Eric Giffard MCSE Windows 2000 MCT Windows 2000 eric.giffard@~ifrance.com (perso) eric.g@~nextmedia.fr (boulot) http://www.nextmedia.fr
jerome wrote:
Bonjour,
Y a t'il l'équivalent des clés run runonce ..... à l'arrêt
de windows (faire executer un programme au moment ou l'on
fait un shutdown, avant, de windows)
merci
Jérôme
Bonjour
Si tu es en domaine, ça se passe dans les stratégies du domaine.
Sinon, tu as des softs comme Lastchance (gratuit) qui le font
(http://www.fileware.com/products.htm#LastChance)
A bientôt
Enlever les ~ pour une réponse
Eric Giffard
MCSE Windows 2000
MCT Windows 2000
eric.giffard@~ifrance.com (perso)
eric.g@~nextmedia.fr (boulot)
http://www.nextmedia.fr
Bonjour, Y a t'il l'équivalent des clés run runonce ..... à l'arrêt de windows (faire executer un programme au moment ou l'on fait un shutdown, avant, de windows) merci Jérôme
Bonjour Si tu es en domaine, ça se passe dans les stratégies du domaine. Sinon, tu as des softs comme Lastchance (gratuit) qui le font (http://www.fileware.com/products.htm#LastChance)
A bientôt Enlever les ~ pour une réponse
Eric Giffard MCSE Windows 2000 MCT Windows 2000 eric.giffard@~ifrance.com (perso) eric.g@~nextmedia.fr (boulot) http://www.nextmedia.fr
Jean-Claude BELLAMY
Dans le message news:0afa01c4a62f$34c07b80$ , jerome s'est ainsi exprimé:
Bonjour,
Y a t'il l'équivalent des clés run runonce ..... à l'arrêt de windows (faire executer un programme au moment ou l'on fait un shutdown, avant, de windows)
Oui... Cela peut se paramétrer simplement à l'aide de GPEDIT (stratégies locales)
Lancer GPEDIT.MSC Sélectionner :
"Configuration ordinateur" (scripts de démarrage/arrêt) ou
"Configuration utilisateur" (scripts d'ouverture/fermeture de session)
puis : Paramètres Windows Scripts Cliquer sur (suivant le cas) : "démarrage/arrêter" ou "ouverture/déconnexion" et indiquer le chemin des scripts (ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR. Il n'y a que l'interface qui change (mais c'est un peu plus complexe que GPEDIT!)
<Mode Bidouilleur accro BDR ON>
Script à la fermeture de session : -------------------------------- Clefs concernées :
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff On y trouve 5 entrées de type REG_SZ: "DisplayName" valeur "Stratégie de groupe locale" "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicyUser" (chemin à adapter à sa config) "GPO-ID" valeur "LocalGPO" "GPOName" valeur "Stratégie de groupe locale" "SOM-ID" valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à exécuter (car il peut y en avoir plusieurs, à la différence du script de login dans le cas d'un domaine) Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant à 0 P.ex. HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff b HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff f HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff 11 ... Chaque sous-clef contient 3 entrées : "ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT affiche de travers sur 16 octets ! J'ai remonté le bug à MS) valeur : 00 00 00 00 00 00 00 00 "Parameters" de type REG_SZ valeur : des paramètres éventuels transmis au script "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyUserScriptsLogoff
De plus, il doit exister un fichier "script.ini" placé dans %systemroot%System32GroupPolicyUserScripts Ce script a la structure suivante : [Logoff] 0CmdLine=test.cmd 0Parameters 1CmdLine=machin.exe 1Parameters 2CmdLine=c:vbstruc.vbs 2Parameters ...
Pour chaque script on a 2 lignes : "Ncmdline=xxxx" qui donne le nom du script "NParameters=yyyyy" qui donne les paramètres éventuels N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à l'ouverture de session. Dans ce cas, la section commence par "[Logon]"
Script à la fermeture de Windows : -------------------------------- On a la même structure que pour la fermetute de session, mais le nom des clefs est un peu différent
Clefs concernées :
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown On y trouve les 5 mêmes entrées de type REG_SZ Seule change les entrées : "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicymachine" (chemin à adapter à sa config) "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyMachineScriptsShutdown
Il y a là aussi autant de sous-clefs qu'il y a de scripts ou programmes à exécuter HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown ... Les entrées de chaque sous-clef sont les mêmes que pour la fermeture de session
De plus, il doit exister là aussi un fichier "script.ini" placé dans %systemroot%System32GroupPolicyMachineScripts Ce script a la structure suivante : [Shutdown] 0CmdLine=test.cmd 0Parameters ... Ce fichier script.ini sert aussi pour les scripts au démarrage de Windows. Dans ce cas, la section commence par "[Startup]"
NB: je me suis interrogé sur la raison de la présence de ces fichiers "script.ini", qui font apparement double-emploi avec les données de la BDR. Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC, seul le compte en cours voit sa BDR modifée immédiatement. Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL qui va provoquer ces modifs lors de chaque ouverture de session. Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les suivants. C'est donc le système qui va à ce moment là compléter éventuellement avec le contenu de "script.ini"... Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de tout cela. C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas) qu'il faudra en tenir compte.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Dans le message news:0afa01c4a62f$34c07b80$a401280a@phx.gbl ,
jerome <anonymous@discussions.microsoft.com> s'est ainsi exprimé:
Bonjour,
Y a t'il l'équivalent des clés run runonce ..... à l'arrêt
de windows (faire executer un programme au moment ou l'on
fait un shutdown, avant, de windows)
Oui...
Cela peut se paramétrer simplement à l'aide de GPEDIT (stratégies locales)
Lancer GPEDIT.MSC
Sélectionner :
"Configuration ordinateur"
(scripts de démarrage/arrêt)
ou
"Configuration utilisateur"
(scripts d'ouverture/fermeture de session)
puis :
Paramètres Windows
Scripts
Cliquer sur (suivant le cas) :
"démarrage/arrêter"
ou
"ouverture/déconnexion"
et indiquer le chemin des scripts
(ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR.
Il n'y a que l'interface qui change (mais c'est un peu plus complexe que
GPEDIT!)
<Mode Bidouilleur accro BDR ON>
Script à la fermeture de session :
--------------------------------
Clefs concernées :
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff
On y trouve 5 entrées de type REG_SZ:
"DisplayName"
valeur "Stratégie de groupe locale"
"FileSysPath"
valeur "C:WINDOWSSystem32GroupPolicyUser"
(chemin à adapter à sa config)
"GPO-ID"
valeur "LocalGPO"
"GPOName"
valeur "Stratégie de groupe locale"
"SOM-ID"
valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à
exécuter
(car il peut y en avoir plusieurs, à la différence du script de login dans
le cas d'un domaine)
Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant
à 0
P.ex.
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff b
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff f
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff 11
...
Chaque sous-clef contient 3 entrées :
"ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT
affiche de travers sur 16 octets ! J'ai remonté le bug à MS)
valeur : 00 00 00 00 00 00 00 00
"Parameters" de type REG_SZ
valeur : des paramètres éventuels transmis au script
"Script" de type REG_SZ
valeur : le nom du script. Son chemin complet est à indiquer s'il n'est
pas dans
%systemroot%System32GroupPolicyUserScriptsLogoff
De plus, il doit exister un fichier "script.ini" placé dans
%systemroot%System32GroupPolicyUserScripts
Ce script a la structure suivante :
[Logoff]
0CmdLine=test.cmd
0Parameters 1CmdLine=machin.exe
1Parameters 2CmdLine=c:vbstruc.vbs
2Parameters ...
Pour chaque script on a 2 lignes :
"Ncmdline=xxxx" qui donne le nom du script
"NParameters=yyyyy" qui donne les paramètres éventuels
N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à l'ouverture de
session.
Dans ce cas, la section commence par "[Logon]"
Script à la fermeture de Windows :
--------------------------------
On a la même structure que pour la fermetute de session, mais le nom des
clefs est un peu différent
Clefs concernées :
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown
On y trouve les 5 mêmes entrées de type REG_SZ
Seule change les entrées :
"FileSysPath"
valeur "C:WINDOWSSystem32GroupPolicymachine"
(chemin à adapter à sa config)
"Script" de type REG_SZ
valeur : le nom du script. Son chemin complet est à indiquer
s'il n'est pas dans
%systemroot%System32GroupPolicyMachineScriptsShutdown
Il y a là aussi autant de sous-clefs qu'il y a de scripts ou programmes à
exécuter
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown
...
Les entrées de chaque sous-clef sont les mêmes que pour la fermeture de
session
De plus, il doit exister là aussi un fichier "script.ini" placé dans
%systemroot%System32GroupPolicyMachineScripts
Ce script a la structure suivante :
[Shutdown]
0CmdLine=test.cmd
0Parameters ...
Ce fichier script.ini sert aussi pour les scripts au démarrage de Windows.
Dans ce cas, la section commence par "[Startup]"
NB: je me suis interrogé sur la raison de la présence de ces fichiers
"script.ini", qui font apparement double-emploi avec les données de la BDR.
Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC,
seul le compte en cours voit sa BDR modifée immédiatement.
Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL
qui va provoquer ces modifs lors de chaque ouverture de session.
Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL
qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les
suivants.
C'est donc le système qui va à ce moment là compléter éventuellement avec le
contenu de "script.ini"...
Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de
tout cela.
C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas)
qu'il faudra en tenir compte.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news:0afa01c4a62f$34c07b80$ , jerome s'est ainsi exprimé:
Bonjour,
Y a t'il l'équivalent des clés run runonce ..... à l'arrêt de windows (faire executer un programme au moment ou l'on fait un shutdown, avant, de windows)
Oui... Cela peut se paramétrer simplement à l'aide de GPEDIT (stratégies locales)
Lancer GPEDIT.MSC Sélectionner :
"Configuration ordinateur" (scripts de démarrage/arrêt) ou
"Configuration utilisateur" (scripts d'ouverture/fermeture de session)
puis : Paramètres Windows Scripts Cliquer sur (suivant le cas) : "démarrage/arrêter" ou "ouverture/déconnexion" et indiquer le chemin des scripts (ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR. Il n'y a que l'interface qui change (mais c'est un peu plus complexe que GPEDIT!)
<Mode Bidouilleur accro BDR ON>
Script à la fermeture de session : -------------------------------- Clefs concernées :
HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff On y trouve 5 entrées de type REG_SZ: "DisplayName" valeur "Stratégie de groupe locale" "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicyUser" (chemin à adapter à sa config) "GPO-ID" valeur "LocalGPO" "GPOName" valeur "Stratégie de groupe locale" "SOM-ID" valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à exécuter (car il peut y en avoir plusieurs, à la différence du script de login dans le cas d'un domaine) Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant à 0 P.ex. HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff b HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff f HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff 11 ... Chaque sous-clef contient 3 entrées : "ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT affiche de travers sur 16 octets ! J'ai remonté le bug à MS) valeur : 00 00 00 00 00 00 00 00 "Parameters" de type REG_SZ valeur : des paramètres éventuels transmis au script "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyUserScriptsLogoff
De plus, il doit exister un fichier "script.ini" placé dans %systemroot%System32GroupPolicyUserScripts Ce script a la structure suivante : [Logoff] 0CmdLine=test.cmd 0Parameters 1CmdLine=machin.exe 1Parameters 2CmdLine=c:vbstruc.vbs 2Parameters ...
Pour chaque script on a 2 lignes : "Ncmdline=xxxx" qui donne le nom du script "NParameters=yyyyy" qui donne les paramètres éventuels N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à l'ouverture de session. Dans ce cas, la section commence par "[Logon]"
Script à la fermeture de Windows : -------------------------------- On a la même structure que pour la fermetute de session, mais le nom des clefs est un peu différent
Clefs concernées :
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown On y trouve les 5 mêmes entrées de type REG_SZ Seule change les entrées : "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicymachine" (chemin à adapter à sa config) "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyMachineScriptsShutdown
Il y a là aussi autant de sous-clefs qu'il y a de scripts ou programmes à exécuter HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScriptsShutdown ... Les entrées de chaque sous-clef sont les mêmes que pour la fermeture de session
De plus, il doit exister là aussi un fichier "script.ini" placé dans %systemroot%System32GroupPolicyMachineScripts Ce script a la structure suivante : [Shutdown] 0CmdLine=test.cmd 0Parameters ... Ce fichier script.ini sert aussi pour les scripts au démarrage de Windows. Dans ce cas, la section commence par "[Startup]"
NB: je me suis interrogé sur la raison de la présence de ces fichiers "script.ini", qui font apparement double-emploi avec les données de la BDR. Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC, seul le compte en cours voit sa BDR modifée immédiatement. Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL qui va provoquer ces modifs lors de chaque ouverture de session. Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les suivants. C'est donc le système qui va à ce moment là compléter éventuellement avec le contenu de "script.ini"... Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de tout cela. C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas) qu'il faudra en tenir compte.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
