We are going live with out first public VMware View terminals this week (Wyse P25 “zero-clients”… nice units). I had what I expected would be a easy list of “little jobs” to be completed before going live. Famous last words…
One item on the list was implementing an “idle user logout” process. This process would detect when a View session had gone idle, and would disconnect the session automatically (preferably after prompting the user). This disconnected session then would be logged out by View Manager after a fixed amount of time.
This proved rather more difficult than I had predicted. I tried several solutions before arriving at one that worked. Among the failed solutions:
- Using Group Policy to configure Remote Desktop Session Manager idle session limits. The View configuration documents imply that this should work, but it does not. I expect that the policies would be effective if you were connecting to your View desktops using RDP, but PCoIP sessions just will not disconnect automatically (at least, they would not for me).
- Using the Windows Task Scheduler to configure a disconnect script that will trigger on idle. This did not work for two reasons. First, the Task Scheduler only evaluates for idle conditions every 15 minutes. Second, for the Task Scheduler, “idle” means not only that the user is not directing mouse and keyboard to the computer, but that the CPU also is not doing anything. As a result, we could not get consistent auto-logout times.
The solution that we settled on involved the use of a custom screensaver developed by the “Grim Admin”. “ScreenSaver Operations”:
This is a great little utility that accomplishes what the “WinExit” screensaver used to for Win XP. (WinExit cannot easily be used on Win7, and is a bit hostile to 64-bit Windows). Screensaver Operations has a well-written README describing the use of registry entries to control the screensaver globally (i.e. for all users on the computer). I set these registry operations as Group Policy Preferences, and we are in business.
Two slight complications… since the screensaver is 32-bit, you need to use the “sysnative” filesystem redirector if your want the screensaver to trigger 64-bit executables. In our case, I wanted the screensaver to launch “tsdiscon.exe” (to disconnect the View session), so I had to use the path:
Additionally, you will need to specify the full path to the screensaver in the Group Policy dialogs (i.e. %SystemRoot%\SysWOW64\Screensaver Operations.scr). If you fail to do so, the screensaver will appear to be configured in the Control Panel, and you will be able to preview it by clicking the “preview” button, but the screensaver WILL NEVER START.
Ashamedly I will admit that this little challenge too much longer to accomplish than it should have. No wonder lab managers burn out so easily.