First, over time, the updates in the central script repository become obsolete. If you delete the body of obsolete scripts, as I suggested earlier, you can eventually end up with dozens of empty updates. To avoid all these empty updates, you might want to have new clients start at a higher update number, which is a reason to upload a different CUSClientLastUpdateNumber.txt file to new clients. Second, one organization I worked with designed its client configuration build procedure to automatically install the corporate update system client files. After installation, the clients used the corporate update system to update themselves to the current build. However, after a while, we needed to update the configuration build procedure for the new clients that we were adding, and rather than forcing new clients to go through 50 or 60 updates, we wanted to roll up the changes in these updates into the new build procedure.
The second example is simple to address. Let's say that you roll up 34 updates into your new build procedure. Then, you copy CUSClientLastUpdateNumber.txt to the new clients as part of the corporate update system's client-side files but place the number 34 inside the .txt file so that the clients begin by looking for update 35.
Addressing the first situation is a little trickier given the corporate update system's current setup. The corporate update system reads CUSClientLastUpdateNumber.txt before starting its update run, then writes a new .txt file at the end of its run. At no point during this process does the CUSClientUpdater.wsf script check for a new .txt file, nor can the updater scripts that CUSClientUpdater.wsf runs tell CUSClientUpdater.wsf to do some task. If you want to alter the processing of the CUSClientUpdater.wsf script through some communication from the updater scripts, you need to change CUSClientUpdater.wsf. Here's one easy modification that I've used. You change the CUSClientUpdater.wsf section that performs the updates (which "Scripting a Corporate Update System, Part 2," November 2002, http://www.winscriptingsolutions.com, InstantDoc ID 26632 shows) to look for a file with a .num extension. So if your clients are looking for update 34 and you want them to skip to update 67, create in the central script repository a 34.num file that contains the value 67. Then, modify the beginning of CUSClientUpdater.wsf's Do While loop to use a variable such as the following
CUS_SCRIPT_REPOSITORY &
intUpdNum & ".NUM"
to check for a file with the .num extension. If CUSClientUpdater.wsf finds such a file, the script should open and read the file, just as it does the .txt file, and the value that the .num file contains will be the number of the next update to run. Listing 5 shows such code, which is just a modification of the CUSClientUpdater.wsf code that opens the .txt file. CUSClientUpdater.wsf starts its loop. When it gets to an update that has a .num file, it reads the integer inside, skips the current update, and starts again with the update that's associated with the integer it just read.
Further Enhancements
To update the CUSClientUpdater.wsf and CUSClientUpdater.job client-side files, you can just copy the files to the clients as part of an update. If you do so, you need to be sure that the immediately following updates don't rely on your new .wsf file because the previous .wsf version might execute them. For example, let's say that .wsf v1 executes update 34, which replaces the script with .wsf v2. At this point, .wsf v1 is still running, so you need to ensure that if updates 35, 36, 37, and so on exist, it doesn't matter that .wsf v1 is running them. CUSClientUpdater.job won't pick up the new .wsf v2 script and run it until .wsf v1 stops.
Here's a simple solution. Make update 34 the last update that .wsf v1 ever runs by modifying .wsf v2 to look for updates called 35a, 36a, 37a, and so on. Because .wsf v1 doesn't look for the a suffix, it never finds any updates after 34, so it stops execution and .wsf v2 picks up where it left off. Next time around, you change to b, then c, and so on. This solution works well and lets you keep your numbering scheme intact.
You don't need to install .wsf v1 on new clients from that point on as long as .wsf v2 (or later) can run earlier updates. Just install .wsf v2 onto clients, but make sure that each update in the central script repository has a corresponding a, b, c, or whatever version to ensure that .wsf v2 picks up the old updates as well as the new ones.
Checking for Group Membership
The corporate update system has one limitation that comes into play when clients are checking for group membership to determine whether to apply an update. Groups can be nested—that is, groups can be members of groups. If a client is in group AAA, the corporate update system functions IsUpdateToBeRunOnThisPC and GetPCGroupMembership will definitely pick it up. However, if the client is a member of AAA, and AAA is a member of BBB but the client isn't, and the functions are looking for members of BBB, the functions won't find the client. If you want to check for nested clients, you need to modify these functions.
Well, that's it for this corporate update system article series. If you come up with any great enhancements, let me know.
End of Article
Prev. page
1
2
3
[4]
next page -->
