Security

Quickly deploy Microsoft security patches with KiXtart login scripts

When you can't use systems management tools or Windows Update to apply security patches, login scripts can be perfect alternatives. Find out how one IT pro deploys Microsoft security patches using a KiXtart login script.


With the Blaster onslaught fresh in our minds, many can attest to the challenges they encountered trying to deploy a Microsoft security patch in a hurry. Those of you equipped with an arsenal of system management tools, such as Microsoft's Systems Management Server (SMS), Novell's ZENworks, or one of the Altiris products, probably have a smug look on your face and are wondering what all the deployment fuss is about. For the remainder of the IT community, having to deploy individual security patches quickly and effectively can be a real issue.

One solution I've created, which can be adapted to accommodate most any Microsoft patch, is to use a script that can be executed during the login process to detect whether a specific vulnerability patch exists, and, if not, apply the required patch. Using my favorite scripting tool, KiXtart, and targeting the latest RPC vulnerability (similar to that exploited by Blaster), we managed to deploy the MS03-039: Security Update for Windows (824146) to more than 1,000 workstations on all three of our Windows platforms (NT/2000/XP) within a couple of days.

Creating and launching the script
There are five essential steps for creating and launching a patch deployment script. (Listing A contains the complete text for the script I used to deploy the 824146 update.)

First, you must ensure that these eight specific criteria are met (the criteria are listed along with their corresponding line numbers in the script):
  1. Ensure the patch is not run within a Terminal Service session (56).
  2. Ensure the patch is not being applied to a server operating system (57).
  3. Ensure the patch is applied for a client with local administrator privileges (58).
  4. Ensure that the target PC doesn't have the patch already applied.
  5. Determine whether three DLLs meet a specific version level (62-64).
  6. Ensure that the Registry indicating installation doesn't already exist (65).
  7. Ensure that the folder under %systemroot%\$NTUninstallKB8241146$ doesn't already exist (79).
  8. Check to see whether a dial-up session is being used. If so, depending on the size of the patch, a deployment may not be forced.

Next, select the patch that corresponds to the target operating system. Microsoft has a habit of using completely different types of names for the same patch depending on which operating system it applies to. In the case of patch 823980 (MS03-026), I saved each patch with Win followed by a two-character abbreviation of the operating system, followed by the patch name and the processor and language type (e.g., WinNT-KB823980-x86-ENU.EXE or WinXP-KB823980-x86-ENU.EXE).

Apply any optional command line parameter for patch execution. For example, for Windows NT, there's a nice /M parameter that allows the patch to run in unattended mode with no user intervention. Unfortunately, for Windows XP, the closest is simply the /U option, which allows for unattended installation. The downside of using /U is that it also allows for user interaction and the capability to cancel the installation process. There's also the ever popular /Q for quiet installation. The problem with quiet installation is that it can cause the processor to spike for a long period of time and clients are prone to believing that their PC has locked up, and, consequently, they reboot. I suggest using quiet mode only for small patches.

Next, you must execute the patch. Prior to execution, I prefer to make one last check to ensure that the patch exists. In our organization and in many organizations, using common drive letters, such as S:, allows patches to be stored in consistent locations across servers without having to use UNCs. The difficulty is that local administrators may occasionally delete or relocate code that you've placed on a server. Checking for the existence of an executable before attempting to run it will help you avoid ugly and embarrassing error messages on client's screens.

Finally, launch the script either with a CALL command from within an existing KiXtart script (e.g. call s:\windows\security\824146fix.kix) or from a command file if you want to run the patch independently of a login script (e.g. S:\Windows\Security\WKIX32.EXE S:\Windows\Security\824146fix.kix /i).

Future patch deployments
The steps I've outlined in this article are essentially the same steps that will be undertaken for any patch deployment. In fact, when the 824146 patch was released, I simply modified the previous script for deployment of the 823980 patch and, within an hour, I was finished. The specific prerequisite conditions may vary slightly, as will the name(s) of the patch executables, but the balance of the script will remain relatively unaffected. This makes it quite easy for you to modify and redeploy as necessary.

 

Editor's Picks

Free Newsletters, In your Inbox