Write a FinalSetup.vbs Script
If you like batch files, you'll love WSH scripting. WSH is a script interpreter (engine) built into Win2K and Win98. You can install it on NT 4.0 and Win95 as well. The WSH interpreter supports WSH commands, VBScript, and JScript (Microsoft's version of JavaScript).
You can use WSH scripting to manipulate the file system, automate desktop applications, manage a Microsoft SQL Server system, and much more. Learning WSH scripting is easy—all you need is a text editor and a computer with WSH installed. The Microsoft Windows Script Technologies Web site (http://msdn.microsoft.com/scripting) has a great deal of information available for download, and the "Related Resources" box lists articles you might find useful.
I used WSH and VBScript to write the FinalSetup.vbs script, which Listing 1 shows. You'll notice that I like a lot of white space and plenty of comments in a script. Comments make a script easier to read and can help you determine what the script does when you open it up months down the road. In many cases, I even retain, but comment out, any debugging code I added when I wrote and tested the script.
FinalSetup.vbs performs the final steps of the setup process before the installer turns a computer over to the end user. The code confirms that the person running the script is logged on as Administrator and that the computer has joined the domain. The script then adds the WEBDEV global group to the Local Administrators group on the computer to enable the Web developers to install software and configure their computers.
The script's first two statements are very important and should be in every script you write. The OPTION EXPLICIT statement requires you to declare variables before you can use them, thus helping you prevent errors in your scripts. Declaring variables is optional in VBScript. However, if you don't use OPTION EXPLICIT, a typo in a variable name will create a new variable. Such an error might be easy to find in a simple script but not in one that contains hundreds of lines. The ON ERROR RESUME NEXT statement prevents your script from stopping if it encounters an error. The purpose of this statement isn't to ignore errors but to let you deal with them gracefully so that they aren't fatal to the script.
FinalSetup.vbs's next section declares variables. You can place all the variables on the same line, separating them with commas, or you can place them on separate lines, as I've done. A variable name must begin with a letter and can have as many as 255 characters. The name can contain letters, numbers, and underscore (_) characters. Using a lowercase one-letter prefix to indicate the type of data (e.g., object, string, integer) stored in the variable is customary.
The next section of the script declares constants, which are similar to variables except that you can't change their values after you declare them. The script uses three constants: GLOBAL_GROUP, LOCAL_GROUP, and DOMAIN.
To perform real work, a script needs to use objects, which have methods (functions that an object performs) and properties (characteristics). Before a script can use an object, it must instantiate (create) the object. Instantiating an object loads it into memory and registers it. In WSH scripting, you use the Wscript.CreateObject() function to instantiate an object. FinalSetup.vbs uses several objects that are built in to WSH.
The next section of FinalSetup.vbs creates two objects: the Network object (Wscript.Network) and the Shell object (Wscript.Shell). The Network object lets the script connect to network resources. The Shell object lets the script run an executable, manipulate the registry, read environmental variables, create shortcuts, and perform several other functions. In each case, the script stores the created object in a variable (oWshNet and oWshShell, respectively) and uses the variable to access the object's methods and properties.
The local Administrator must be logged on to the computer for the script to be able to complete its tasks. To confirm that the user is the local Administrator, the script gets the value of the Username property of the Network object created earlier and stores the value in the sUser variable. The script retrieves the computer name from the Computername property and stores it in the sCompName variable. Then, the script uses the UCASE() function to convert the value of sUser to uppercase and compares the converted value with ADMINISTRATOR. If sUser's value isn't equal to ADMINISTRATOR, the script displays an error message and exits.
When the user is the Administrator, the script continues to the next step, which ensures that the computer has joined the domain. First, the oWshShell.RegRead method reads the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\DomainCache\GONDOR registry subkey and stores the value in the sInDomain variable. Then, the script performs two checks. First, it checks whether sInDomain is null (i.e., whether the registry subkey is empty). If it is, the script displays an error message and exits. Second, the script checks for the fatal error —2147024894, which occurs if the registry subkey doesn't exist, and exits gracefully if the error has occurred. If the registry subkey weren't present and the script didn't include the ON ERROR RESUME NEXT statement that I mentioned earlier, the user would see the error message that Figure 1 shows.
Register
