évènements clavier en WMI

Le
Philemil
Bonjour à tous

Soit un script VBS lancé en tâche planifié, sous un compte autre que la
session courante.

Je cherche à récupérer les évènements clavier, voir souris , en fait
juste savoir si il y a une activité d'un utilisateur, ce qui me
permettra de suspendre le script en conséquence,

attention, je ne veux pas arrêter la tâche planifiée, çà elles savent le
faire en natif sur une reprise d'activité utilisateur.

Il y a qquechose en WMI peut-être ?

Par avance merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Méta-MCI \(MVP\)
Le #17279391
Bonjour !

Pour tracer l'utilisation du clavier, le mieux est de passer par les API
de windows.
Par exemple, la fonction GetAsyncKeyState de user32.dll

Gilles Laurent a proposé, à plusieurs reprises, un composant qui permet
d'appeler dynamiquement les API de windows. Je pense qu'il pourrait être
bien adapté à ce genre d'utilisation.

@-salutations
--
Michel Claveau
Gilles LAURENT [MVP]
Le #17280001
"Philemil" news:%
| Bonjour à tous

Bonjour,

| Soit un script VBS lancé en tâche planifié, sous un compte autre que
| la session courante.
|
| Je cherche à récupérer les évènements clavier, voir souris , en fait
| juste savoir si il y a une activité d'un utilisateur, ce qui me
| permettra de suspendre le script en conséquence,
|
| attention, je ne veux pas arrêter la tâche planifiée, çà elles savent
| le faire en natif sur une reprise d'activité utilisateur.
|
| Il y a qquechose en WMI peut-être ?

A ma connaissance rien du coté de WMI. En revanche l'utilisation de
l'API Win32 GetLastInputInfo (session-wide) permettra de répondre
précisément à votre besoin. Le composant DynaWrap (version étendue)
devra au préalable être enregistré sur le système. Pour tester le
fonctionnement du script ci-dessous, je vous invite à procéder de la
manière suivante :

1- Enregister le composant DynaWrap (le lien de téléchargement
ci-dessous)
2- Copier le script VBScript DetectInput.vbs dans un dossier quelconque
3- Ouvrir une invite de commandes "en tant que" avec les credentials de
la tâche planifiée
4- Exécuter le script VBScript DetectInput.vbs dans cette console :
> CScript DetectInput.vbs
Note : Ctrl / Pause pour breaker
5- Réaliser des actions clavier / souris dans n'importe qu'elle fenêtre
/ application
6- Vérifier la détection des évènements (delta 1s) dans la console
précédente

--- Coupez ici : DetectInput.vbs ---
Set oDyn=CreateObject("DynamicWrapper")
oDyn.Register "User32.dll", "GetLastInputInfo", "i=l", "r=b"
LastInputInfo=String(8,0)
PLastInputInfo=oDyn.GetBSTRAddr(LastInputInfo)
oDyn.SetMemInBSTRAddr PLastInputInfo, 0, 4, 8
oDyn.GetLastInputInfo PLastInputInfo
dwLastTime=oDyn.GetMemInBSTRAddr(PLastInputInfo, 4, 4)

While True
WScript.Sleep(1000) ' une seconde
oDyn.GetLastInputInfo PLastInputInfo
dwTime=oDyn.GetMemInBSTRAddr(PLastInputInfo, 4, 4)
WScript.Echo "Activity : " & CStr (dwTime <> dwLastTime)
dwLastTime=dwTime
Wend
--- Coupez ici : DetectInput.vbs ---

GetLastInputInfo :
http://msdn.microsoft.com/en-us/library/ms646302(VS.85).aspx

DynaWrap - DynaCall Wrapper :
http://glsft.free.fr/index.php?option=com_content&task=view&idG&Itemid3

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Méta-MCI \(MVP\)
Le #17280411
Salut, Gilles !

Un problème peut apparaître, du fait que GetLastInputInfo travaille
avec la session courante (celle qui lance le script), alors que le
demandeur parle d'une autre session (sa tâche/vbs est sous un autre
compte).

