Problem solve Get help with specific problems with your technologies, process and projects.

Logging out inactive users

Use these tactics to log off users who have stepped away from their desks or gone home for the day without logging off.


By Dave Kearns

Logging out inactive users

In the past fifteen years that I've been providing volunteer support to network managers on CompuServe, MSN and on Novell's Support Connection, one of the most frequently asked questions is along the lines of: "How can I automatically log off inactive users?"

Some managers want to log off people who have gone home without shutting down so that files are closed before backup starts. Some need to shut down inactive users because they have fewer licenses than users and need to free up connections for people who wish to be active. The third reason is security -- sessions left logged in while the user goes away could be an invitation for unethical, immoral or illegal activity by anyone walking past.

But how do you define "inactivity" and, more importantly, how do you measure it?

If I'm sitting at my desk, looking at an on-screen map and mentally plotting a route -- is that "activity" or not? Simply measuring time from the last keystroke or mouse click won't indicate activity status.

Even provided we could agree on a definition and find some way to measure inactivity in an unequivocal way, what should we do with that user's session? Forcing a shutdown will free files for backup and insure there are no security breeches -- but it won't save open files and it won't necessarily shutdown applications cleanly. Suppose I've spent a couple of hours working on a spreadsheet but needed to verify a figure with someone else. I call a colleague and start talking to her -- we discuss the Super Bowl, maybe -- before asking about the figures I need. Turning back to the screen, I see my spreadsheet is gone, two hours wasted! Will I be after the network manager's head? You bet I will! I could also be using a database system and saving as I go, but if the DB session isn't shutdown properly, the database indexes could be corrupted. How would the accounting department feel about that?

There are some things you can do, but it may not be the entire solution you are looking for, if that even exists (and I don't think it does).

The security issue is addressed the most easily and completely. There are a number of screensaver programs that are linked to your network password. Set a short time factor (say, five minutes) and the screensaver kicks in. Only by entering the correct password for the user who "owns" that session or -- for the past such solutions -- the administrative password can the screensaver be ended and the session resumed.

For users who leave for the day and forget to log out, it is possible with some network and desktop operating systems (such as NetWare) to set allowed access times. Outside of those times, a logged-in user has their session abruptly terminated. This could wipe out unsaved work (but the user would hopefully save before leaving for the day) and could crash a database system, but it does allow you to back up all files. Of course, if backup is your sole objective then there are any number of applications which will back up open files.

Having more users than licenses is almost an impossible situation. You risk alienating one user in order to please another. The password-linked screensaver mentioned above could help if it would start a second timer and close the session after a set period of time -- but this still risks losing data when sessions are abruptly shutdown.

In the end, the best solution is probably a combination of password-linked screensavers, open file backup solutions and education of the users. Firm and enforceable policies about logging out could also help. That way, if all else fails, you can appeal to the recalcitrant user's supervisor.

Would you like to receive Dave's future columns via e-mail? Go to our registration page, enter your password, and edit your profile by checking the box next to "Net Know-how with Dave Kearns."

This was last published in February 2002

Dig Deeper on Network management and monitoring

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.