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.