The first article in the Windows Patch Management seriesprovided 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.
Two registry locations contain relevant information:
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.
1 Dim sComputerB '-- name of computer to be patched 2 Dim sComputerC '-- name of computer where patch executable is located 3 Dim sDomain '-- domain where computers are located 4 Dim sPatchExe '-- full path to the patch executable 5 Dim sTempDir '-- working directory on the Computer B 6 Dim oLocator '-- object representing SWbemLocator class 7 Dim oWMISvc '-- object representing SWbemService class 8 Dim oProcess '-- object representing Win32_Process class 9 Dim iResult '-- integer indicating outcome of process creation 10 Dim iPID '-- integer indicating PID of the created process 11 sDomain = "ServerWatch" 12 sComputerB = "ComputerB" 13 sComputerC = "ComputerC" 14 sPatchExe = "\\" & sComputerC &"\Patches$\q123456_w2k_sp2_x86_en.exe /q" 15 sTempDir = "%TEMP%" 16 sUserName = "InstallAdmin" 17 sPassword = "$w0rdF1sh" 18 Set oLocator = CreateObject("WbemScripting.SWbemLocator") 19 Set oWMISvc = oLocator.ConnectServer(sComputerB, "root\cimv2", _ sDomain & "\" & sUserName, sPassword,, _ "kerberos:" & sDomain & "\" & sComputerB) '-- Delegate impersonation level 20 oWMISvc.Security_.ImpersonationLevel = 4 '-- SeShutdown privilege 21 oWMISvc.Security_.Privileges.Add 18 22 Set oProcess = oWMIService.Get("Win32_Process") 23 iResult = oProcess.Create(sPatchExe, sTempDir,, iPID) 24 If iResult = 0 Then 25 WScript.Echo "Process creation succeeded" 26 WScript.Echo "New Process ID is " & iPID 27 Else 28 WScript.Echo "Process creation failed with return value " & iResult 29 End If
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.