| Downloads |
|---|
| 21567.zip |
In a server lab, console switches save space and resources because you don't need to have a dedicated monitor, mouse, and keyboard for each server. However, one problem that commonly occurs when you use console switches is that administrators forget to close sessions when they leave work for the day. Even in a locked data center, leaving sessions open after business hours poses a security risk. So, an unlucky administrator often has to check each server for open sessions.
Although you could use the Microsoft Windows NT Server 4.0 Resource Kit's Winexit utility to log off users at the end of the day, this utility has two drawbacks. First, if users stay logged on for long periods with no activity, the utility automatically logs them off. Second, the utility doesn't save open documents before it logs off users.
I wrote the script LoggedOnUser.bat to make the task of checking servers easier for administrators. LoggedOnUser.bat quickly identifies any servers with open sessions and identifies the administrators who left those sessions open. The script records the results in a log.
LoggedOnUser.bat uses the PsLoggedOn utility. This tool is part of the PsTools freeware from Sysinternals (http://www.sysinternals.com). PsLoggedOn works more consistently than the Nbtstat command and gives the complete domain/user identification information of the logged-on user, the date and time of the logon, and whether the logon was remote or local.
Like most available utilities, PsTools is designed for use in the command-shell window. I hadn't previously used this utility, so I had to determine whether its operation and results were suitable for use in a script. You can make this determination for most utilities by following three steps:
- Read the available documentation, or run the utility with the Help switch (e.g., /?, ?, -H, help) to learn the proper command syntax. Some utilities return Help information if you run them without switches.
- On the command line, test the utility and its switches against a valid target or against valid data. Testing against valid targets and data ensures that the utility operates correctly in your environment. This type of testing also lets you become familiar with the switches, learn how the utility operates, and see what the output looks like. (If you intend to use the utility's output in a script, you must know what the output looks like to determine whether the script needs to manipulate that data into the desired format.)
- On the command line, test the utility against an invalid target or against invalid data. Testing with invalid targets or data lets you find out how the utility handles error situations. This type of testing also lets you become familiar with the utility's error messages.
After you perform these steps, you'll know whether you can use the utility in a script and how to use it programmatically. After I performed these steps with PsLoggedOn, I discovered that I had to add a ping test and counters to LoggedOnUser.bat.
Adding the Ping Test
When I tested PsLoggedOn.bat against an offline server and a bogus server, I discovered that the utility kept trying to connect to the server for up to 1 minute before the operation timed out and the utility returned an error message. Having a 1-minute lag isn't a problem if you manually use the utility to test one server. However, if you programmatically use the utility to test many servers, a 1-minute lag can present a problem if several servers are offline.
To avoid this potential problem, I included a ping test in LoggedOnUser.bat. The script pings each server before running PsLoggedOn.bat against it. If the server doesn't respond to the ping, the script skips to the next entry in the server list.
Adding the Counters
When testing PsLoggedOn.bat, I discovered that the output scrolled off the screen, which made viewing the results difficult. Thus, I decided to use counters to limit the number of displayed output lines to a manageable size. Counters are useful for controlling and enhancing command output. LoggedOnUser.bat uses two counters. One counter tracks the number of server entries displayed in the command-shell window, and the other counter pauses the script when the command-shell window displays the specified number of server entries.
Using the Script
You can find LoggedOnUser.bat in the Code Library on the Windows Scripting Solutions Web site (http://www.winscriptingsolutions.com). Here are the steps to get the script working in your environment:
- Prepare the input file. Create a text file that contains the names to the servers you want to check for open sessions. Enter one server name per line.
- Configure the script. Listing 1 shows the four configurations you need to make. In the first three configurations, you need to replace the sample paths with your paths. In the last configuration, you need to specify the desired value.
I wrote LoggedOnUser.bat for use on machines running NT 4.0. You can also use the script on Windows 2000 machines.
