Understanding How the Script Works
As I mentioned previously, ApplyReg.vbs relies on several technologies to do its work. WSH 5.6 provides the engine that processes the script's code and provides some key objects, such as the WshArguments object, which passes the command-line parameters to the script, and the Regular Expression (RegExp) object, which evaluates registry strings. ADSI lets the script connect (i.e., bind) to AD and read each computer object's attributes. WMI lets the script bind to a remote registry and use StdRegProv to update the registry.
ApplyReg.vbs begins by defining several constants and global variables, then calls the CheckForCScript subroutine, which Web Listing 1 shows (http://www.winnetmag.com, InstantDoc ID 40714). This subroutine verifies that you're running the script with the CScript host. You must use CScript because WScript doesn't support the WScript object's StdOut property.
After verifying the host, the script sets the input file you specified with the /f parameter and the registry file you specified with the /r parameter to the strRptFileName and strRegFileName variables, respectively, as Web Listing 2 shows. (If you don't specify the /f and /r parameters when you launch ApplyReg.vbs, the script displays a message informing you that both parameters are necessary.) The script calls the SampleCommandLine function to display the command-line syntax, then terminates.
Next, ApplyReg.vbs uses the Script Runtime Library's Dictionary object to define the five registry root keys (e.g., HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT) as constants. The script later uses these constants to access the registry keys and subkeys that the registry file specifies. Using the Dictionary object is a straightforward scripting operation, so I haven't included a listing for it. If you're unfamiliar with the Dictionary Object, see the Microsoft Developer Network (MSDN) documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/jsobjdictionary.asp.
ApplyReg.vbs creates a comma-separated value (CSV) report that you can view after the script runs. To uniquely name this report, the script uses the GenFileName function, which takes a filename (without the extension) as an input parameter (i.e., the prefix parameter). In this case, the prefix parameter is ApplyReg, as Web Listing 3 shows. GenFileName creates a unique filename by appending the date and time to the filename ApplyReg. For example, if you ran ApplyReg.vbs on April 16, 2003, at 11:43 a.m. and 53 seconds, GenFileName would generate a file named ApplyReg-030416-114353.csv. Note that the date follows the YYMMDD format. Callout A in Web Listing 3 shows the GenFileName function call. The rest of the code is the function itself.
Given the report name, ApplyReg.vbs creates an instance of the Script Runtime Library's FileSystemObject object, which the script uses to create, open, and write to the report. The script also uses this object to open the registry file for reading, as the code in Web Listing 4 shows.
ApplyReg.vbs creates a RegExp object to evaluate each line of the registry file. This evaluation lets the script determine whether it should create a registry key or a registry entry. A registry entry is a value name, a data type, and a value. If the script needs to create a registry entry, RegExp also determines the type of entry to make: String, Binary, DWORD, Expandable String, or Multi-String. The code in Web Listing 5 demonstrates how the script creates the RegExp object and sets that object's properties.
Before the registry file evaluation begins, ApplyReg.vbs calls the BindDN function to attempt an ADSI bind operation for each DN in the input file. BindDN takes as input one line from the input file at a time and returns a string of values, depending on the success or failure of various operations within the function, as Figure 2 shows.
Listing 1 shows the BindDN function. Notice how the function sets the BindDN output values that appear in Figure 2. In the case of BindDN = strDN||None||Invalid, which callout A in Listing 1 shows, the function doesn't find the DN in AD. Either the specified DN is invalid or the computer name has been deleted from AD. In the case of BindDN = strDN||strComptName||Host, which callout B in Listing 1 shows, the function finds the DN and sets the strComptName variable to the dNSHostName attribute (i.e., the computer's DNS host name). In the case of BindDN = strDN||strComptName||NetBIOS, which callout C in Listing 1 shows, the function finds the DN but doesn't set the dNSHostName attribute for the computer. Therefore, BindDN retrieves the cn attribute, which is mandatory for computer objects. The cn attribute is usually the computer's NetBIOS name.
Prev. page
1
2
[3]
4
next page 
