Valuable Lessons Learned

On the journey to create a successful script, there are sometimes unexpected detours in theroad. Sometimes a script just comes together and works on the first try. Other times, there arechallenges at every turn. I have to admit that UptimeReport.bat didn’t work correctly on the firstor even the second try. I ran into problems finding utilities that provided the information Ineeded, sorting the utilities’ output, dealing with errors, and getting output displayed in ameaningful format. My struggles revealed some real-world problems that scripters can face. Bysharing 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.batworking, a savvy systems administrator looked at the report and questioned some of the uptimenumbers. After some investigation, I realized that my script was mysteriously introducing somebogus numbers into the report. It took only a few minutes of testing to determine that theUptime.exe utility in the Microsoft Windows 2000 Server Resource Kit reports uptime resultsdifferently on Windows Server 2003 and Windows 2000 systems. When you use the Forcommand to extract data from Uptime.exe’s output, these differences cause problems. For thisreason, I used Sysinternals’ PsInfo tool. It has a consistent output format that works well withthe For command.

Keep an eye open for rare but possible situations. I noticed that UptimeReport.bat ran intoproblems a couple of times when parsing PsInfo’s uptime output. After looking into the matter, Idiscovered that PsInfo would occasionally output an Error reading uptime message instead ofreporting uptime statistics. Like most of the utilities that gather uptime statistics, PsInfocomputes uptime based on event log entries. If those entries have been cleared or present aconflicting picture of the actual uptime, PsInfo returns the Error reading uptime message. Toaccount 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 theservers’ uptime statistics must be sorted so that the most recently booted servers appear at thetop 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 aquick math operation so that each server’s uptime is given terms of minutes. I wanted to use theSort command to sort the uptime statistics, so I devised a test to verify whether the Sortcommand would work properly. I created a text file with some test entries in it (numbers 1through 10) and tested the Sort command against this file. As you can see from the results

C:>sort D:test.txt11023456789 

the Sort command thought that 10 is less than 2, which is obviously a problem. The reason forthis problem is that the Sort command puts entries in alphanumeric order. Fortunately, Idiscovered 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 ActiveDirectory (AD) organizational unit (OU) for information, such as uptime. However, I discovered acouple of potential problems with using Dsquery. One problem is that you might have entries inAD for non-Windows devices. When these devices are queried, the query fails—but moreimportant, 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 tospecify the servers to query. Keep this code handy for future scripts. I can guarantee you thatyou’ll reuse this Dsquery and exclusion code many times.