Question Message à la fermeture de Windows

Effectivement si on applique cette stratégie (je viens de vérifier) :

Empêche l'utilisateur d'arrêter ou de redémarrer Windows.

Ce paramètre supprime l'option Arrêter du menu Démarrer et désactive le bouton Arrêter le système sur la boîte de dialogue de sécurité Windows (qui apparaît quand vous appuyez sur Ctrl+Alt+Suppr).

Ce paramètre empêche l'utilisateur d'utiliser l'interface utilisateur de Windows pour arrêter le système, mais ne l'empêche pas d'exécuter des programmes qui peuvent arrêter Windows.

Si vous désactivez ce paramètre ou que vous ne le configurez pas, l'option de menu Arrêter apparaît et le bouton Arrêter le système est activé.

Remarque : les applications tierce partie avec une certification Windows 2000 ou ultérieure doivent adhérer à ce paramètre.

On empêche l'accès à l'option redémarrer car c'est une sous option de \"Arrêter l'ordinateur\". Ceci étant, tu pourrais très bien leur créer une icône (sur le bureau ou dans le menu démarrer) pour redemarrer l'ordinateur. D'autre part, comme tes utilisateurs sont admins de leur poste, comme l'indique la stratégie, il peuvent toujours arreter le PC via un programme adhoc. En fait, on fait via la GPO, uniquement un masquage du bouton \"Arreter l'ordinateur\".

En espèrant que ça t'aide...

Arnaud
PS: il n'y a pas pour l'instant la possibilité de faire des messages privés. Mais tu peux m'écrire à Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. ou cliquer tout en haut sur 'nous contacter'.

Salut,
qq remarques après avoir cherché qq heures sur ce sujet.
La fin de session peut être interceptée via les message système WM_QUERYENDSESSION ( msdn2.microsoft.com/en-us/library/aa376890.aspx )
Sous WMI la classe Win32_ComputerShutdownEvent ( msdn2.microsoft.com/en-us/library/aa394101.aspx ) permet d'être averti d'une fin de session (..when a computer begins the process of shutting down..) mais j'ai bien l'impression que sous WMI on sait qu'il y a eu un événement d'un type donné mais on ne pas (plus ?) intervenir dessus.

Par exemple ceci fonctionne mais n'est pas ici d'une grande utilité :
[code:1]$RequeteWQL=\"Select * from Win32_ComputerShutdownEvent within 1\"
$Requeteur= new-object Management.WQLEventQuery($RequeteWQL)

$Surveillant=new-object Management.ManagementEventWatcher $Requeteur
$Resultat=$Surveillant.WaitForNextEvent();$Resultat.Type>c:\temp\result.txt[/code:1]
On peut se tourner vers le framework .NET pour vérifier si cela est possible. En cherchant un peu on tombe sur ceci SystemEvents.SessionEnding ( msdn2.microsoft.com/en-us/library/micros...s.sessionending.aspx ) porté par le gestionnaire d'événement SessionEndedEventHandler ( msdn2.microsoft.com/en-us/library/micros...dedeventhandler.aspx ).

Bon c'est là que ça commence à se corser, PowerShell v1 ne sait pas (simplement) gérer les délégués (un type de données référençant des fonctions). Qu'a cela ne tienne on se dit que ce framework doit bien posséder une méthode pour construire un délégué. Exact ! Il s'agit de Delegate.CreateDelegate ( msdn2.microsoft.com/en-us/library/ms131072.aspx )
Malheureusement l'espoir s'arrête là au vue des difficultés d'implémentation, pour moi, sous PS.
Enfin tout n'est pas perdu car sur le blog de PowerShell, cette demande étant récurrente, les concepteurs proposent un script de haute voltige pour ce faire ( blogs.msdn.com/powershell/archive/2006/07/25/678259.aspx )
Pour info il est basé sur de l'injection de code IL ...

La partie reprend
En cherchant on peut tomber sur ce cmdlet PSEventing ( www.codeplex.com/PSEventing ), en beta mais prometteur.
Effectuons un test sur un délégué :
[code:1]Add-PSSnapin psEventing # Inscription obligatoire aprés l'installation

$fsw = new-object system.io.filesystemwatcher
$fsw.Path = \"c:\temp\"
$fsw.EnableRaisingEvents = $true
Get-EventBinding fsw -IncludeUnboundEvents | Format-Table -Auto[/code:1]Je vous laisse consulter le site pour le détail.

Allons plus loin, en passant sur les pb de droits d'exécution de ce script :
[code:1]cd \"le répertoire du script get-delegate.ps1\" # on fait au plus simple ici
[System.Reflection.Assembly]::LoadWithPartialName(\"microsoft.win32\"«») # on charge l'assembly
#Appel le script de création de délégué avec celui gérant la fin de session
$delegate=.\get-delegate.ps1 microsoft.win32.SessionEndingEventHandler {Echo \"Ok delegate\">c:\temp\result.txt}[/code:1]

Fin du premier round !
A ce point je n'ai pas réussi à intercepter quoi que ce soit. Je pense que c'est dû au faite que PS est un programme console qui lui se base sur un gestionnaire particulier SetConsoleCtrlHandler ( msdn2.microsoft.com/en-us/library/ms686016.aspx ).
J'ai testé les 2 approches dans une application console .NET et seul la dernière a été couronné de succès.
Donc pour implémenter ce dernier point sous PS je ne sais pas si cela est possible et si le jeux en vaut la chandelle.
De plus il resterait un pb, à savoir cacher la fenêtre exécutant cet improbable script.
Il se peut que cela soit possible plus simplement il reste à le découvrir.

Pour résumer je pense que PS est inadapté pour résoudre ton PB en revanche une application de type Service, développé en L4G, peut suffire.
Maintenant il y a peut être une autre approche...

PS:
On peut donc voir que si ce shell à du pouvoir, il n'a pas tous les pouvoirs et ce n'est pas pas un outil pour le développement système.

Ensuite se profile les questions de la maintenance et de la reprise, par un nouvel admin, de ce type de script

Message édité par: BatchMan, à: 7/06/07 20:15<br><br>Message édité par: BatchMan, à: 7/06/07 20:17

Je viens de trouver ce complément d'informations :
msdn.microsoft.com/msdnmag/issues/07/06/.../Default.aspx?loc=fr
Bon c'est plutot destiné aux développeurs .NET mais reste trés intéressant.