Copying Updates to the Central Script Repository
PCs are fast these days. If you copy a new update named 27.wsf to the central script repository before copying the 27.txt file (if one exists) or the supporting files in the folder named 27, PCs might try to run the central script repository scripts and not find the files they need or might run the script when they shouldn't do so. Both situations are hard to clean up after because they can leave clients in a lot of different states. Even if you copy all the update files at the same time to the central script repository directory, you can cause problems if a client is looking for 27.wsf at just the wrong time. The correct way to move scripts to the central script repository is to upload the 27.txt file and the 27 folder of supporting files first—then copy 27.wsf to the repository last.
Clearing Obsolete Updates
If you create an update 27 that installs some files, then later create an update 52 that installs a more recent version of the same files, clients might no longer need to execute 27, but new clients will do so anyway. To solve this common problem, you can simply delete the main body of the script in 27.wsf so that the file contains the following
<job>
<script language="VBScript">
</script>
</job>
New clients will run the file, but it will do nothing because it has no code. If you need to make many updates obsolete, see the section "Manipulating the Update Numbers" later in this article.
Correcting Faulty Updates
Mistakes happen. The corporate update system can make changes on many clients quickly before you notice a mistake in an update script. If you see a mistake, your tendency will be to delete the update, but think carefully before taking this action because it can leave clients that are executing the update in a bad state. If you decide to take the update out of service, you can quickly do so by renaming the .wsf script to a name that clients aren't looking for (e.g., 27a.wsf).
Typically, the easiest solution is to let the faulty update run, then create a new update that undoes the damage of the faulty update. However, if the situation is grave and a new script can't solve the problem, you must immediately rename the faulty .wsf file and manually update the clients. You now have some clients that have executed 27.wsf (for example) and some that haven't. How can you find the faulty clients so that you can manually correct them? The clients that have executed 27.wsf are now looking for 28.wsf. You can add in an update called 28.wsf that simply emails you the names of the clients that execute it. Then you have your list of the clients you need to fix. The clients that haven't executed 27.wsf are still waiting for it to appear (you renamed it, so it isn't available). After fixing the clients that downloaded the faulty update, you can remove the code from 27.wsf and 28.wsf so that all the clients will be ready for update 29.
Prev. page
1
[2]
3
4
next page 
