By Peter Pawlak [bio]
Posted: Jan. 24, 2005

• Illustration: Windows Update Services Architecture
• Illustration: Patch Management Terminology Changes
• Chart: How Do WUS and SMS Compare?

The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.

Centralized Software Update Management

Most organizations today recognize that one of the most important elements of a defense against computer attacks and viruses is to patch software vulnerabilities before exploits ever appear. However, this is not a simple task, and maintaining a Windows PC today includes patching and updating many applications and components beyond those of the core OS, such as Internet Explorer (IE), Office, Windows Media Player, SQL Server (including the desktop version, Microsoft SQL Desktop Engine, or MSDE), and Exchange. Organizations need to know that their software has all the latest software updates, yet realize they can’t depend on users to be proactive about keeping their machines updated.

For consumers who are aware of the threats and want to stay current with Windows OS patches and other updates, the Windows Update Web site has made this task considerably easier by providing a single preconfigured point to get updates, and a scanner that tells users what updates they need to be current. Moreover, the combination of the Windows Update Web service with the Automatic Update (AU) client-side agent (which accompanied the release of Windows XP and was back-ported to Windows 2000) improved the situation even more by providing an option to automatically grab and install all applicable critical Windows updates without user intervention.

However, this solution has several shortcomings that make it inadequate for organizations, namely:

• It installs critical Windows updates only and misses critical updates for many other Microsoft and third-party applications
• There’s no centralized way for IT staff to determine that the process is working properly and that PCs are up-to-date
• Since software updates are applied automatically, there’s no way to first test them to make sure they won’t cause problems
• It’s designed for interaction with logged-on users, which creates problems with controlling server reboots.

Microsoft recognized these problems years ago and has produced two solutions aimed at resolving most of them: SMS 2003 and SUS.

SMS 2003. SMS consists of a server infrastructure and agents on each managed computer that enable organizations to inventory and manage hardware and software assets, distribute software, apply software updates, track licenses, and remotely diagnose and fix problems on Windows clients, servers, and Windows Mobile devices. Mainly aimed at medium and large organizations, it addresses all of the above needs and provides most of the tools needed to keep their PCs at current update levels, but it is complex to deploy and operate, and involves significant license fees.

SUS. For a variety of reasons, SMS may be deemed inappropriate by some organizations. In 2002, Microsoft introduced SUS as a free feature pack for Windows Server to help those organizations keep their Windows PCs patched. SUS is an intermediate server product that sits between computers running the AU agent and the Windows Update Web service, and conceptually brings a subset of the Windows Update site inside the organization’s firewall. By allowing system administrators to approve software updates before publishing them to the AU agents, SUS provides a limited degree of centralized software update management for organizations that have at least one dedicated IT person or a service provider to maintain their systems.

However, SUS 1.0 was saddled with several serious shortcomings that left customers wanting more. Most importantly, it had no real facility for status reporting and did not support "targeting," meaning that administrators could only globally approve software updates for all clients configured to use the SUS server and could not restrict it to a subset of computers, such as those used for testing prior to widespread software update deployment. Furthermore, SUS was encumbered with a limitation of the Windows Update site: it was primarily aimed at Windows and IE software updates, and it had no support for updating Office and many other popular Microsoft applications.

To resolve these shortcomings, Microsoft is upgrading both SUS and the Windows Update Web service. The successors, named WUS and Microsoft Update, respectively, are currently in beta, with release targeted for the first half of 2005.

WUS—What’s New?

Although the overall solution does not depart from the architectural approach taken by SUS, all three parts—the server, the client-side agent, and the Web service—have been upgraded with new capabilities. However, name changes made by Microsoft strictly for marketing and branding reasons may cause some customer confusion. SUS’s name implied that it could update more than just the Windows OS, but it actually updated only Windows. Now Microsoft is changing the name to something that sounds like it updates only Windows—Windows Update Services—when in fact it updates other Microsoft products as well. The old AU agent gets renamed the Windows Update (WU) agent, but it updates more than Windows components. Furthermore, the new server name can easily be confused with the current Windows Update site and its associated Web service, which will be renamed Microsoft Update (which makes sense semantically in that the scope of the site has changed to include all Microsoft products). (For a comparison of the old and new terms, see the illustration "Patch Management Terminology Changes". For a physical view of how the components fit into the overall solution, see "Windows Update Services Architecture".)

Server Changes

