Procedure ouverture session XPhome

"Daniel92" <QuelleGalere@ole6news.fr> a écrit dans le message de
news:OrIpA09$HHA.4324@TK2MSFTNGP02.phx.gbl...

Sur: microsoft.public.fr.windowsxp et microsoft.public.fr.scripting
Redirigé sur: microsoft.public.fr.windowsxp ( je consulterai
également fr.scripting pour ceux qui préférent y rester) .

Bonsoir,

Sous XP home, je cherche à tester à l'Entrée en Session :

(-) la présence ou l'absence de processus ,

(-) le démarrage ou le non-démarrage de services ;

via un fichier de commandes (.cmd ou .bat) .

Je cherche donc des Programmes ou des Scripts (pas trop
gourmants en ressources) prenant comme argument en ligne
de commandes le nom du processus ou du service, et qui
renvoient un code de sortie (exemple 0 ou 1) testable par
le fichier de commandes.

Il suffisait de demander !

Script "TestProcessus.vbs"
------------- couper ici -------------
' ----------------------------------------------------------
' Script de test d'exécution d'un processus
' Syntaxe:
' testprocessus <processus>
' Paramètre :
' <processus> : nom total ou partiel de l'exécutable
' Retour dans ERRORLEVEL :
' 0 : processus non trouvé
' 1 : processus actif
'
' JC BELLAMY 2007
' ----------------------------------------------------------
Set args = Wscript.Arguments
if args.count=0 then wscript.quit
Processus=args(0)
Set
System=GetObject("winmgmts:{impersonationLevel=impersonate}!//.").InstancesOf("Win32_Process")
Running=0
for each Process in System
If not IsNull(Process.ExecutablePath) Then
filename=CStr(Process.ExecutablePath)
If InStr(1,FileName,Processus,vbTextCompare) Then
Running=1
exit for
End If
End If
next
Wscript.quit Running
------------- couper ici -------------

Exemples :
C:VBS>testprocessus.vbs svchost.exe
C:VBS>echo %ERRORLEVEL%
1

C:VBS>testprocessus.vbs svchost2.exe
C:VBS>echo %ERRORLEVEL%
0

C:VBS>testprocessus.vbs c:windowssystem32winlogon.exe
C:VBS>echo %ERRORLEVEL%
1

A toi d'incorporer le VBS dans un batch en testant %ERRORLEVEL%

Existe-t-il également la possibilité d'intercepter, avec des
outils natifs d'XP , la Sortie de Session sous Xp home
pour lancer un fichier de commandes ou un script VBS ?
(j'avais essayé il y a deux ans LastChance mais il ne marche
pas très bien; plantage de Windows XP)

Sous XP PRO, pas de problème, par contre sous XP HOME, c'est un peu
casse-pied !

En effet, sous W2k (PRO et SRV), XP PRO, W2K3, une stratégie locale
(workgroup) ou globale (domaine) permet de lancer une appli (exe, script,
..) en fin de session (ou fermeture) de Windows.

Lancer GPEDIT.MSC (ou DOMPOL.MSC..... si on est dans un domaine)

Sélectionner :
"Configuration utilisateur"
(scripts d'ouverture/fermeture de session)
puis :
Paramètres Windows
Scripts
Cliquer sur "ouverture/déconnexion"
et indiquer le chemin des scripts
(ils peuvent être placés n'importe où)
_________________________________________________________________________

Sous XP HOME, ou pour les masochistes qui aiment bien tripatouiller dans la
BDR, il faut mettre les mains dans le cambouis ...

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 !)
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]
0CmdLinetest.cmd
0Parameters 1CmdLinemachin.exe
1Parameters 2CmdLinec:vbstruc.vbs
2Parameters ...

Pour chaque script on a 2 lignes :
"Ncmdlinexxxx" qui donne le nom du script
"NParametersyyyyy" 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]"

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 modifié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 !!!



--
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

*Jean-Claude BELLAMY* écrit dans
<news:%23sqilfBAIHA.3548@TK2MSFTNGP06.phx.gbl>
|
| *Daniel92* avait demandé dans
| <news:OrIpA09$HHA.4324@TK2MSFTNGP02.phx.gbl>
| >

