After you perform these three tasks, your simple corporate-update—system installation system will be ready to go. Let's take a closer look at this system to see how it works.
Installing Files on the Client
Listing 1, like the other Windows Script (WS) files in this series, imports constants and functions from CUSLibrary.vbs and another library file, GenericLibrary.vbs. Web Listing 1 and Web Listing 2 (http://www.winscriptingsolutions.com, InstantDoc ID 26969) present excerpts from CUSLibrary.vbs and GenericLibrary.vbs, respectively. (Make sure that you change the paths in Listing 1 to point to your libraries.) Although I've reused a lot of code from these libraries throughout this article series, code reuse isn't always possible. For example, I would have liked to import generic constants (such as FSO_FORCE_DELETE and FSO_COPY OVERWRITE) from GenericLibrary.vbs into the CUSClientFilesInstaller function in CUSLibrary.vbs. Then, I wouldn't have had to define the constants in CUSLibrary.vbs, or at least I would have been able to use values of TRUE in SimpleCUSClientTargetter.wsf without having to remember what each TRUE value meant. However, because the libraries are VBScript files and not WS files, SimpleCUSClientTargetter.wsf can't use the XML tags to import the libraries. Instead of using complex mechanisms, I simply redefined the two FileSystemObject constants in CUSLibrary.vbs.
The CUSClientFilesInstaller function installs the two payload files onto a target client PC. The constant CUS_INSTALLATION_PATH represents the path where these two files are stored. Two other constants, CUS_CLIENT_JOB_NAME and CUS_CLIENT_SCRIPT_NAME, represent the individual files themselves. As I mentioned in Part 2 of this series, the installation server doesn't typically deliver the CUSClientLastUpdate.txt file to a client. If the CUSClientUpdater.wsf script (described last month) can't find the text file, the script assumes that it needs to attempt to retrieve update number 1 from the central script repository. In this case, the script creates the text file because the file doesn't already exist and places the number of the last successfully completed update into the new text file.
CUSClientFilesInstaller needs to know the client's IP name to know where to copy the schedule task .job file and script files. (The function can use the client's IP address instead, but Listing 1 always passes CUSClientFilesInstaller the IP name.) The function declares variables and assembles paths that the script in Listing 1 will use later. Although the function doesn't have to use the variables strPCAdminShare and strPCTasksFolder, both of these components help make the corporate update system easily extensible and modifiable.
The function begins by creating an fso variable that references the Scripting::FileSystemObject object to allow for some file manipulation. Next, the FileSystemObject::CopyFile method copies the task scheduler file to the client. If an error occurs, the function quits with a return code of 1 so that the calling script knows that an error occurred. Because an error at this point in the process would be a failure to copy the first file to the client, the script can safely quit because it hasn't yet added any files to the client PC. When an error doesn't occur, the function uses the same FileSystemObject::CopyFile method to copy the client updater script to the client. If an error occurs during this copy operation, the function uses the FileSystemObject::DeleteFile method to remove the previously copied task scheduler .job file from the client. After the function removes the .job file, the function quits with a return code of 1. When the function successfully copies both files to the client, the function quits with a return code of 0.
The SimpleCUSClient Targetter.wsf Script
The script in Listing 1 starts by declaring and initializing several variables. The strLogFilePath variable represents a path to the log file that records all attempted client installations. The CreateFilenameFromTimestamp function in GenericLibrary.vbs outputs a formatted date string. The script uses the Now() VBScript function to produce from the date string a filename for the log files. The filenames that the CreateFilenameFromTimestamp function returns appear in a year-month-day-hour-minute-second format (e.g., 2002-05-23-13-05-09 to indicate May 23, 2002, 13:05:09), which lets you easily sort them in a directory listing. (You can modify this output to suit the way you want your dates formatted.) The script also uses adsMgmtGroup, which gets passed a Lightweight Directory Access Protocol (LDAP) path, to hold an Active Directory Service Interfaces (ADSI) reference to the AD group.
The next section of the script opens and initializes the log file. To ensure that the log file is readable, the script uses a separator, such as a string of dashes (—-) or equals signs (===), that's defined as a constant called SEPARATOR in GenericLibrary.vbs. The script also calls the GetCurrentUsername and GetCurrentComputername functions in GenericLibrary.vbs to record details for debugging purposes.
After the script prepares the log file, the real work begins. The script must identify all workstations that aren't part of the Centrally Managed PCs AD group and target each one for installation. The script uses ADO to locate the AD objects. (For information about using ADO, see "An ADSI Primer, Part 5: Using ADO to Script Fast ADSI Searches" and "Automating Excel to Create Trend Charts" in "Related Articles in Previous Issues." The former article introduces ADO, and the latter introduces the SearchAD function that Listing 1 calls.) Because the script needs to search AD for IADsComputer objects that aren't members of the Centrally Managed PCs group, the script uses an ADO filter that specifies that it's looking only for computers (i.e., objectClass=Computer) that aren't members of the AD group we're interested in—i.e., !(memberOf=Centrally Managed PCs). The script uses an ampersand (&) at the beginning of this filter to combine these two requirements.
Prev. page
1
[2]
3
next page 
