\[Editor's Note: Email your scripting solutions (400 words or less) to Reader to Reader at Please include your script and phone number. We edit submissions for style, grammar, and length. If we print your contribution, you receive $100.\]

I need to keep track of build numbers for many commercial Web applications, so I created a Windows NT command script, BuildCtr.cmd, that uses a Comma Separated Values (CSV) file, buildctr.csv, as a database. The database has four fields: application name, current build number, build increment, and last build date.

Whenever developers need to work on a new build of a Web application, they go to the command line and enter the command

                              BuildCtr.cmd AppName

where AppName is the name of the Web application on which they want to work. BuildCtr.cmd executes and returns the application's next build number, then updates the database with the new build number and last build date. If developers don't enter the application name as an argument, the script displays an error message, then exits.

Listing 1 contains an excerpt from BuildCtr.cmd. (You can find the entire script and the buildctr.csv file in the Code Library on the Win32 Scripting Journal Web site at Here's how BuildCtr.cmd works. After a developer enters the command to run BuildCtr.cmd, the script tries to locate the specified application in the database. If the script can't find the application, the script displays the message AppName not found in buildctr.csv, then exits. If the script finds the specified application, the script retrieves the current build number and build increment. Using these values, the script calculates the new build number (current build number + build increment) and stores it in the BUILDCTR_RESULT environment variable.

Next, BuildCtr.cmd loops through the records in buildctr.csv and copies them to another CSV file called buildctr1.csv. However, the script doesn't copy the record for the current Web application. Instead, BuildCtr.cmd appends the updated record for the current Web application to buildctr1.csv. Finally, the script renames buildctr .csv to buildctr.csv.old, then renames buildctr1.csv to buildctr.csv.

To use BuildCtr.cmd, you need to customize buildctr.csv with your application names, current build numbers, and build increments. The application name can't include embedded commas. As callout A in Listing 1 shows, the For command uses commas as the delimiter when searching buildctr.csv for the application name. A comma in the application name will throw the For command's parsing off.

BuildCtr.cmd includes a simple file-locking mechanism to prevent users from simultaneously accessing buildctr.csv. Before searching buildctr.csv, the script checks for the existence of a file called buildctr.lck. If buildctr .lck doesn't exist, the script creates this file and starts searching buildctr.csv for the specified Web application. If buildctr.lck exists, the script enters a wait loop because another instance of BuildCtr.cmd is running. Depending on the results of the search, the script deletes buildctr.lck after updating buildctr.csv or after sending the AppName not found in buildctr.csv message.

You can use BuildCtr.cmd as a standalone application or call it from another batch file. Listing 2 contains an example of a calling batch file. The calling batch file's BUILDCTR_RESULT environment variable will contain the next build number after BuildCtr.cmd executes. Before the calling batch file terminates, it sets BUILDCTR_RESULT to nothing in the interest of good housekeeping.

I wrote BuildCtr.cmd to work under NT and have tested the script on NT Server 4.0 and NT Workstation, Service Pack 4 (SP4), SP5, and SP6. Although I wrote BuildCtr.cmd to track Web application build numbers, you can easily adapt it for other applications that require you to track sequential counts.

Find Out Servers' Lockout Policy Numbers
The scripts and that Dick Lewis provided in "Real-World Scripting: Testing and Changing Administrator Account Passwords" (November 1999) have come in handy several times and are now part of my scripting toolbox. In the article, Dick noted that before you use, you need to find out your servers' lockout policy number. Because the script tests the administrator account password on targeted servers, if you execute repeatedly, you might lock out accounts if the number of times you run the script equals the lockout policy number.

I developed the Perl script,, to report servers' lockout policy numbers. If you run against the servers on which you're testing and changing passwords, you'll know how many incorrect attempts the lockout policy allows.

Listing 3 contains an excerpt from (You can find the entire script in the Code Library on the Win32 Scripting Journal Web site.) The script begins by creating the structure of the HTML report it generates. The script then opens an input file containing the names of the servers you want to target. In the input file, you must precede each server name with double backslashes (\\). As callout A in Listing 3 shows, the script uses the NetUserModalsGet() call of the Win32::Lanman module to check each server's lockout policy number. The script then records that number in the HTML report.

To use this script, you need to install the Win32::Lanman module. You can obtain this free module at