Windows Patch Management, the Free Way

In the second part of our Windows patch management series, we begin a discussion of free solutions with a look at general techniques for querying registry and launch processes on local and remote systems. We also look at various scripting options.

The first article in the Windows Patch Management series provided an overview of Windows patch management. With this installment, we shift our focus to the available solutions. We will begin with an examination of the free options, which can be grouped into three categories:

Scripted solutions

Microsoft operating system enhancements and products

Third-party tools

Many of these methods complement each other and can be combined into comprehensive solutions for both vulnerability detection and patch deployment. Some even incorporate utilities discussed in the previous article, such as HFNetChk from Shavlik Technologies or mssecure.xml file.

Before we dive into the pool of available solutions, let's first examine the general techniques to query the registry and launch processes on local and remote systems. These functions allow you to either develop a custom patch management solution or use one of the third-party utilities (which we will discuss further). Note, however, that verifying the installation of patches based on registry entries alone (rather than based on file version and checksum) can be deceiving for several reasons. Although patches create registry keys to indicate their presence, this does not guarantee relevant files have been installed and are intact, particularly in cases of custom installation procedures. For example, if QCHAIN.EXE is applied to combine multiple hotfixes into a single batch without proper caution, you might experience problems outlined in the Microsoft Knowledge Base article 296861. Similarly, security rollup packages frequently do not include a complete set of registry references created by individual patches they contain. Microsoft's HFNetChk and MBSA utilities provide an option of skipping registry check and relying exclusively on file version comparisons and checksums against entries in mssecure.xml. On the other hand, registry check is the primary mechanism used by Windows Update, so at a minimum, custom scripts will be as dependable as the Microsoft's default patching mechanism.

To find methods to query remote registry via scripting, refer to our Managing Windows Registry With Scripting series. Note that these scripts depend on Windows Management Instrumentation (WMI) components being present on the target machine. This is not a problem when dealing with newer versions of Windows, since, starting with Windows 2000, WMI has been integrated with the operating system. For Windows NT 4.0 workstations and servers, however, WMI will probably need to be installed (a list of links and instructions can be found here).

Local or remote patch installation can also be handled by employing WMI capabilities (by invoking the Create method of the Win32_Process WMI class). The following sample script demonstrates this approach. In general, it is possible to invoke any process in this manner.

For now, disregard the numbers at the beginning of each line -- we will reference them when explaining the code -- but they must be removed, should you decide to test the script.

The script assumes a common scenario involving three computers -- Computer A, from which the script is run; Computer B, where a patch must be installed; and Computer C, which contains the patch executable. There are two main obstacles in this case. The first, the ability to launch a remote process in the security context of an arbitrarily chosen account, is resolved using the ConnectServer method of sWbemLocator class (line 19). The ConnectServer method allows the user to specify alternate credentials (a name in the format domain\username and a corresponding password, set on lines 16 and 17, respectively). The second obstacle is that the method uses Kerberos authentication (rather than default NTLM). The reason for it, as explained in great detail in this of the Microsoft Knowledge Base articles, is that connecting to the third computer (in our case, Computer C) requires delegation, which is not available when authenticating via NTLM. The delegation is chosen by setting ImpersonationLevel value to 4 (line 20).

On line 21, we assign Shutdown privilege to the process that will be running on Computer B (this way, patch installation can be followed with restart). The command line to be executed is specified on line 14 (for typical syntax of patch installation, refer to Summary of Command-Line Syntax for Software Updates, a Microsoft Knowledge Base article. Obviously, computer names, domains, user credentials, and patch paths must be modified to match the environment.

Configuring computer and user accounts
In addition to creating the script, you must also configure computer and user accounts involved in the patch installation, so they can participate in the delegation. Relevant settings are configurable via Active Directory Users and Computers. After the utility is launched, locate the account of Computer B and select "Trust this computer for delegation" option from the Properties dialog box (this setting is on the General tab in the Windows 2000 version of the tool and on the Delegation tab when working with Windows 2003 domains). You must also ensure that the user account used for installation is delegated (this option exists in the Account Options area of Account tab of the user account properties in Active Directory Users and Computers).

The main problem with this approach is that it is limited to Windows 2000 or 2003 domains and Windows 2000 or later computers (it is not supported on Windows NT 4.0 systems and in NT 4.0 domains). In addition, assigning delegation privileges is considered to be a potential vulnerability.

Several workarounds are available to overcome these limitations:

Copy patches to a specific location on target computers that must be patched. You can do this by running a separate, simple script prior to invoking the second one. If a folder where users have write privileges is chosen, files can also be distributed as part of a logon script. This way, you no longer depend on Kerberos and delegation, and instead default back to NTLM and impersonation settings. Effectively, line 19 of the script would change to:

Line 14 would also change to a local path. Since NTLM and impersonation work fine in a Windows NT 4.0 environment, none of the limitations described above would apply. A similar approach is presented in the Microsoft Knowledge Base Article - 827227, which describes how to use a Visual Basic script to install the 824146 (MS03-039) or 823980 (MS03-026) security patches (a script included in the article is modifiable to allow deployment of other patches).

If copying patches to remote computers does not seem a viable solution, drive mapping can be included as part of the original script. The script would map a drive to a share on the Computer C, where patch files are located, using specified credentials (we do NOT recommend hardcoding them into the script, but rather providing them as input arguments when executing the script from the Command Prompt). This way, a connection to the Computer C is established in the security context of the existing drive mapping.

An even simpler option is to download the PSExec utility from the SysInternals Web site. PSExec is launched from the computer where a patch is stored, which would result in the patch file being copied to remote system for execution with specified options. After the installation completes, the file is automatically deleted from the remote computer.

The next article in this series will continue our exploration of free solutions.