WUS is a complete rewrite of SUS and, while the basic function it provides is the same, its implementation details have changed significantly.

Unlike SUS, which was an Active Server Page (ASP)-based application, WUS is an ASP.NET application that stores its configuration information and approval details in an MSDE database bundled with the product, although organizations can use a local or remote SQL Server 2000 database if they so choose. WUS runs on either Windows 2000 Server SP4 with the .NET Framework or on 32-bit versions of Windows Server 2003.

This new architecture helped Microsoft build a substantially better administrative user interface that is easier to localize (the initial release will support 17 different languages) and supports a managed API and SDK that allows developers to integrate other third-party applications, such as patch-compliance auditing tools and products that e-mail notifications to administrators when new updates are available.

WUS’s major new feature areas include the following:

Reporting. Although SUS logged download and installation operations to raw Internet Information Services (IIS) logs, it provided no reporting tools to parse and analyze them. WUS helps administrators monitor the system by providing a status-reporting feature that allows administrators to see which software updates are required by each managed computer and which are installed. Administrators who are troubleshooting their patching systems can even get more granular status information on each managed computer, such as its update download status and whether a reboot is pending. However, they cannot get summary reports of the software update status of the organization as a whole, and WUS’s reports cannot be published to an intranet site for viewing by non-administrators, making it difficult to make status information available to help-desk personnel or managers without installing third-party add-ons.

Like SUS, WUS servers can be configured as a hierarchy to provide better performance in WAN topologies and to provide greater scalability, but status information does not flow up to the parent WUS server. In organizations with multiple WUS servers, administrators cannot get a single, centralized report on the overall system and instead must manually connect to multiple WUS servers to get this information. Sample scripts will be provided at the time WUS is shipped to show administrators how to automate the process of exporting reporting data and aggregate it for centralized reports. However, this functionality will not be integrated in the base product.

By the time WUS ships, Microsoft has also committed to supply a Microsoft Operations Manager 2005 management pack that will make it possible to centrally monitor the health and performance of multiple WUS servers.

Targeting. Unlike SUS, WUS provides a means of approving software updates for subsets of computers through the use of WUS-defined computer groups. This feature is particularly useful for testing, when an administrator wants to limit software update installations to a set of test computers. It also provides a manual method to segregate servers from workstations, where update approval settings would typically be different.

However, unlike SMS, WUS’s targeting system is fairly primitive. It does not make use of Active Directory computer groups, and a computer can belong to only one WUS group at a time. WUS group assignments are also not dynamic—based on some property of the client, such as whether it is a server or a workstation. Instead, administrators must manually assign computers to a group from the WUS server, or use Group Policy, local policies, or Registry edits to configure the group name on the WU agent.

More flexible approvals and publishing options. While SUS’s approval mechanism was a simple checkbox for each software update that would trigger installation on all applicable computers pointed at that SUS server, WUS supports multiple approval options. For instance, in addition to the targeting groups discussed previously, administrators can mark an update as "detect only," which retrieves a listing of the computers for which the software update is applicable without installing it. They can also mark it to "install with a deadline," which downloads the software updates to the WU agent and gives users the option to install them at their convenience up to the deadline date, after which the agent automatically installs them. WUS administrators can also trigger a rollback of any installed software update that was developed to support a rollback option (at some time in the future Microsoft plans to make all software updates reversible). Administrators can also automatically decline updates that have been superseded by newer updates, thereby making approvals simpler. Lastly, organizations can filter the types of software updates and platforms they want to support through WUS, helping them to more easily control storage and network requirements and reduce the size of the list of updates they have to examine. For instance, if they have no Windows 2000 systems in their organization, they can avoid the overhead associated with Windows 2000 software updates that will never be used.

Support for disconnected networks. Organizations with remote offices that are not connected to each other or to the Internet by a high-bandwidth WAN can use removable disks, such as CDs or DVDs, to transfer approval data and downloaded software update files from their central WUS server to a WUS server at a remote site. However, this process requires several manual steps to export the data from the source WUS server and to import it on the remote WUS server and is not intended as a means to create a software update CD for a home office worker. But it's still an improvement over SUS, which did not support this scenario at all.

Client Agent Changes

