By Peter Pawlak [Bio]
Posted: Apr. 22, 2002

• Illustration: Software Update Service Flowchart
• Illustration: The SUS Web Interface
• Sidebar: What is "BITS"
• Illustration: SUS Architectural Scenarios

Microsoft’s Software Update Service (SUS) provides an automated means to distribute and install critical operating system (OS) fixes and security rollups on Windows 2000 and later workstations and servers. Part of Microsoft's Strategic Technology Protection Program and formerly known as Windows Update Corporate Edition, this free Windows 2000 Server-based product is currently in beta testing and due out by the end of June 2002. Though much less capable than full-featured software distribution products such as Microsoft’s Systems Management Server, SUS is relatively inexpensive to deploy and contains the core set of features many IT departments will need to consistently patch machines before hackers have a chance to exploit newly discovered OS vulnerabilities.

The Need for Automated Patch Distribution

The Code Red virus illustrated that typical combinations of firewalls and virus-scanning software cannot completely protect organizations against certain types of malicious attacks. In particular, protecting against buffer-overflow vulnerabilities can be accomplished only by correcting the flawed code and installing patches containing the corrected code on all affected systems. (For more information on Code Red and Microsoft’s response to it, see "Get Secure, Stay Secure" on page 17 of the Dec. 2001 Update and "Secure Windows Initiative to Tackle Security Vulnerabilities" on page 13 of the Aug. 2001 Update.)

In the case of Code Red, Microsoft had posted patches correcting the vulnerability nearly a month beforehand. So why were so many systems affected? The problem lies with the sheer logistics of installing the needed patches correctly on servers and workstations that often number in the thousands and are geographically dispersed. Making matters worse, Microsoft issues so many fixes: For example, from Jan. through Mar. 2002, Microsoft issued 15 security bulletins, most of which involved some form of patch to existing software.

To distribute these security and other software patches, organizations typically resort to some combination of four basic strategies, none of which is perfect:

Do nothing. Some organizations install only well-tested standard software configurations on workstations (and occasionally even on servers) and then never change them until it is time to update all systems with new software. This approach leaves the organization exposed to vulnerabilities that are discovered and exploited after the computer has been put into production.

Manually install the patches. An IT administrator can go around to each computer and manually install the patches, but the costs of hiring enough administrators to do this in a timely manner, even on just their servers, is prohibitive for most organizations. The problem is even worse when administrators must travel to install patches on remote computers.

Allow end users to patch their workstations. Windows Update makes it much easier for end users to keep their systems current with Microsoft’s latest critical fixes, and the Windows 2000 Critical Update Notification service or the Windows XP Automatic Update service will even alert users when an update is needed. However, installing the patches requires end users to have local administrative privileges on their computers. Although this requirement was normal on the Windows 9x OS, most organizations using Windows NT, Windows 2000, or Windows XP desktops do not grant local administrative privileges to end users, primarily because it's cheaper to support workstations that have standardized and locked-down configurations. Furthermore, even when end users have administrative rights, there is no way to ensure that all users will update their workstations correctly and only when instructed. For this reason, many organizations completely block Windows Update access to end users.

Use a software distribution product. Products like Microsoft’s Systems Management Server (SMS) are ideal for this task, but they are complex and expensive and require skilled personnel to package and target the patches at the desired systems. Although organizations running Windows 2000 and Active Directory can use Microsoft’s Intellimirror technology and the Windows Installer service to install application software packages and patches of those applications, this method does not work for patches to the OS because the Windows Installer can update only software originally installed as a Windows Installer package, and the OS does not use Windows Installer during its installation.

No matter what method they use, most organizations will want to test the patches on representative systems before installing them on workstations or servers. In the past, Microsoft has issued patches and service packs that broke existing functionality, or even introduced new vulnerabilities.

The Software Update Service Solution

