New information has been added to this article since publication.
Refer to the Editor's Update below.
Patch Management
A Hands-On Guide to Hands-Off Updates with WSUS
Jeremy Moskowitz
At a Glance:
- Planning for a WSUS rollout
- Installing a WSUS server
- Setting up notification groups
- Server hierarchies explained
Windows Server Update Services
SQL Server
Windows Server 2003
An essential, though sometimes time-consuming, task for protecting your computing environment is to keep systems current with the latest software updates and patches. To help streamline this process, Microsoft recently released
Windows Server™ Update Services (WSUS), which greatly improves upon its predecessor Software Update Services (SUS). WSUS is a flexible component that can be installed on Windows Server 2003 or Windows® 2000 Server, and lets you deploy Microsoft product updates to systems throughout your network running Windows 2000 Server, Windows Server 2003, Windows XP, and more. In this article, I examine the various configurations that WSUS supports, and look at the features to help you get it up and running quickly.
Choosing a Topology
Before you do anything else, you need to determine precisely how many WSUS servers you’ll need to support your enterprise. If you have a single office, you’ll most likely only need one server. In a single WSUS server environment, as shown in Figure 1, all clients utilize the same WSUS server to grab their updates.
Figure 1 Using a Single Update Server
Whereas SUS dictated that all clients that requested updates from a single server got the same updates, WSUS gives you the ability to specify groups of computers (clients, servers, or a combination of both) that will receive the same updates. In Figure 1, for example, there are three groups defined. The term "groups" can be a little confusing, though—groups in WSUS does not refer to groups defined in Active Directory®. Rather, these groups are simply collections of computers defined within the WSUS environment. I’ll explain how to define and configure groups later.
Planning the Installation
Once you have a handle on which topology you’ll deploy, you’re ready to install your first server. WSUS stores information about known patches in a database. The good news is that you get to choose which database is used to store this information: SQL Server™ 2005, SQL Server 2000, SQL Server 2000 Desktop Engine (MSDE), or SQL Server 2000 Desktop Engine (Windows) (WMSDE), which is available for Windows Server 2003.
For smaller installations, SQL Server may not be the ideal choice if you’re only using it for this one task. However, if you already have SQL Server deployed and have SQL expertise, then it’s a perfectly viable option. Of the other options, WMSDE does incorporate performance enhancements over MSDE, but in this case they’re likely to perform very similarly. WSUS ships with WMSDE, so that’s an easy choice for the majority of installations running Windows Server 2003. MSDE can be used if you install WSUS on Windows 2000 Server instead.
Smaller installations or satellite offices often have only one or two Windows-based servers. You might be tempted to just load WSUS on the one server already out in the field. However, before making that decision, be sure to recognize the kinds of loads that machine could be under when you’re rolling out an important patch or update.
WSUS is currently capable of delivering updates for four product families: Windows, Office, Exchange Server, and SQL Server. It is also internally architected to deliver additional update types in the future. Service packs for an operating system typically range somewhere between 300 and 500MB. If you have multiple languages to deal with, you have to carve out space for each language as well. All of the patches, service packs, and languages you’ll have to support can constitute a huge storage requirement. While WSUS will only download updates as they are needed, you’ll still need to plan for long-term growth. Microsoft recommends a minimum of space for potential downloads of at least 10GB. However, I recommend a realistic minimum of about 20GB of space for an average environment.
If you only have one server in a small or branch office, you need to be sure it can handle the space and performance requirements of WSUS when servicing clients for not only regular updates, but larger service pack releases for Windows or Office as well. Additionally, keep in mind that WSUS requires IIS 5.5 or later. You may want to consider a stand-alone installation of IIS dedicated to WSUS, simply to ensure that it doesn’t interfere with other production uses of IIS you may have in your environment.
Installing Your First Server
Installing your first server is really a piece of cake. First, make sure that IIS is already installed on the server you choose. You’ll need to have Background Intelligent Transfer Service (BITS) 2.0 and Windows HTTP Services (WinHTTP) 5.1 already installed on the machine. (The installer for both can be found through Knowledge Base article 842773.) Also required is The Microsoft® .NET Framework 1.1 SP1.
On my server, I created a 20 GB D: partition on which to load WSUS and store the available updates. At installation time, I was given the option of storing the updates locally, which is recommended. If you don’t, every time a patch is needed, clients will have to fetch the patch from the main Microsoft servers.
You are also given the choice to mirror an existing WSUS server. If this is your first WSUS server, you can safely skip this option and click Next. However, if this isn’t your first server and you want to create a server hierarchy, you can point your new server toward an existing one to grab all the needed information.
Once you’ve finished those initial settings, WSUS is ready to go. You can select Options | Synchronization Options to make some major configuration decisions. Here is where you choose where to get your updates (from Microsoft directly, or through another WSUS server) and, under the advanced options, select which languages you’ll want to download (see Figure 2). In many cases you can choose to download only updates that match the locale of your server. This is a much more sensible choice for the majority of environments.
Figure 2 Selecting Options
Notification and Groups
WSUS needs to know what mechanism you’ll use to let clients know they might have updates waiting for them. If you select Options | Computers Options, you can choose from the two options shown in Figure 3: Use the Move computers task in Windows Server Update Services or Use Group Policy or registry settings on computers. WSUS also calls these options server-side targeting and client-side targeting, respectively.
Figure 3 Finding WSUS Server
For server-side targeting, you’ll utilize the Move the selected computer task on the Computers page to organize your client computers into groups. This option is generally meant for organizations with smaller implementations. However, personally, I think the next option, client-side targeting, should be used for implementations whenever possible.
For client-side targeting, you’ll perform one of three steps:
- Create a Group Policy and link it to an Organizational Unit (OU) within Active Directory that contains the client computers or servers
- Edit the local Group Policy Object on target computers
- Edit the registry
Each of these three steps has the exact same effect, but utilizing Group Policy within Active Directory allows for the most straightforward and manageable option for larger organizations.
Configuring the clients through Group Policy is quite simple. In fact, if you’ve previously configured SUS through Group Policy, you’re already on the way. The Group Policy settings to configure a client to utilize WSUS are found by selecting Computer Configuration | Windows Components | Windows Update within the Group Policy template.
Figure 4 Update Service Location
While WSUS does bring a handful of additional client-side options, only two are of major concern with regard to architecting your WSUS environment. The policy setting specifying the update service location is shown in Figure 4, and the policy setting that enables client-side targeting is shown in Figure 5.
Figure 5 Client-Side Targeting
Clients tell WSUS which server they want to receive updates from when they get a message from Group Policy explaining which server to report to. This is specified in the Update Service location policy setting, as seen in Figure 4. Simply specify the upstream update server URL in both fields.
Additionally, clients need to know which WSUS group they belong to, which they can also learn through Group Policy. Again, they can relay that information to the update server.
Conclusion
WSUS adds some great new functionality to its predecessor, but the real news is in the increased flexibility that it provides. For example, WSUS allows administrators to choose a topology that makes sense for their organization. In addition, Group Policy and the WSUS group functionality can be used to manage both clients and the methods by which updates are distributed. This kind of custom control makes WSUS an adaptable infrastructure that ensures that your computing environment will always be up to date with the very latest software and fixes.
Hierarchical Configurations
In a single, small-to-mid-size office environment, using a single server and separating computers into a few groups for updating might be the right choice. However, if you have a very large environment with many branch offices, slow WAN links, multiple administrators, and perhaps a little bit of red tape, you might be better off with a hierarchy of servers. A server hierarchy gives admins the ability to direct which clients will utilize which servers. For instance, the clients in a branch office with a slow WAN link would want to use a locally available update server to avoid downloading large service packs across a slow link.
WSUS hierarchies are very flexible and have three main configuration possibilities, as described here. In each case, the configuration involves two server types: upstream servers that connect to Microsoft servers to retrieve updates, and downstream servers that only connect to upstream servers.
Configuration 1: Standard Hierarchy
In this configuration, the downstream servers can only distribute updates if they’ve been previously approved at the upstream server. This allows for organizations to decide at a high level which patches and updates work for the entire company, but it also allows administrators close to the user populations to determine which subset of those updates is right for them, and when to deliver them.
[Editor's Update - 4/18/2006: A point of clarification – In the Standard Hierarchy configuration, the downstream server is restricted to retrieving its updates from the upstream server, but the distribution approval process on the downstream server is done independent of approvals made on the upstream server. This is in contrast to the Replica Hierarchy configuration shown below, in which the downstream approval process is tied directly to approvals made on the upstream server. ]
Configuration 2: Replica Hierarchy
In this configuration, the downstream servers are exact clones of the upstream servers. When an update is approved on the upstream server, the downstream server will also automatically approve it. This configuration allows for centralized administration of all updates and patches, and ensures a uniform deployment approach across the environment. The only difference between the downstream server and upstream server is where the clients are receiving their updates from. Here again, the goal is for clients that have a slow WAN connection back to the main office to be able to use servers close to them.
Configuration 3: Disconnected Hierarchy
With this configuration, there is no ongoing communication between the downstream server and the upstream server. This configuration might be useful on, for example, ships at sea that only receive updates when at port, or perhaps in very secure environments that don’t connect directly to the enterprise network. When using a disconnected hierarchy, the approved updates need to be exported from the upstream server, typically through a CD or other removable media. The CD is delivered to the disconnected system and installed on the downstream server.
Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He also runs a two-day Group Policy intensive training course. His latest book is Group Policy, Profiles and IntelliMirror, 3rd edition (Sybex, 2005). Contact Jeremy at www.GPanswers.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.