The WU agent for computers running Windows 2000 SP4 and above is a background service that connects to the WUS server, retrieves any new software update applicability data, scans the local file system and Registry to see what software updates are needed, downloads approved software updates from the WUS server, installs the software updates using whatever installer technology each software update calls for, sends status information back to the WUS server, and triggers reboots if needed. As with SUS, administrators have the option to configure clients to get applicability and approval data from WUS, but then download the update files directly from Microsoft, a capability useful in scenarios where clients have good Internet connection bandwidth but limited bandwidth between them and their WUS servers.

Both the current Windows Update site and WUS will upgrade all computers configured to use it to Version 5 of the agent (which also is installed by Windows XP SP2). This new WU agent includes several features that make updating more robust while reducing network usage:

Binary delta compression and BITS 2.0. Rather than download complete replacements of the files needed for a software update, the WU agent supports binary delta compression, which lets clients download only the parts of each file that have changed and then merge those new parts into the existing files. This dramatically reduces network traffic between WU agents and the file source, whether it’s Microsoft or a WUS server. Because each client is requesting less data, the server can service more clients at once.

However, there is a trade-off when using binary delta compression with WUS: the source files, called "express installation files," are roughly three times the size of traditional software updates. Consequently, local storage requirements are larger and the link between each WUS server and its upstream data source (Microsoft or another WUS server) is hit with increased file transfer traffic.

Binary delta compression requires Version 2.0 of the Background Intelligent Transfer Service (BITS), which is installed by either Windows XP SP2, Windows Update, or the WUS server. BITS is a file transfer technology based on the Hypertext Transfer Protocol (HTTP) that uses a "checkpoint" mechanism that allows an interrupted file transfer to resume where it left off, even if the user becomes disconnected from the network. This mechanism also allows BITS to adjust its network use based on other network adapter activity, making it well-suited for downloading software update files in the background, especially for remote users with low network bandwidth and intermittent connectivity.

Windows Installer 3.0 support. If not already present on each managed computer, the new WU agent installs Windows Installer 3.0 (also known incorrectly as Microsoft Installer, or MSI) and depends on it for updating all applications installed with Windows Installer. Windows Installer 3.0 supports update rollback, enables application developers to ship smaller patch files, installs the updates in the proper sequence, and eliminates the need for original installation media, which has sometimes plagued attempts to automate patching of MSI-based applications. (See "New Installer Supports Security Push" on page 9 of the Oct. 2004 Update.)

The new WU agent also provides a lot more control over how often the client checks for updates, provides an option to install updates only upon system shutdown (which helps keep users from being affected by the installation process), and allows administrators to set how much time a user has before mandatory reboots will occur. However, all these settings options are per-machine and are not controllable on a per-update basis.

Although these WU agent-side improvements decrease bandwidth requirements and download times, the client is still pointed at a single software update source, whether Microsoft or a WUS server. While this arrangement is fine for fixed workstations and servers, it is not ideal for roaming laptop users, because WU cannot identify the most efficient software update file source given the client’s current location and available bandwidth.

Web Service Changes

The current Windows Update Web site (where end users go with a browser to download updates) and the Windows Update Web service (where the current AU agents or SUS go to download updates) will be updated and renamed Microsoft Update at the same time WUS ships. This change reflects consolidation of the Windows Update and Office Update sites into a unified update site. At launch, Microsoft Update will support detection and updating of Windows, IE, Windows Media Player, SQL Server 2000 (including MSDE), Exchange 2003, and Office XP and 2003. Eventually, it will grow to support updating of all Microsoft products.

Furthermore, Microsoft Update will eventually include much more than patches and service packs, such as developer kits, drivers, feature packs, prescriptive guidance kits, tools, update rollups, noncritical updates, and connectors that link various Microsoft products. While Microsoft Update is not designed to host software updates for third-party products in general, hardware vendors with Windows Hardware Compatibility Lab-certified drivers can have Microsoft post them on the Microsoft site.

During 2004, Microsoft announced its intentions to reduce the number of installer technologies it uses in its products to two: the Windows Installer for applications and the Update.exe installer engine for Windows components. The company claims that by the time Microsoft Update goes live, it will be very close to meeting that goal. Standardization on these two installers will make it easier for Microsoft and other management tool vendors to produce updating solutions that are better understood and easier for system administrators to manage—for example, they will use consistent installation switches and write standard format installation logs to a standard file directory.

Migration Issues

WUS is functionally similar to SUS, but because it uses completely different underlying technology, installing WUS on a SUS server does not perform an upgrade but instead installs the two products side-by-side.