Windows Software Update Service (SUS) is a free, albeit limited, software distribution product designed exclusively to automate Microsoft OS patch and service pack maintenance for Windows 2000 (and later) servers and workstations. SUS is granular enough to allow administrators to specify which Windows Update packages (containing individual patches or security rollups) are made available to client systems and whether the clients automatically install the packages or just download them for manual installation later by someone with administrative privileges. (However, SUS is not granular enough to distribute different sets of patches to each client.)

With SUS, an organization could potentially install a patch on every Windows 2000 or later system within two days after the patch was posted on the Microsoft Windows Update site. When SUS is running in automatic installation mode, end users do not need local administrative privileges on their computers or to take any active role; SUS takes care of the installation in the background. However, an organization can still test the packages first and approve only those it wants to distribute.

SUS is not Microsoft’s first attempt to overcome the shortcomings of Windows Update, particularly for corporations. In 2000, Microsoft created a Windows Update Corporate Web site that allowed administrators to locate and download patches without installing them on a system. (See "Windows Update Corporate Site Goes Live" on page 14 of the Oct. 2000 Update.) However, this solution suffered from two problems: Administrators had to proactively discover when a patch was available and manually download it. It assumed that organizations had software distribution technology, such as SMS, so it provided no tools for getting the patches onto the target computers.

How SUS Works

SUS consists of server components and a client-side "agent" service that can run on both servers and workstations. (See "Software Update Service Flowchart" for a graphical overview of the SUS update process.)

SUS Server

The SUS server consists of a new service, based on Internet Information Server (IIS), that runs inside an organization’s firewall and synchronizes daily with the Microsoft Windows Update site, downloads content packages, and publishes those packages to client workstations and servers or to subordinate SUS servers.

Each SUS package consists of a localized version of an OS patch or security rollup and takes the form of an executable (.EXE) file and possibly one or more cabinet (.CAB) files. Microsoft digitally signs each package, and the SUS server will download only those that it verifies as authentic.

In addition to the packages themselves, SUS downloads metadata—an XML file that contains information on all the available packages, such as descriptions, applicability rules (i.e., what OSs they are for and other dependencies), and whether a reboot is required.

The SUS server logs its activity to a file and can notify administrators via e-mail when new packages arrive.

SUS also provides a Web interface that allows administrators to:

• Approve the packages they want to publish
• Configure periodic synchronization settings or trigger immediate synchronization
• Configure the "locales" (localized versions of the packages) they want to download
• View synchronization and approval logs.

(See "The SUS Web Interface" for a screen shot of the SUS administrative interface.)

SUS also can function as a status server, accepting status information posted by its client computers and rolling these messages into a single IIS log (separate from the SUS server’s own log). Organizations can opt to deploy SUS status servers separately from SUS package-distribution servers.

Automatic Update Client

The SUS client is based on an update to the Automatic Update (AU) agent service that first shipped with Windows XP. Windows XP’s AU can be configured to automatically retrieve critical updates, but a local administrator still must install these updates. The AU agent uses Windows XP’s new Background Intelligent Transfer Service (BITS) to download new packages from a Microsoft Windows Update site using a daily schedule randomized between 17 and 22 hours (so that all clients do not hit the SUS server at the same time). BITS makes the package download process much more tolerant of interruptions and limited network bandwidth. (For more information about BITS, see the sidebar "What is "BITS"".)

The SUS AU client service has all the capabilities of its predecessor, but has a new option that enables it to install update packages in the background using local system privileges.

Furthermore, the SUS AU client can be configured to get all new packages applicable to the version of OS and other related services running on the local computer in one of three different ways:

• Get the applicable packages from a specified SUS server
• Get the list of approved packages from a SUS server, but go to a Microsoft Windows Update site to get the applicable packages
• Get all available and applicable packages from a Microsoft Windows Update site (and not use a SUS server).

