Windows Patch Management, the Free Way - Page 2

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.

 By Marcin Policht
Page 2 of 2   |  Back to Page 1
Print Article

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:

  1. 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:
    	Set oWMISvc	= oLocator.ConnectServer(sComputerB, "root\cimv2", _ 
    			sDomain & "\" & sUserName, sPassword)

    and line 20 to:

    	oWMISvc.Security_.ImpersonationLevel = 3

    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).

  2. 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.
  3. 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.

Article courtesy of ServerWatch

» See All Articles by Columnist Marcin Policht

This article was originally published on Feb 3, 2004
Get the Latest Scoop with Networking Update Newsletter