I am not sure if this belongs here or some place else but lets get it out there and hope we can get an answer on this.
I am doing group policy for a kiosk machine and have changed the shell from explorer.exe to iexplore.exe -k. Once the machine logs in IE opens and sits there. Works perfect.
Within the same GPO I have a logon script that runs a powershell job to pretty much start a job and loop it so if anyone closes IE it will reopen IE.
I am noticing that the wait-job commandlet is somehow prohibiting the ctrl alt del to work until I either put a timeout at the end of wait-job or remotely kill powershell.exe for ctrl-alt-del to work properly. It is as if the job is somehow prohibiting a fundamental component of windows since NT 4. I am not sure why this happens or if it has anything to do with explorer.exe not running. I will test more around that and post back but does anyone know what is happening
Well… Wait-Job isn’t disabling Ctrl+Alt+Del per se ;). Rather, the Secure Attention Sequence (SAS) in Windows attempts to politely suspend running processes before displaying the Secure Desktop. Basically, Windows just wants to make sure no application is right in the middle of something before all processes are temporarily hung. Most apps just say, “yup, no problem, I’m good” and things proceed as you’re used to. In this scenario, it looks like PowerShell’s saying, “nope, I’m busy, hang on a second” until Wait-Job releases its blocked thread. Because you’re launching this as a logon script, the process gets some special privileges - you’ve just found a wonderful combination of Windows features that results in a fairly unique situation :).
Honestly, though, you’re probably operating outside the boundaries that PowerShell’s creators were thinking of. That is, what you’re doing is a little hack-y :). I’d probably do this in a Scheduled Task, instead - one that runs every minute or so. Check to see if IE is open, and just end if it is. If it isn’t, run it, and then end. That may still cause you some performance grief, because starting up PowerShell.exe each time is non-trivial, of course, but you can test it. I think not using a logon script is probably going to be kinda key.
And, even in your original approach, there’s really no reason at all to use a Job. You’re essentially just spawning a second instance of PowerShell for no reason. It’d be just as easy to have your logon script enter an endless loop right on the main thread. But having this as a logon script is probably still going to be problematic, because the Group Policy client essentially “owns” PowerShell. You see, it’s really the GP client that’s not responding to the SAS, here, because it’s the GP client that wants the darn logon script to finish.
Me… I’d probably code up a little background service in Visual Studio. It can respond to ended-process events, rather than just sitting in a loop (PowerShell isn’t awesome at being event-driven, but VB and C# rock at it), and if the ended process was IE, just re-spawn.
You might also experiment, by the way, with making Iexplore.exe the “shell,” rather than explorer.exe. Windows tries to keep the shell process running and has some logic to auto-re-launch if the process is killed. Googling “internet explorer as shell” turns up a lot of people who’ve been doing what you’re trying, going way, way back in time. Might find some different approaches that way.
I think I will just force a logoff if IE is not running , in other words if the user closes the webpage then logg off. I like some of your other ideas such as creating a service that would restart IE if it was closed , I am just not to well versed in coding. I can enable a GPO that prohibits of closing IE all together even alt - f4 and only allow the user to log off.
As for your second post I am using the custom shell configuration via GPO to set Iexplorer.exe as the shell and same issues persist.
I am still weighing my options here but thanks for the answer on this , it was a strange result that I was not expecting.