Designing an Enterprise WSUS Deployment

Once upon a time, you could use do-it-yourself, spit-and-glue solutions to keep your systems patched. But malware now spreads so quickly that you can't rely on your users visiting Microsoft's Windows Update Web site to maintain an adequate level of security in your enterprise. On June 14, 2005, Microsoft released 10 security bulletins as part of its monthly patch update. Three of the vulnerabilities were rated critical, and analysts predicted that malware exploiting those weaknesses would appear within a week. Fortunately, just a few days earlier Microsoft had rolled out the first components of its new update infrastructure, including its robust, reliable patch management solution, Windows Server Update Services (WSUS).

In addition to Windows updates and security patches, WSUS lets you deploy drivers, tools, service packs, feature packs, Microsoft Office 2003, Windows XP, Microsoft SQL Server, and Microsoft Exchange Server. But before deploying WSUS in an enterprise, you need to plan for it by making decisions on key deployment considerations and choosing an appropriate topology. I explain the steps in designing an enterprise WSUS deployment, but I don't go into the details of installing WSUS; Douglas Toombs covers that topic thoroughly in "Let WSUS Ease Your Patch-Deployment Hassles," June 2005, InstantDoc ID 46171.

The Microsoft document Deploying Microsoft Windows Server Update Services, which you can download from Microsoft's WSUS Web site (http://www.microsoft.com/windowsserversystem/updateservices), offers key design considerations. First, you need to formulate your update plan, including strategy, objectives, resources, and procedures. Then, you need to select a database engine for WSUS, determine the best locations for your WSUS servers, decide which update files to obtain and where to store them, and develop a client-group targeting strategy. After you complete these tasks, you can design a WSUS topology.

STEP 1: Formulate Your Update Plan
Before doing anything else, you need to ensure that your team and organization agree about the need for update management, the objectives you want to achieve, and how WSUS meets those goals. WSUS supports a range of updates for key Microsoft platforms and applications and can manage patching on Windows 2000 and later clients. Although WSUS supports updates for third-party products, currently no third-party vendors are taking advantage of its capabilities, so you need to decide what tools to use to update technologies and products that WSUS can't yet handle.

You also need to determine the kinds of updates you want WSUS to deploy (e.g., security updates, feature packs, drivers, rollups, service packs) and the process you'll use to identify, evaluate, test, deploy, and troubleshoot or uninstall updates if necessary. Consider your requirements for compliance reports and determine whether WSUS's reporting capabilities meet your needs. Finally, identify who will perform the procedures necessary to support update services.

STEP 2: Select a Database Engine
WSUS downloads updates from Microsoft Update. Updates consist of the update file, which is distributed to clients for installation, and metadata, which includes the update's name, release date, revision number, affected products, and reboot requirements. The metadata downloads to a database that's dedicated to the WSUS server and also stores WSUS configuration settings. As clients poll WSUS, the server adds basic inventory information to the database. Update status is also stored in the database.

Each WSUS server requires a unique database instance. The database can be one of the following:

The best database for your update server depends on your hardware platform, the number of clients the server supports, and your tolerance for license fees. Each WSUS server requires a unique instance of SQL Server, MSDE, or WMSDE; a remote centralized SQL Server system can't support multiple WSUS servers. I suggest you start with WMSDE on Windows 2003 and monitor performance.

STEP 3: Determine Locations for WSUS Servers
WSUS can run on Windows 2003 or Win2K Server SP4, including Small Business Server (SBS) 2003. WSUS can't run on 64-bit Windows 2003 platforms. Such systems can receive updates from WSUS but can't provide update services to other clients. Microsoft recommends Windows 2003 over Win2K Server SP4 because Windows 2003 has a more secure code base and WMSDE availability.