WUS comes with a command-line migration tool that allows administrators to move software update approvals and downloaded software updates from SUS to WUS. This two-step export/import process also works over a network, so it can be used to bring a newly installed WUS server up-to-date with an existing SUS server, whether on the same or separate machines.

Organizations with a single SUS server or multiple SUS servers not arranged in a hierarchy can export the approval and software update data, deinstall SUS, install WUS on the existing servers, and import the migrated data. Clients pointed at those servers will connect and automatically update themselves to the latest WU and BITS versions. If the organization decides to use new servers, with different computer names, they will also have to reconfigure the clients to point to the URLs of the replacement servers.

Migration of hierarchical SUS systems is more involved because SUS and WUS servers cannot be mixed in a single hierarchy; WUS servers can only synchronize with other WUS servers or with the Microsoft Update Web service. SUS and WUS hierarchical systems may need to run in parallel during a gradual migration. An organization can also run its SUS and WUS servers on the same computers by configuring WUS to use a custom port number rather than the standard HTTP port 80.

Living in the Shadow of SMS

As noted earlier, both SMS 2003 and WUS address the need for centralized software update management, but the free WUS product lives under the shadow of its fee-based cousin, SMS 2003—a far more flexible and capable product, for which software update management is a subset of its broader inventory and software distribution functions. Both products make use of software update applicability scanners (currently based on different technologies) that compare file properties and Registry data against Microsoft-maintained software update applicability data to determine which software updates are installed and which updates are needed. Both also use BITS to move software update files between source servers and their clients. However, the similarity ends there. Each uses a completely different architecture. SMS provides far superior reporting and targeting capabilities, and it can handle large, complex network topologies and delegated administration, while still providing a centralized view of the organization’s software update compliance status. (See the chart "How Do WUS and SMS Compare?".)

Since SMS is a functional superset of WUS, few organizations already using SMS 2003 can benefit from WUS. Organizations without SMS 2003 or a third-party software update distribution product face the choice of which product to use, if any (both products are complex enough that neither is for small organizations that lack a dedicated system administrator or service provider to manage their system). The choice essentially boils down to cost: if customers can afford SMS’s license costs (approximately US$48 per managed device plus US$1,300 for an SMS/SQL Server bundle for each server), they get better updating capabilities with SMS and also benefit from its other functions, such as the ability to install software or track licenses. Furthermore, if customers are participating in Microsoft’s Enterprise Agreement volume licensing program and have licensed the Core Client Access License (CAL), which includes an SMS CAL, they have already paid the bulk of SMS’s licensing cost.

For those organizations that cannot justify SMS 2003, WUS is better than pointing AU/WU agents directly at Microsoft Update, but it is really not "free" when total cost of ownership is factored in: it requires server hardware, test machines, training, people to do software installation and configuration, and routine attention from IT personnel.

The product overlap between WUS and SMS also puts Microsoft in a quandary: WUS customers are likely to ask for more SMS-like features, but the closer the two become, the less incentive customers will have to pay for SMS, which is currently selling well. The overlap also means that Microsoft is paying for development of two separate products when one could do the job. It is puzzling that Microsoft did not simply create a free or low-cost "light" version of SMS that is limited to software update management and that is upgradeable to the full version, but Microsoft’s roadmap indicates that it will be many years before the two merge together onto a common technology base.

Since the product architectures are so different, this eventual merger will require one of the two products to undergo radical redesign. However, one change will take place in the short term: SMS 2003 customers will get a free update within 60 days of WUS’s release that replaces SMS’s current software update scanner and update applicability data file format (based on the Shavlik’s HFNETCHK scanner, which is also used by the free Microsoft Baseline Security Analyzer tool) with the Microsoft-developed scanner used by WUS and the WU agent. This move will finally eliminate inconsistencies between the results returned from SMS 2003 scans and results returned by AU or the Windows Update site.

Resources

More information and the WUS beta are available at www.microsoft.com/windowsserversystem/wus.

A WUS Wiki site that provides additional information is available at wus.editme.com.

WUS’s positioning and roadmap vis-à-vis other Microsoft management products and technology is described in "More Integration on Management Roadmap" on page 11 of the May 2004 Update.

More detail on SMS 2003 may be found in "Stronger Systems Management Server Worth a New Look" on page 9 of the Nov. 2003 Update.

Background on SUS is contained in "Software Update Service to Ease Patch Distribution" on page 3 of the May 2002 Update.