On the journey to create a successful script, there are sometimes unexpected detours in the
road. Sometimes a script just comes together and works on the first try. Other times, there are
challenges at every turn. I have to admit that UptimeReport.bat didn’t work correctly on the first
or even the second try. I ran into problems finding utilities that provided the information I
needed, sorting the utilities’ output, dealing with errors, and getting output displayed in a
meaningful format. My struggles revealed some real-world problems that scripters can face. By
sharing the lessons I learned, I hope you can avoid similar problems.
Make sure a tool’s output is consistent across OSs. The first time I got UptimeReport.bat
working, a savvy systems administrator looked at the report and questioned some of the uptime
numbers. After some investigation, I realized that my script was mysteriously introducing some
bogus numbers into the report. It took only a few minutes of testing to determine that the
Uptime.exe utility in the Microsoft Windows 2000 Server Resource Kit reports uptime results
differently on Windows Server 2003 and Windows 2000 systems. When you use the For
command to extract data from Uptime.exe’s output, these differences cause problems. For this
reason, I used Sysinternals’ PsInfo tool. It has a consistent output format that works well with
the For command.
Keep an eye open for rare but possible situations. I noticed that UptimeReport.bat ran into
problems a couple of times when parsing PsInfo’s uptime output. After looking into the matter, I
discovered that PsInfo would occasionally output an Error reading uptime message instead of
reporting uptime statistics. Like most of the utilities that gather uptime statistics, PsInfo
computes uptime based on event log entries. If those entries have been cleared or present a
conflicting picture of the actual uptime, PsInfo returns the Error reading uptime message. To
account for these errors, I included code that detects and reports them. Callout G in Listing 1, in the main article highlights this code.
Make sure a tool works as expected. One key requirement for UptimeReport.bat is that the
servers’ uptime statistics must be sorted so that the most recently booted servers appear at the
top of the list (i.e., in ascending order). PsInfo specifies each server’s uptime in terms of days,
hours, minutes, and seconds, so I wrote code that dropped the seconds figure and performed a
quick math operation so that each server’s uptime is given terms of minutes. I wanted to use the
Sort command to sort the uptime statistics, so I devised a test to verify whether the Sort
command would work properly. I created a text file with some test entries in it (numbers 1
through 10) and tested the Sort command against this file. As you can see from the results
C:\>sort D:\test.txt
1
10
2
3
4
5
6
7
8
9
the Sort command thought that 10 is less than 2, which is obviously a problem. The reason for
this problem is that the Sort command puts entries in alphanumeric order. Fortunately, I
discovered Kilowatt Software’s FSort, which has a /Numeric sort option.
Avoid potential problems. The Dsquery tool lets you query a group of servers in an Active
Directory (AD) organizational unit (OU) for information, such as uptime. However, I discovered a
couple of potential problems with using Dsquery. One problem is that you might have entries in
AD for non-Windows devices. When these devices are queried, the query fails—but more
important, the wait time can be significant, which make the script’s run time extremely long.
Another problem is that you might have servers for which you don’t need uptime statistics (e.g.,
a server that’s in the process of being retired). Thus, I provided two options in UptimeReport.bat.
One option is to use Dsquery with an exceptions list. The other option is to use an input file to
specify the servers to query. Keep this code handy for future scripts. I can guarantee you that
you’ll reuse this Dsquery and exclusion code many times.