After the packages have been downloaded to a target computer running in automatic installation mode, pop-up warning messages will appear five minutes before the scheduled installation time, giving users with local administrative privileges the option to defer installation until later. If a reboot is requested by the package, the administrator gets another notification and can also defer the reboot. Users without local administrator privileges see little; everything happens in the background and users are only warned that the computer is about to shut down and restart, so they should save their work and log off. Non-administrative users cannot defer the reboot.

If a computer is turned off before a download is complete, it resumes downloading after being turned back on and installs new packages at the next scheduled time.

When AU must install multiple packages, each of which requires a reboot, the AU automatically uses Microsoft’s QCHAIN utility to install them sequentially and reboots once after the last package has been installed.

In the case of servers or other machines on which administrators do not want the packages to be automatically installed, AU provides an option that automatically downloads packages but requires an administrator’s intervention to install them.

The AU client logs its activities to the local Windows event log and can also be configured to forward events to a SUS status server. Logged events include Unable to Connect, Install Ready, Install Success, Install Failure, and Restart Required. Since SUS has no status-monitoring console, the log is only useful for troubleshooting problems after the fact.

AutoUpdate Configuration

Although users who have local administrator privileges can configure the settings of the new AU client, most organizations will want to centrally manage these settings. An organization using Active Directory can use Group Policy to control the settings. An organization still using Windows NT 4.0 domain controllers can use Windows NT system policies or directly edit the Registry settings of each computer. (Group Policy settings override any local settings.)

The SUS policy settings allow administrators to control the following:

• Whether AU automatically installs packages or just fetches them and notifies logged-on administrators
• When automatic installs will occur
• The URL path of the SUS server
• The URL path of the SUS status server
• Whether the normal Windows Update is hidden from users.

By creating different policies with different settings, administrators can point machines at the appropriate SUS servers and use installation modes appropriate to each machine's needs. For instance, an organization would normally not want servers that are always in use to automatically reboot themselves, so these machines would be configured to only download the packages.

Scaling SUS for Larger Organizations

Large organizations or organizations with WANs might have requirements that cannot be met by a single central SUS server. For example, these organizations might need more capacity than one server can provide or might not want numerous clients downloading the same packages across WAN links simultaneously. Fortunately, SUS can be configured in several different architectures to meet these requirements. (For a graphical overview, see the illustration "SUS Architectural Scenarios".)

Fan-out architecture. Organizations with large numbers of AU clients might be tempted to distribute the workload by using Application Center Server to host a farm of SUS servers. However, SUS does not support this configuration and, even if it did, it would not address the WAN bandwidth issue. Therefore, the best way to service large numbers of clients is to construct a hierarchical SUS system consisting of multiple "child" SUS servers that download approved packages from a single "parent" SUS server. By applying different Group Policies—each having a different SUS server address—to groups of clients, the workload can be spread across the child servers. Geographically distributed organizations can place a child server at each remote site and then point all clients at that site to a local child SUS server so that each package needs to transit the WAN connection only once (from parent to child) rather than many times (from a central SUS server to multiple clients at the remote location).

Direct Internet download architecture. When geographically distributed organizations have a firewall and direct Internet connectivity at each remote site, SUS can scale by exploiting Microsoft’s worldwide network of Windows Update sites. In these cases, each AU client at each site can be configured to get its list of approved packages from the organization’s central SUS server but then download the packages directly from a Windows Update server via the Internet. Thus, each client does not burden a private WAN link by downloading the packages from the central site. SUS can also take advantage of caching proxy servers to reduce the impact on the Internet link.

Not an SMS Replacement

Although SUS will be attractive to many organizations, it has several limitations and is not a substitute for more capable solutions, such as SMS.

Status reporting. The SMS console or a monitor based on Microsoft Operations Manager will alert system administrators when packages fail to install properly. With SUS, someone must manually parse a large IIS log to spot such problems.

