Testing Updates
To prevent faulty updates, test your scripts before putting them in production, just as you would any other script. On your test PC, double-click the .wsf update script in the central script repository.
If you want to test a complex update on several clients, place the clients in an AD group and create a .txt file that restricts the update to that group (as I described in "Scripting a Corporate Update System," October 2002, http://www.winscriptingsolutions.com, InstantDoc ID 26360). For example, if the update is 27, the script is 27.wsf and the configuration file 27.txt specifies the AD group for the text PCs. All PCs not in the group will ignore update 27 and reset themselves to look for update 28; all PCs in the group will execute 27 and reset to wait for 28. If you need to refine your update script and test it multiple times, you can keep creating update numbers (28, 29, 30, and so on) until you get the result you want.
Although this approach forces all other clients to ignore an update, the overhead is minimal. If you have only a few test PCs, your other alternative is to wait for all of them to execute update 27, make the necessary changes to the scripts in 27, then change the CUSClientLastUpdateNumber.txt file on each of the test clients back to 26 so that they all download 27 again.
Determining a Client's Update Number
At some point, you might want to know each client's update number. You can either take a snapshot of the current situation when required or enhance the corporate update system to ensure that the data is always available when you need it.
Your first idea for a snapshot solution might be to script an update that has clients email you their name and most recent update number. Or you could create on a server a share with permissions that let the clients' Run as account write to the share, then create an update that writes to the directory a file containing the client name and update number. Sharp-eyed readers will realize that these solutions do nothing more than return the update number of the update you just created. The solutions don't help you find out why several clients that are supposed to be running the corporate update system never respond. One snapshot solution that works is a server-based script that connects to every client, reads its CUSClientLastUpdateNumber.txt file, and records the result.
However, I prefer a more permanent solution. Every object in AD has 15 text attributes that you can use for your own data storage. I discuss these Extension attributes in "Extending Active Directory's GUI," February 2000, http://www.winnetmag.com, InstantDoc ID 7883, and "Generating Deployment Reports," March 2000, http://www.winnetmag.com, InstantDoc ID 8054. You can use any of these attributes to store the update number. Just modify the end of the CUSClientUpdater.wsf script to use Microsoft Active Directory Service Interfaces (ADSI) to write the update number to AD as well as to the CUSClientLastUpdateNumber.txt file, as Listing 4 shows. You can then search AD at any time to populate a Microsoft Excel spreadsheet with clients' update numbers ("Generating Deployment Reports" explains the details).
If you're wondering why you should keep the number on the local machine at all if you can place it in AD, the answer is simple: You never know which DC a client will hook up with when it reads or writes data to AD, and replication takes minutes between DCs; so, a client might write an update number to one DC, then minutes later read a lower update number from another DC. For example, if a client writes a value of 77 to DC A and 5 minutes later reads the value of 72 from DC B before A has had a chance to replicate to B, then the client will try to run updates 73 through 77 all over again—and that's bad news.
Manipulating the Update Numbers
The earlier articles in this series don't discuss copying a CUSClientLastUpdateNumber.txt file to a client. If the file is absent on a client, the CUSClientUpdater.wsf script simply looks for update 1 in the central script repository. However, over the years, I've needed to change this procedure for some organizations. Let me give you a couple of real-life examples.
Prev. page
1
2
[3]
4
next page 
