Latest posts by Kyle Beckman (see all)
- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
Shared computer systems in areas such as reception desks, computer labs, and call centers can be brought to their knees very quickly if users lock the workstation and walk away when their shift ends. The next person sits down, clicks Switch User, logs in, and repeats the process all over. After enough users, there are enough random applications running in the background to slow the system to a crawl. So, how do you log off the idle sessions? Actually, it’s pretty easy with a free utility and a little Group Policy!
Non-recommended solutions ^
Before we get started, I’d like to address two of the ways I’ve seen suggested as a way to handle logging off idle user sessions. One solution that used to be popular is the winexit.scr screensaver included in the Windows NT Server 4.0 Resource Kit. A systems administrator can set the workstation’s screensaver to winexit.scr, and the user would be logged off when the screensaver activated.
This solution doesn’t take into account newer operating systems that include Fast User Switching. It also requires you to lengthen your screensaver activation time so you don’t accidentally log off a user who has gone on a break or lunch period. And, last but not least, getting this old utility to work correctly on newer OSs is just a pain. Do you really want to run something this old on your network if you don’t have to? Another is a Group Policy setting that a lot of people point to as a solution to this problem. The setting is located in Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for disconnected sessions.
“Set time limit for disconnected sessions” policy (for RDS sessions only)
I’ve seen this setting recommended—a LOT—as a solution for logging off idle users. You can use it for logging off idle users on Remote Desktop Services (RDS, formerly Terminal Services). This session doesn’t work for physical computers that people are using at the console.
Computer-side Group Policy settings ^
To set up our solution, we’ll need to create a new Group Policy Object (GPO) in the Group Policy Management Console (GPMC). For multiuser computers, I usually like to create a new sub-Organizational Unit (OU) inside the original OU that contains all the other non-multiuser computers. This lets the multiuser computers get the same Group Policy as all of the other computers without forcing the “idle logoff” on every single computer.
Create new GPO in the Group Policy Management Console
Next, we’ll need to right-click the new GPO and choose Edit. Once you’re in the Group Policy Management Editor, you’ll need to go to Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode. Enable the policy and set it to Merge. This will let us apply a user-side policy to computer objects in Active Directory. (I’ve written articles on loopback processing in Group Policy and common usage scenarios if you’d like more information.)
Configure user Group Policy loopback processing mode to Merge
Next, we’ll need to copy a small utility to the multiuser computers. Go and download idlelogoff.exe.
UPDATE: We removed the link to the website that hosts idlelogoff.exe is because the site is infected with malware. See comments below.
For demo purposes in this article, I’m going to put my copy into Active Directory’s Sysvol folder. For a production environment, you’ll probably want to do this from a file share. Just make sure that domain computers have at least read-only access to both the share and the file system.
IdleLogoff executable in the Sysvol folder
Go back to your GPO and go to Computer Configuration > Preferences > Windows Settings > Files. Right-click Files and choose New > File. In the Source File(s) section, select the IdleLogoff.exe that we put into \\domain.local\sysvol\domain.local\files\IdleLogoff\IdleLogoff.exe. Set the Destination File value to C:\Program Files\IdleLogoff\IdleLogoff.exe.
New File Properties to copy IdleLogoff.exe to computers
User-side Group Policy settings ^
Next, we’ll need to set our user-side Group Policy settings. Go to User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff). Double-click Logon on the right side of the window.
Logon/Logoff scripts in the Group Policy Management Editor
Click the Show Files button to open a new window where you can place the Logon script we’ll use.
Create a new batch file for a Logon script
Create a new text file named IdleLogoff.bat in the folder, with the following text:
"c:\Program Files\IdleLogoff\IdleLogoff.exe" 1800 logoff
The IdleLogoff.exe utility takes two arguments. The first argument is the time, in seconds, before taking action. In this case, I’m using 1800, which translates to 30 minutes. The second argument is the action to take. The valid actions are logoff, lock, restart, and shutdown. We want to log off idle sessions, so I’m using logoff.
Last, we need to add the Logon script to the GPO. Click the Add button on the Logon Properties window, then click the Browse button on the Add a Script window, select the script (IdleLogoff.bat), and click Open. This will take you back to the Add a Script window where you can click OK. The Logon script will show up on the Logon Properties window; click OK.
Adding the Logon script to the Group Policy Object
Testing on the client ^
On a test client, I’m going to run a manual Group Policy update by running gpupdate.exe at a command prompt just to ensure the system gets the settings in the GPO. Next, I’m going to go to C:\Program Files\IdleLogoff\ and make sure that IdleLogoff.exe is copied to the computer.
IdleLogoff.exe copied to a Windows 8.1 client
Next, we can run Task Manager and see that the IdleLogoff.exe executable is running in the background in the user’s session.
IdleLogoff.exe running on Windows 7
IdleLogoff.exe running on Windows 8.1
A word of warning about Windows 8: Windows 8 includes a number of changes to make the system startup and user logon process faster. One of these changes is to delay the running of logon scripts for five minutes, by default, to make the logon process faster for the end user. Keep this in mind when deploying this solution to computers. You can change this setting in Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure Logon Script Delay.
Configure Logon Script Delay policy
You might also ask, “If I can see the process, won’t the user be able to see the process?” The short answer here is, yes. The user will be able to run the Task Manager and see this process running in his/her list of processes and can stop it from running. I’ve found that 99 percent of my users logging into a workstation with this configured never know it is there. You can do things like try to hide the process from Task Manager or even rename the file to something like “explorer.exe.”
The only problem with those solutions is that those are the same things malware can do to a system. And, you probably don’t want to implement a solution that looks a lot like malware, or you run the risk of your antivirus/antimalware kicking in and killing it. You can disable the Task Manager by going to User Configuration > Administrative Templates > System > Ctrl+Alt+Del Options > Remote Task Manager. Set the policy to Enabled and click OK.
Disable the Task Manager with the Remove Task Manager policy
Lastly, communicate this new policy to people who may be impacted by the change. Some reception desk computers may need the idle logoff time set anywhere from 45 to 90 minutes so the primary user isn’t kicked out of his/her session while on a lunch break. Other locations, such as computer labs, may need it set to something lower—maybe 15 to 20 minutes. If you have any thoughts on how long it should take, we’d love to hear them in the comments!