Targeting. SMS can target packages at machines based on nearly any selection criteria, such as rolling out a patch to just a single site to make sure that the whole organization isn’t affected if a problem occurs. SUS packages are automatically targeted at all computers whose agents are configured for that SUS server.

Types of packages. SUS (at least in the first release) can distribute only Microsoft-signed, critical OS patches or security rollups. SUS cannot install service packs or handle Office Update patches, driver updates, or other noncritical patches, such as normal updates to Windows Messenger or Media Player. SMS can distribute any type of software from any vendor, including software created internally. It can even update device drivers.

Rollbacks. SUS has no mechanism to centrally force a rollback if problems occur after a patch has been applied (although the patches can be manually rolled back using the computer’s "Add/Remove Programs" Control Panel utility). As long as the client has not lost contact with the network, SMS administrators can roll back any SMS package (as long as the package itself was designed to support rollbacks).

Bandwidth management. Organizations implementing a multitier SUS system with child servers located across low-bandwidth links have no capability to throttle SUS file transfers over the link, although they can schedule the time of day when the transfer occurs. SMS has more scheduling options and can even manage the network utilization of package distribution traffic to its child sites.

Organizations already using SMS will also find that there is no integration between SMS and SUS or Windows Update. However, the upcoming SMS Value Pack (available later this year) will include a wizard that will allow SMS to download and publish critical update packages from Windows Update just as easily as with SUS.

Other SUS Limitations

In addition to its shortcomings compared with SMS, SUS has other limitations:

Reboots could affect logged-on users. SUS assumes that a client computer can automatically install packages when nobody is actively using it. However, this assumption may be problematic in two ways. First, some organizations have computers that are always in use—in airports, parcel services, or factory floors, for example. A forced reboot could cause a worker to lose data, and non-administrative users have no way to postpone the reboot. Second, users sometimes leave applications open on a workstation when leaving for the night (not advisable, but common in practice). AU-forced reboots could cause the loss or corruption of unsaved data.

SUS does not properly handle server farms. Unlike Microsoft’s Application Center Server product, SUS does not explicitly deal with patch maintenance of server farms. If a farm of servers used the same AutoUpdate policy and a patch triggered a reboot or service restart, all of them could go offline at the same time. Ideally, organizations need an update method that allows server farms to automatically install packages one server at a time by "draining off" users, performing the update, rebooting, rejoining the farm, and then triggering the next server’s update.

Laptops could be affected. Apart from BITS’ ability to throttle its bandwidth use and restart file transfers from the point where it left off, SUS has no provisions for dealing with laptops used offline or which roam to various places on the network. The AU client is not location-aware, and it will always try to connect with the SUS server specified in its configuration settings rather than the closest one.

Package approval is an all-or-nothing proposition. Unless an organization maintains completely separate SUS systems, package approval and distribution is an enterprisewide action. Although each AU agent will retrieve and install only applicable packages (i.e., the local system meets the package’s system requirements), a package cannot be marked for distribution to a single site or to a subset of computers. Organizations might need to create extensive test facilities to be certain that a package has no ill effects on representative test systems before approving a package for distribution.

System Requirements and Resources

When SUS is released, it may be freely downloaded from Microsoft’s Web site. The SUS server requires Windows 2000 Server Service Pack (SP) 2 or later, running IIS. SUS will also be included with Windows 2000 Server SP3.

AU clients must be running Windows 2000 or later. Windows XP clients running the standard AU client or Windows 2000 systems running the Critical Update Notification service will be able to get the new AU client directly from Windows Update, although someone with local administrative rights will still be required to install it. A regular Windows Installer package will also be available. Windows 2000 SP3 or Windows XP SP1 will also install the new AU service.

For more information on SUS, see www.microsoft.com/technet/treeview/default.asp?url=/TechNet/ittasks/support/corpwu.asp.

For more information on BITS, see msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/drzportal_06xx.asp.

For more information on SMS, see "SMS 2.0 Ships" on page 3 of the Mar. 1999 Update.