| > Sur: microsoft.public.fr.windowsxp et microsoft.public.fr.scripting
| > Redirigé sur: microsoft.public.fr.windowsxp ( je consulterai
| > également fr.scripting pour ceux qui préférent y rester) .
| >
| > Bonsoir,
| >
| > Sous XP home, je cherche à tester à l'Entrée en Session :
| >
| > (-) la présence ou l'absence de processus ,
| >
| > (-) le démarrage ou le non-démarrage de services ;
| >
| > via un fichier de commandes (.cmd ou .bat) .
| >
| > Je cherche donc des Programmes ou des Scripts (pas trop
| > gourmants en ressources) prenant comme argument en ligne
| > de commandes le nom du processus ou du service, et qui
| > renvoient un code de sortie (exemple 0 ou 1) testable par
| > le fichier de commandes.


| Il suffisait de demander !
|
| Script "TestProcessus.vbs"
|

[...] reprendre le script dans le message précédent ,
<< Set System=... >> doivent être sur la même
ligne et séparés par un espace .

| Exemples :
| C:VBS>testprocessus.vbs svchost.exe
| C:VBS>echo %ERRORLEVEL%
| 1
|
| C:VBS>testprocessus.vbs svchost2.exe
| C:VBS>echo %ERRORLEVEL%
| 0
|
| C:VBS>testprocessus.vbs c:windowssystem32winlogon.exe
| C:VBS>echo %ERRORLEVEL%
| 1
|
| A toi d'incorporer le VBS dans un batch en testant %ERRORLEVEL%

Pour tester les processus,
c'est tout à fait ce que je cherchais. :-)


Pour les services (démarrage ou le non-démarrage), il y a
en fichier de commandes : sc query state= all
... puis tester ceux qui sont en État: RUNNING ;

mais la commande FOR est trop gourmande en ressource,
est-ce que c'est réalisable en VBS ?


| _________________________________________________________________________
| >
| > Existe-t-il également la possibilité d'intercepter, avec des
| > outils natifs d'XP , la Sortie de Session sous Xp home
| > pour lancer un fichier de commandes ou un script VBS ?
| > (j'avais essayé il y a deux ans LastChance mais il ne marche
| > pas très bien; plantage de Windows XP)
|
| Sous XP PRO, pas de problème, par contre sous XP HOME, c'est un peu
| casse-pied !
|
| En effet, sous W2k (PRO et SRV), XP PRO, W2K3, une stratégie locale
| (workgroup) ou globale (domaine) permet de lancer une appli (exe, script,
| ..) en fin de session (ou fermeture) de Windows.
|
| Lancer GPEDIT.MSC (ou DOMPOL.MSC..... si on est dans un domaine)
|
| Sélectionner :
| "Configuration utilisateur"
| (scripts d'ouverture/fermeture de session)
| puis :
| Paramètres Windows
| Scripts
| Cliquer sur "ouverture/déconnexion"
| et indiquer le chemin des scripts
| (ils peuvent être placés n'importe où)
| _________________________________________________________________________
|
| Sous XP HOME, ou pour les masochistes qui aiment bien tripatouiller dans la
| BDR, il faut mettre les mains dans le cambouis ...
|
| 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 !)
| valeur : 00 00 00 00 00 00 00 00

*) Voir un peu plus bas

| "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
|


... En rêve, seulement en rêve, Jean claude, ou alors
en Songes d'une nuit d'été humide :-)

http://cjoint.com/?jBpjI3AcrM

Création de la clef liée à l'illustration
(illustration malheureusement éphémère)
------------- couper ici -------------
Windows Registry Editor Version 5.00

; creation valeur QWORD Quadruple mot 64bits
[HKEY_CURRENT_USERSoftwareNetparamDCsouscleBvaltry]
@=hex(2):
"valQWORD_"=hex(b):
"ExecTime"=hex(b):00,00,00,00,00,00,00,00

------------- couper ici -------------

Source: (notamment le tableau sur les déterminants
hexadécimaux des types de valeurs du Registre)
DataStronghold - Windows Registry Editor
http://www.datastronghold.com/security-articles/general-computing/windows-registry-editor.html


| De plus, il doit exister un fichier "script.ini" placé dans
| %systemroot%System32GroupPolicyUserScripts
| Ce script a la structure suivante :
| [Logoff]
| 0CmdLinetest.cmd
| 0Parameters 1CmdLinemachin.exe
| 1Parameters 2CmdLinec:vbstruc.vbs
| 2Parameters ...
|
| Pour chaque script on a 2 lignes :
| "Ncmdlinexxxx" qui donne le nom du script
| "NParametersyyyyy" 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]"
|
| 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 modifié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 !!!
|

Pour l'interception du la sortie de Session, ce n'est pas
vraiment simple (sous XPhome) , mais pas irréalisable.
Dès que je suis sorti de mon "service System minimum"
pour cause de restructuration de Partitions, je me mets
sur le chantier.


Merci Jean-Claude,
--
Daniel92.
======