Mais, comme toi, à part les API, je ne vois guère de solution légère. ou
alors, un logiciel qui tourne en tâche de fond, et communique par
inter-sessions. Mais, ça semble lourd.

@-salutations
--
Michel Claveau
Gilles LAURENT [MVP]
Le #17281181
"Méta-MCI (MVP)" message de
news:48d4bf3b$0$881$
| Salut, Gilles !

Salut Michel,

| Un problème peut apparaître, du fait que GetLastInputInfo travaille
| avec la session courante (celle qui lance le script), alors que le
| demandeur parle d'une autre session (sa tâche/vbs est sous un autre
| compte).
[...]

Moi aussi j'ai eu un doute au départ ! C'est pour cela que dans le
scénario de test je précise d'ouvrir une invite de commande "en tant
que" avec les credentials de la tâche planifiée. Et il s'avère que cela
ne pose aucun problème, ni via une tâche planifiée qui s'exécute sous
l'autorité d'un autre compte que celui de l'utilisateur courant. La
remarque du MSDN s'applique par exemple à plusieurs sessions TSE sur un
même serveur ou alors au Fast User Switching apparu avec Windows XP.

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Philemil
Le #17282801
Gilles LAURENT [MVP] a écrit :
"Philemil" news:%
| Bonjour à tous

Bonjour,


Bonjour Gilles et Laurent

Excellent, je viens de tester, çà ouvre des perspectives et c'est tout à
fait ce que je voulais, merci beaucoup à Gilles.

Par contre je ne suis pas certain que mon idée soit la bonne.

Voici ce que je cherche à faire:

Un defrag en ligne de commande sous un compte SYSTEM ou admin, lorsque
les machines (XP) sont hors activité, (et non pas sur un créneau horaire
précis)
Donc une tâche planifiée sous un de ces comptes fait l'affaire, à la
limite un simple defrag c:
Mais ... laisser la tâche planifiée tuer tout simplement le defrag sur
reprise d'activité, çà me semble dangereux ?
Defrag accepte "^C" pour l'interrompre proprement, c'est donc ce que je
souhaitais faire, dès qu'il y avait reprise d'activité, si le defrag
n'est pas terminé.

qquechose comme çà , mais j'ai bien l'impression de plus que le sendkeys
ne soit pas opérant.