WSUS also requires Windows .NET Framework 1.1 with SP1, Background Intelligent Transfer Service (BITS) 2.0, Windows HTTP Services (Win-HTTP) 5.1, Microsoft Internet Information Services (IIS) 6.0 (for Windows 2003) or IIS 5.0 with IIS Lockdown (for Win2K Server), Microsoft Internet Explorer (IE) 6.0 with SP1, and a local database engine (unless you're running a remote SQL Server configuration). These software requirements might determine your choice of server, because they might affect previously installed services or applications on an existing server.

You need to install WSUS on a member server rather than a domain controller (DC). Running WSUS on a DC might be adequate for a small company or branch office, but doing so has performance and security implications for all enterprises. If you choose to install WSUS on a Win2K DC, read the documentation for specific Win2K DC problems. You can also install WSUS on SBS, but you need to read the documentation to prevent conflicts between WSUS, Companyweb, and Windows SharePoint Services. Installing WSUS on a member server is the best option.

To administer WSUS and manage updates, your security token must include the local Administrators group. Because you can't delegate WSUS or update administration without delegating administration on the entire server, you need to install WSUS on a dedicated server.

For optimal performance, place WSUS servers where they can best use the company's bandwidth. A WSUS server must download update metadata and, usually, the update files from Microsoft Update or an upstream WSUS server (as I discuss later). Because every client that's directed to a WSUS server polls and, typically, downloads update files from the server, a common configuration is to place WSUS servers in locations that are separated by slow links. You also need to consider the number of users to direct to each WSUS server and monitor the server for performance bottlenecks.

STEP 4: Decide Which Update Files to Use
After clients connect to a WSUS server, they obtain a list of approved updates from it, report whether the updates are necessary, and inform the server of the updates' installation status. You can specify whether clients download updates from the WSUS server or from Microsoft Update.

The advantage of storing update files locally is that you minimize the use of external links: The WSUS server downloads update files to the network, then distributes them to clients. BITS 2.0, the technology that downloads updates from Microsoft Update to WSUS and then to clients, uses network bandwidth more efficiently than does Microsoft Software Update Services (SUS). If a client's network location makes downloading updates from the WSUS server inefficient, you can configure WSUS to let clients obtain the list of approved updates from the server but download the updates themselves from Microsoft Update.

A useful feature is express installation files, which lets WSUS distribute only changed bits of files rather than entire updates. Clients apply the revised bits to the existing files. An express installation update is sometimes referred to as delta delivery because clients download only the difference, or delta, between file versions.

A drawback of express installation files is that the WSUS server must download a different variation of the delta for each version of a file. Instead of downloading only one update file, the server downloads a file that contains all possible variations. However, express installation still saves network bandwidth because clients download only the bits necessary to patch their current file version. Figure 1 illustrates the difference between a full file update and an express installation file update.

STEP 5: Develop a Group-Targeting Strategy
WSUS lets you create target groups of clients and approve updates for particular groups. Design your groups to support your update strategy. Common strategies are grouping clients by type (e.g., server, desktop, laptop), role (e.g., executive, development), update rollout phase (e.g., test, pilot, deploy, do not patch), client configuration (e.g., simple/ managed, complex/unmanaged—computers with complex configurations and unmanaged computers are difficult to troubleshoot or roll back), and update priority (e.g., critical, normal, low).

After you decide on a computer grouping, you need to determine which computers belong in each group and decide which WSUS server each computer will download updates from. These considerations affect your topology, which I discuss next. Implementing computer groups on WSUS is complicated; I'll discuss the process in a future article.

STEP 6: Design a Topology
After you complete the planning phase, you can evaluate WSUS topologies and determine how to best design your environment. Server configuration options include single, hierarchical or chained, replica, disconnected, and multiple.

To implement a topology, go to the WSUS administration Web site, http://WSUSservername/WSUSAdmin (where WSUSservername is the name of your WSUS server), and click Options, Synchronization Options. In the Update Source section, you'll see the options for obtaining updates. The first option, which is the default, obtains updates from Microsoft Update. This configuration is the basis for a single-server topology. You can also have WSUS obtain updates from an upstream WSUS server.

Single server. Using one WSUS server is the most straightforward topology. If your organization's update infrastructure can function with only one server, select Microsoft Update as the update source. After your server downloads updates, you can approve them and target them to groups of computers, and clients will download the appropriate updates from the server. You can use target groups, which I discuss in more detail in an upcoming article, to distribute updates to specific computers. Figure 2 illustrates a single-server topology.

Hierarchical or chained servers. If your site has many clients, you might want to deploy multiple WSUS servers to improve performance. You can have multiple servers in one location to support a large user population or distribute updates to servers in different locations, as Figure 3 shows.

If you use a single-server topology, the WSUS server obtains updates from Microsoft Update. In a multiple-server configuration, however, servers often obtain updates from other WSUS servers. The server that provides the updates is the upstream server; servers that download updates from an upstream server are referred to as downstream servers. Although the hierarchical structure technically has no depth limit, Microsoft has tested a depth of only five WSUS servers. The acceptable lag time between an update's approval on the most upstream server and when the approval installs on downstream servers and clients determines a hierarchy's maximum depth; three levels deep is the recommended maximum.

To properly implement a hierarchical topology, you must understand how configuration and updates are handled. You need to maintain a consistent configuration throughout the hierarchy. For example, each server must use the same update file storage location—a server can't store update files on Microsoft Update if an upstream or downstream server stores the files locally, and vice versa. Content filters (i.e., subscriptions to product categories, update classifications, and languages) must also be uniform. And if you use express installation files, you must do so consistently.

You can manage the list of approved updates independently on each WSUS server in a hierarchical topology. But keep in mind that the most upstream server approves updates from Microsoft Update and downstream servers download only updates that the upstream server has approved. Downstream servers don't know about updates that the upstream server doesn't approve. Upstream servers in effect provide a global approval list, and downstream servers maintain the same list of updates or a subset of the list.

Because each server in a hierarchical topology lets you approve and target updates independently, you can choose whether to use a centralized or decentralized management model. For a distributed, centrally managed hierarchical topology, configure downstream servers to automatically accept all updates that the upstream server approves. For a distributed, decentralized hierarchical topology, let downstream WSUS server administrators configure their own approvals or auto-acceptance rules. This practice is common in large enterprises with geographically distributed business units. A central WSUS server manages the global list of approved updates, and administrators for downstream servers manage approvals for clients that use those servers.

If you employ a hierarchical model, don't use the deferred download option (which I discuss in an upcoming article). This option can delay update distribution to downstream clients, particularly in a hierarchy more than one level deeper than the most upstream server.

Remember that WSUS servers are also clients and must also be updated. In a hierarchical model, you need to direct the WSUS servers to the most downstream WSUS server for updates, which seems counterintuitive. The reason for this requirement is to allow for future patches to WSUS files. If Microsoft releases a WSUS patch and an upstream server patches itself in such a way that it prevents downstream servers from communicating with it, the update will never travel downstream and all updating will stop. Thus, you need to allow updates to travel all the way downstream before WSUS servers update themselves. In addition, the most downstream server must update itself last. The recommended method to achieve this goal is to target the server separately (i.e., place the server in its own target computer group) and approve WSUS-related updates after they are applied to existing WSUS servers. Finally, to ensure that updates travel downstream before the WSUS servers update themselves, keep your model relatively shallow.

Replica servers. A replica server is a mirror of an upstream WSUS server. Figure 4 shows a replica WSUS topology. Unlike a downstream server in a hierarchical topology, a replica replicates its upstream partner's entire configuration, including updates, approvals, targeting, and groups. The only thing a replica manages uniquely is computer group membership. Because a client points to only one WSUS server, a computer belongs to a group on only one WSUS server. The replica contains the same group names as the upstream server, and approved updates are targeted identically, but group membership is unique to the replica.

For example, an enterprise might decide on a computer group targeting model that includes the computer groups Test, Critical, Important, Low Risk, and Do Not Update. In a replica topology, the updates that the administrator approves and targets to each group synchronize to each replica server. Each branch office or business unit might host a replica WSUS server. Replicas then manage the membership of their own groups.

This topology supports a centralized update approval strategy but distributes the updates themselves to multiple servers. You configure replica servers during WSUS installation. To configure an existing WSUS server as a replica, you must reinstall WSUS.

Disconnected servers. WSUS lets you use the Wsutil command-line tool to export updates from one update server and import them to another. This export/import feature is useful for updating clients that reside on a portion of the network that's disconnected from the Internet or the rest of the network. For example, an organization with black box or classified networks might use this approach. An administrator exports approved updates from a connected WSUS server, transports them on removable media to the disconnected network, and imports the updates to the disconnected WSUS server.

Multiple servers. A multiple-server topology is simply a replication of a single-server topology. Multiple WSUS servers obtain updates from Microsoft Update. Each server is managed separately and can have a unique configuration and unique settings and approval lists. This topology can be useful in a highly decentralized enterprise in which each business unit is responsible for managing its own updates.

A multiple-server topology is also necessary if you have users who dial in to your network or use a VPN connection. Suppose you have a corporate WSUS server that stores approvals and updates locally. Internal clients are directed to that server for approvals and updates. To minimize bandwidth usage, you want to direct remote users to the WSUS server for update approval and reporting but to Microsoft Update to download updates, as Figure 5 shows. A problem arises because the internal clients' WSUS server stores update files locally but the remote clients' WSUS server doesn't. Downstream hierarchical and replica topologies require all servers to use the same update file storage location. Thus, you need a standalone WSUS server for remote users. You must manually approve updates on this server separately from the internal WSUS server—you can't export and import update approvals only.

Microsoft needs to address this scenario in WSUS's next release. An alternative solution is to configure the internal server to download express installation files. The efficiency of delta updates and BITS 2.0 might eliminate the need for a separate WSUS server for remote-user update approvals.

Ready, Set...
Before you implement WSUS, you need to evaluate your update strategy, objectives, resources, and procedures; select servers and database engines; and determine which updates you want to download, where to store them, and to which computers you'll deploy them. Only then can you select the best update topology for your organization.

Go!
Implementing WSUS in an enterprise is challenging. In a later article, I'll explain how to install and configure WSUS and the Automatic Updates client in an enterprise setting.

Dan Holme ([email protected]) is the director of training at Intelliem, which delivers solutions-focused training and consulting services that support Windows and Active Directory implementations at enterprises.