Windows Patch Management, Software Update Services (Part 2)

Friday Apr 23rd 2004 by Marcin Policht

Microsoft's SUS tool is designed to enable a highly customized deployment infrastructure by facilitating patch selectivity. We complete our coverage of SUS with a look at client settings, advanced configuration options, and future plans.

The previous article in this series began our discussion of Software Update Services. SUS is a free patch deployment solution from Microsoft that also offers limited auditing/inventory capabilities. "Windows Patch Management, Software Update Services (Part 1)" discussed the basic principles of SUS' operations: installation, configuration, and basic administration procedures. Part 2 completes our coverage of SUS solutions with a description of client settings, more advanced configuration options, and Microsoft's plans for future versions of SUS.

Installation of SUS Client Software

SUS 1.0 SP1 clients must have the latest version of Automatic Update component (downloadable from http://www.microsoft.com/Windows2000/downloads/recommended/susclient/download.asp). This updated version is required only for systems running Windows 2000 with SP2 or Windows XP without SP1 (newer service packs and Windows 2003 Server systems have the newer version built in). Since the software is provided in the form of the Windows Installer package (*.MSI file), it is deployable using Group Policies.

Configuration of SUS client software

Remote configuration of SUS clients can be accomplished via group policies and direct registry changes (in a non-Active-Directory environment). Note that since SUS clients employ the same mechanism as Windows Updates (with a few additional configuration options), we covered the majority of relevant settings in the second article of this series.

In short, the Group-Policy-based method involves modifying entries stored in the WUAU.ADM administrative template, the most recent version of which has been released with SUS SP1 and is available for download from the Microsoft Web site at http://www.microsoft.com/downloads/details.aspx?FamilyId=D26A0AEA-D274-42E6-8025-8C667B4C94E9&displaylang=en. The template is intended for Windows 2000 SP 2 and XP systems. (It is already included with the administrative templates bundled with Windows 2003 Server.) Once it is added, via the Add/Remove Templates option in the Computer Configuration section of the Group Policy Editor MMC snap-in for the Group Policy Objects linked to the relevant Active Directory container (the one containing target clients that will be receiving patch updates from SUS servers), the Windows Update node appears in the Administrative Templates -> Windows Components subfolder.

Besides the generic Windows Update settings described in the previous article and mentioned above, there is a single entry labeled "Specify intranet Microsoft update service location," which plays an essential role in the SUS client configuration. From here, you would specify the URL paths to your SUS server (from which clients download approved patches) and intranet statistics server (to which clients upload information describing their patch download and installation status). These names must match the ones specified on the SUS Admin Web page under the "Set options" entry.

In case you cannot configure your clients via group policies (limitations of non-AD environments), you can accomplish your goal via registry changes. The SUS-related settings reside in the HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registry key. The WUServer entry contains a URL path to a SUS server, and WUStatusServer points to an SUS statistics server (both entries are of REG_SZ data type). They correspond to two entries in the WUAU.ADM template, referenced in the previous paragraph. Remaining settings reside in the AU subkey of the HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate key and include UseWUServer entry (REG_DWORD data type), which can take the value of 0 (indicating use of Windows Update) or 1 (instructing the client computer to pull updates from a SUS server).

Typically, an SUS server is used as the source of patches for other SUS servers, although this is by no means a requirement. Creating a non-SUS, manually configured distribution point might be useful in situations where a remote site without direct Internet connectivity is separated from the main office by a slow WAN link. In this case, you can copy updates from an SUS server at the main office to a removable media, ship them to the remote site, and restore them to their local distribution point. To accomplish this, two servers are needed -- the first one would have the SUS server software installed (functioning as the source of update files) and another one would serve as the distribution point. Both of them must run Internet Information Server 5.0 (or later) listening on TCP port 80 (default).


  1. On the distribution server, with help of Internet Information Services Manager console, create a folder called Content (its location is not relevant, although you should pick a fast, lightly used drive with ample free space available), a subfolder called cabs, and a virtual directory called Content that points to the cabs subfolder (SUS server creates this structure automatically during installation).
  2. Copy all files from the cabs folder on the SUS server to cabs folder at the distribution point.
  3. Copy autocatalog1.cab, aurtf1.cab, and approveditems.txt from the root of the SUS Web site on the SUS servers to the root of the Web site on the distribution point. (This process will need to be repeated each time a new update for internal redistribution to client computers is approved.)
  4. Finally, point the target SUS servers to the Web site on the distribution server as the source of patch updates (using the option available after selecting the "Set options" on the SUS main Web page).

>> NLB Clustering; The Future of SUS

For larger environments, consider setting up the SUS servers distributing patches to clients in a Network Load Balancing (NLB) cluster. NLB is a component included in the Windows 2000 Advanced Server and Datacenter Editions as well as all versions of Windows 2003 Server. The basic purpose of NLB clustering is to provide redundancy and load balancing by presenting a group of servers as a single logical unit. This is done by distributing incoming network traffic across all members of NLB cluster and assigning each with parameters that determine which node should process next network packet (for additional information on NLB solutions, refer to this overview of Windows Clustering Technologies found on the Microsoft Web site). An NLB cluster is represented to client computers by a single IP address, and clients requests for patch downloads are transparently load balanced to them across all members.

This provides several benefits. First, since clients are configured with the name of the NLB cluster, rather than with an individual server name, as long as at least one member of the cluster remains operational critical updates are delivered. This means you can shut down any of the cluster members servers for maintenance or emergencies without affecting the overall functionality. It also means you can add another server to the cluster without reconfiguring clients, since the servers always point to a single virtual IP address assigned to the cluster. In the NLB cluster-based SUS scenario, you would typically set up a single source of updates for each cluster member (this can be a parent SUS server pulling patches directly from Microsoft Windows Update Web site or a manually configured distribution point).

The Future of SUS

Instead of releasing the next version of SUS (initially planned as SUS 2.0), Microsoft decided to rebrand its product Windows Update Services (creating a rather tough-to-promote acronym). WUS is scheduled to enter an open evaluation program later this year, and you can participate in it by registering at the WUS web site. The Web site offers some preliminary information on the functionality of the current beta version, as well as an indication of changes to be introduced before final release.

In short, the new incarnation of the product will feature several important improvements, including the following:

  • Updates for additional products (besides Windows operating systems) such as MS Office XP and 2003, MSDE 2000, SQL 2000, Exchange 2003 Server, and critical driver updates.

  • Extended management capabilities that allow missing identifying patches and the systems to which these patches must be applied. Control over the managed environment will be more granular, providing the ability to create deployment groups to be targeted by specific patches, modify client update frequency, and set the dates by which the update should be completed (this effectively enforces installation by that date, preceded by a notification about the impending reboot to a logged on user). It will also be possible to rollback patches. On the client side, the number of reboots will be minimized by eliminating them altogether (for patches that do not require them) or by linking the installation of multiple patches into one, followed by a single reboot. On Windows XP SP2 systems, Microsoft will offer to defer reboots to the next regular, user-initiated shutdown. Centralized management of the SUS server hierarchy is possible by enabling or disabling inheritance of configuration settings by child servers from their parents.

  • More comprehensive and administration-friendly reporting capabilities, including inventorying missing updates across groups of computers, with detailed information about operations involving clients (downloads and installations) or downstream servers (in more complex SUS hierarchies). You then have the option of creating reports for the entire hierarchy of SUS servers, since the statistics will be propagated from child servers to their parents. It will also be possible to load reporting data into SQL Server (or MSDE) for simplified retrieval and more robust storage.

  • Optimized utilization of network bandwidth based on Background Intelligent Transfer Service (BITS) and Windows Installer technologies. This makes it possible for interrupted downloads to be continued after connectivity is re-established (rather than starting it from the beginning), use only the available portion of the bandwidth to prevent a negative impact on other network applications, and reduce the size of downloads with delta updates and improved compression. In addition, you will be able to selectively download only those updates that are of interest or even a list of updates only (to select the ones which should be copied by your clients directly from the Microsoft Update Web servers). This was not possible with previous versions of SUS, which required the download of the full collection of patches for the language versions selected, regardless of how many were approved for further deployment.

  • Increased security uses encrypted inter-server and client-server communication and offers the ability to validate the identity of the parent SUS server.

This completes our review of the Microsoft Software Update Services. The next article in our series will look at Microsoft's enterprise-class solution for patch management: SUS Feature Pack for Systems Management Server 2.0 and Systems Management Server 2003.

Mobile Site | Full Site