I often use Group Policy to customize PC and server settings. However, sometimes I need more control, so I manually make registry changes. The problem with the manual approach is that between new installations, I often forget how to accomplish the registry changes.
Like most administrators, I'm cautious about making registry changes, so I decided to come up with a way to store registry-modification information and perform the modifications with minimal risk. My first crude solution was to maintain a folder in which I kept a number of common .reg files. Whenever I made a new registry change that I thought I might need later, I added a new .reg file to the folder. In many cases, the .reg files came in pairs, with one file to enable a setting and another file to disable the same setting. With so many files, I had a hard time keeping them organized, which made finding a particular .reg file difficult.
After examining my usage patterns with the .reg files, I discovered there were only about 20 or 30 files that I used regularly. I realized that the optimal solution would be to integrate the information in those files into a menu-driven script. That way, I could easily find and select the registry modification I needed. And by putting that menu-driven script on a shared folder and connecting to that share, I could make the changes to whatever computer I was logged on to.
Figure 1 shows the menu interface of my menu-driven script, RegMods.Menu.bat. Listing 1 shows an excerpt from this script. You can download the entire script from the Windows Scripting Solutions Web site. (Go to http://www.windowsitpro.com/windowsscripting, enter 49360 in the InstantDoc ID text box, then click the 49360.zip hotlink.)
RegModsMenu.bat uses Choice .exe with the If ERRORLEVEL command to route the script's flow to the code that will perform the registry modification selected from the menu. The script uses the Reg.exe tool to perform that modification.
The Command of Choice
Choice.exe has been around since the early days of DOS. The Choice command lets you use keyboard selections to route a script's flow to the appropriate section of code. In the original RegModsMenu.bat script, I used Choice.exe from the Microsoft Windows 2000 Server Resource Kit. This version of the tool worked great until I tried to run the script on a Windows Server 2003 machine. The syntax for the version of Choice.exe in the Win2K resource kit differs slightly from the syntax for the version of Choice.exe built into Windows 2003.
Scripts can fail if different versions of the same tool use different syntaxes. There are several ways to resolve a syntax problem. One way is to select a version of the tool that works correctly on all the OSs you're working with, then place this version in a shared folder and use that copy each time you use the tool. That way, you can get consistent results without worrying about what version is on the local machine. RegModsMenu.bat includes code to specify a remote location for Choice.exe and Reg.exe, as callout A in Listing 1 shows. This code is commented out but can easily be implemented by removing the double colons and specifying a remote path.
Another way to resolve a syntax problem is to have your script detect what version of the tool exists on a machine, then have separate sections of code for each version of the tool. This technique works well if you know a tool exists on all the machines but the versions might differ. I used this technique in RegModsMenu.bat.
The first step in using the version-detection technique is to determine one easily detectable difference between the versions' syntaxes. For example, the version of Choice.exe in Windows 2003 includes an /M switch but the version in the Win2K resource kit doesn't.
The next step is to write code that looks for and reacts to this difference. For example, as callout C in Listing 1 shows, RegModsMenu.bat runs the Choice /? command and determines whether the /M switch is present in the command's output.When this switch is present, the script jumps to the code that uses this switch, as callout D shows. When the /M switch isn't present, the script goes to the code that doesn't use this switch, as callout E shows.
The version-detection technique is well suited for those situations in which there isn't a single version of the tool that works on all the target computers. Version detection also works well when a command is used only a few times. However, when you have a script that uses a command many times, the technique might be impractical. For example, RegModsMenu.bat uses Choice.exe only once, so including two versions of the Choice command doesn't add much code to the script. However, the script uses Reg.exe 26 times. For illustration purposes, let's say that different versions of Reg.exe have different syntaxes. (Fortunately, in reality, this isn't true.) Having to include two versions of the Reg command for each of those 26 instances would add a lot of code, making the remote-path approach a better solution.
As I mentioned previously, Choice .exe lets you use keyboard selections to route a script's flow. Choice.exe assigns values to the keys you specify. The first key you specify is assigned the value of 1, the second key you specify is assigned the value of 2, and so on. Thus, in this case, when the user presses the A key on the keyboard to select the My Computer registry modification, Choice.exe returns a value of 1. When the user presses the B key to select the New Batfile registry modification, Choice.exe returns a value of 2, and so on. The selected key's value is set to the ERRORLEVEL environment variable.