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.
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
Méta-MCI \(MVP\)
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
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.
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]
"Philemil" a écrit dans le message de 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
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Philemil" <Philemil@nospam.fr> a écrit dans le message de
news:%239shtrnGJHA.4560@TK2MSFTNGP02.phx.gbl
| 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
"Philemil" a écrit dans le message de 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
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Méta-MCI \(MVP\)
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
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.
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]
"Méta-MCI (MVP)" a écrit dans le 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
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> a écrit dans le
message de
news:48d4bf3b$0$881$ba4acef3@news.orange.fr
| 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
"Méta-MCI (MVP)" a écrit dans le 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
Gilles LAURENT [MVP] a écrit :
"Philemil" a écrit dans le message de 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
"Philemil" <Philemil@nospam.fr> a écrit dans le message de
news:%239shtrnGJHA.4560@TK2MSFTNGP02.phx.gbl
| 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
"Philemil" a écrit dans le message de 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
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
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.
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.
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
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.
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
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...
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...
... 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...