-------------------------------------------------
Set oSh=CreateObject("WScript.Shell")
Set oCmd=oSh.exec ("cmd /c "defrag.exe c:")

oSh.AppActivate oCmd.ProcessID

'boucle tant que le defrag est en cours
Do While oCmd.Status = 0
'arrêt propre du defrag si activité utilisateur
If "activité_utilisateur" then
osh.sendkeys("^c")
WScript.Sleep (3000)
oCmd.Terminate
Exit do
End if
Loop
-------------------------------------------------





| Soit un script VBS lancé en tâche planifié, sous un compte autre que
| la session courante.
|
| Je cherche à récupérer les évènements clavier, voir souris , en fait
| juste savoir si il y a une activité d'un utilisateur, ce qui me
| permettra de suspendre le script en conséquence,
|
| attention, je ne veux pas arrêter la tâche planifiée, çà elles savent
| le faire en natif sur une reprise d'activité utilisateur.
|
| Il y a qquechose en WMI peut-être ?

A ma connaissance rien du coté de WMI. En revanche l'utilisation de
l'API Win32 GetLastInputInfo (session-wide) permettra de répondre
précisément à votre besoin. Le composant DynaWrap (version étendue)
devra au préalable être enregistré sur le système. Pour tester le
fonctionnement du script ci-dessous, je vous invite à procéder de la
manière suivante :

1- Enregister le composant DynaWrap (le lien de téléchargement
ci-dessous)
2- Copier le script VBScript DetectInput.vbs dans un dossier quelconque
3- Ouvrir une invite de commandes "en tant que" avec les credentials de
la tâche planifiée
4- Exécuter le script VBScript DetectInput.vbs dans cette console :
> CScript DetectInput.vbs
Note : Ctrl / Pause pour breaker
5- Réaliser des actions clavier / souris dans n'importe qu'elle fenêtre
/ application
6- Vérifier la détection des évènements (delta 1s) dans la console
précédente

--- Coupez ici : DetectInput.vbs ---
Set oDyn=CreateObject("DynamicWrapper")
oDyn.Register "User32.dll", "GetLastInputInfo", "i=l", "r=b"
LastInputInfo=String(8,0)
PLastInputInfo=oDyn.GetBSTRAddr(LastInputInfo)
oDyn.SetMemInBSTRAddr PLastInputInfo, 0, 4, 8
oDyn.GetLastInputInfo PLastInputInfo
dwLastTime=oDyn.GetMemInBSTRAddr(PLastInputInfo, 4, 4)

While True
WScript.Sleep(1000) ' une seconde
oDyn.GetLastInputInfo PLastInputInfo
dwTime=oDyn.GetMemInBSTRAddr(PLastInputInfo, 4, 4)
WScript.Echo "Activity : " & CStr (dwTime <> dwLastTime)
dwLastTime=dwTime
Wend
--- Coupez ici : DetectInput.vbs ---

GetLastInputInfo :
http://msdn.microsoft.com/en-us/library/ms646302(VS.85).aspx

DynaWrap - DynaCall Wrapper :
http://glsft.free.fr/index.php?option=com_content&task=view&idG&Itemid3



Méta-MCI \(MVP\)
Le #17283281
Re !

Je répond à côté, mais...

De plus en plus de doutes planent sur l'intérêt des défragmentations ;
surtout trop nombreuses.
Certains administrateurs font état d'un taux de pannes disque plus
important, sur les disques souvent défragmentés.
De plus, les tailles actuelles des disques rendent ces défragmentations
peu utiles. Les mesures faites avec des disques libres à plus de 50 %
ne font apparaître AUCUNE différence de vitesse avant et après
défragmentation.

@-salutations
--
Michel Claveau
Méta-MCI \(MVP\)
Le #17283271
Re !

Merci pour les précisions.

MCI
Philemil
Le #17283931
Méta-MCI (MVP) a écrit :
Re !



Re bonjour
Je répond à côté, mais...


Non ce n'est pas à côté ,de fait déjà les scan antivirus font beaucoup
travailler les DD, si on ajoute beaucoup des defrag à répétition, çà ne
doit pas améliorer leur taux de pannes, mais bon un petit défrag par
quinzaine ou par mois?

De plus en plus de doutes planent sur l'intérêt des défragmentations ;
surtout trop nombreuses.
Certains administrateurs font état d'un taux de pannes disque plus
important, sur les disques souvent défragmentés.
De plus, les tailles actuelles des disques rendent ces défragmentations
peu utiles. Les mesures faites avec des disques libres à plus de 50 % ne
font apparaître AUCUNE différence de vitesse avant et après
défragmentation.


évidemment là autant que j'abandonne l'idée :-)

@-salutations



salutations
Philippe
Th.A.C
Le #17287131
Philemil a écrit :

...
Par contre je ne suis pas certain que mon idée soit la bonne.

Voici ce que je cherche à faire:

Un defrag en ligne de commande sous un compte SYSTEM ou admin, lorsque
les machines (XP) sont hors activité, (et non pas sur un créneau horaire
précis)
Donc une tâche planifiée sous un de ces comptes fait l'affaire, à la
limite un simple defrag c:
Mais ... laisser la tâche planifiée tuer tout simplement le defrag sur
reprise d'activité, çà me semble dangereux ?



Une alternative, lancer le defrag avec une priorité très basse.
Ca a l'avantage de très peu solliciter le disque et le processeur, même
si c'est un peu plus long...
Publicité
Poster une réponse
Anonyme