Let WSUS Ease Your Patch-Deployment Hassles

9:00 a.m. Monday: Microsoft releases critical security patch.
9:00 a.m. Tuesday: You successfully deploy patch across 2500 desktops and 150 servers.

Does this scenario sound too good to be true? A wishful dream after having spent one too many nights alone in the server room? For years, most administrators would have assumed that large-scale, rapid deployment of patching just wasn't possible. I'm here to tell you that it is possible and available to you today, in the form of Microsoft's Windows Server Update Services (WSUS). Cancel any appointments you might have for the rest of the week. You'll want to get started implementing WSUS ASAP, and I'll show you how to do that here.

Installing WSUS
The new WSUS patch-delivery system, which is currently available as a Release Candidate (RC) at the time of this writing, is already playing a significant role within production environments. Using Software Update Services (SUS) as a baseline, WSUS offers a comprehensive set of capabilities above and beyond what SUS provides. (The Web-exclusive sidebar "A Brief History of WSUS" at http://www.windowsitpro.com, InstantDoc ID 46172, which is available to Windows IT Pro subscribers only, discusses the evolution of Microsoft's update services.) Namely, WSUS offers reporting, support for patching of applications (e.g., Exchange, Microsoft Office, Microsoft SQL Server), the ability to group computers for patch deployment, and the concept of mandatory "deadlines" for the installation of patches at an administrator's discretion. With the final release of WSUS in June or July, patch deployment should never be seen as a headache ever again. You can download WSUS at http://www.microsoft.com/windowsserversystem/updateservices/default.mspx.

In support of a WSUS installation, there are some prerequisites you'll need on your WSUS server and client systems. First, you'll need a Windows Server 2003 server or a server running Windows 2000 Server and Microsoft IIS that's been upgraded to support Background Intelligent Transfer Service (BITS) 2.0. The BITS 2.0 download is available via the WSUS download site. Of course, as with most anything released from Microsoft these days, you'll also need to upgrade your system to the latest version of the Windows .NET Framework for WSUS to work correctly. After you've upgraded these components on your target system, you can begin installing the WSUS service by launching the WSUS installer that Microsoft provides in the WSUS download file.

When you start the installation, one of the first items you're prompted for is where you want WSUS to store the updates it receives from Microsoft. You can choose either to store updates on your WSUS server itself or have clients access a Microsoft server for downloads, as Figure 1 shows. My feeling is that disk space is exceptionally cheap, but Internet bandwidth is not. If you have thousands of workstations in your organization, imagine them all trying to download patches simultaneously. Therefore, I suggest you specify a local directory path for storing WSUS patches on your server. Make sure that the volume and directory you choose has at least 6GB of free disk space. At publication time, downloading the entire set of patches (including support for all languages) required approximately 2GB of disk space.

WSUS needs an additional 2GB of disk space to allocate for its own database—a SQL Server database that WSUS uses to track information such as which patches your organization has and hasn't approved for download, how you prefer to group machines, and which patches have been successfully deployed (and to which systems). You don't need a full-blown SQL Server system in your organization to use this database (although if you do, it's recommended that you use it); you can opt for WSUS to install and use the SQL Server desktop engine, as Figure 2 shows.

After a few more confirmation dialog boxes are displayed, the WSUS installation starts. After the installation is done, WSUS is available and ready for you to start using. All WSUS functions are driven by a Web-based interface, which you launch by opening Microsoft Internet Explorer (IE) and browsing to http://localhost/wusadmin. If WSUS is working right, you should see a page similar to the one that Figure 3 shows.

Choosing WSUS Download Options
The WSUS administration interface comprises five main areas, as shown by the five icons across the top right portion of the screen: Home, Updates, Reports, Computers, and Options. When you start WSUS for the first time, obviously no updates are available for you to approve or deny (unless you're upgrading from SUS). The list of updates on the initial page should total zero, as Figure 3 shows. Therefore, your first task is to set up WSUS so that it will retrieve all the updates you'll need. But wait! Don't click that Synchronize now link too fast; there are a couple of options you might want to set first. Click the Options icon to configure the parameters for WSUS.

When WSUS initially chooses certain default settings for you, one of those settings is to download all available patches in every available language, which makes for an exceptionally long first download. Now, if you've deployed every language version of Windows 2003, Windows XP, and Windows 2000, this default behavior might be the right choice for you. However, for most sites it isn't and, furthermore, causes an excessive amount of space to be wasted (not to mention bandwidth at the Microsoft WSUS site). Therefore, select the appropriate languages for your organization. To do so, click the Options icon, then select Synchronization Options. Scroll down to the Update Files and Languages section and click Advanced. You should see a dialog box similar to the one that Figure 4 shows.

In Synchronization Options, you can also select what types of patches you want to download and make available (e.g., security hotfixes, service packs, drivers, critical hotfixes) and what products you intend to support. After you've selected all the options you want, return to the Home page, then click the Synchronize now link to start the synchronization process. If you don't see all the products available at first, don't worry; the rest should appear after the initial synchronization with Windows Update—Microsoft's online update-download service.

The initial synchronization for WSUS will take some time, depending on your bandwidth and the number of patches that need to be downloaded. I've seen the initial synchronization process take anywhere from 1 hour to an entire evening. After the synchronization is finished, you'll be able to start approving patches for deployment throughout your organization. When WSUS performs its initial synchronization, it retrieves only the details of each patch or hotfix. The patch isn't actually downloaded until an administrator approves it for deployment within your organization. To start approving patches for deployment, click the Updates icon to see which updates are available for download as well as those that have been approved for downloading to the WSUS server, as Figure 5 shows.

The repository of information that WSUS stores is a database, which means that patches and hotfixes now all have extended attributes that can easily be searched. When you view the Updates page for the first time, you can see fields associated with each patch, such as Classification and Approval. These are just two of the extended attributes that are now stored along with each patch that WSUS maintains. You should take the time to review the list of updates and understand what has and hasn't been approved, then make your changes accordingly. To change a patch's approval status, highlight the item within the Updates view, then click the Change approval option in the window's left frame. Clicking this option displays a dialog box similar to the one that Figure 6 shows.

By default, all updates are initially configured for a Detect approval state unless they're otherwise automatically approved according to synchronization policy. Patches that have a Detect approval state will simply inspect target systems to determine whether the patch is required and record that status. To approve a patch for deployment, select Install instead of Detect, and the patch will be deployed throughout your organization. For certain patches, Microsoft has even included an uninstall capability that you can apply to a patch by selecting the Remove option from the Approval drop-down list. WSUS can't automatically remove patches that don't support removal (such as the one that Figure 6 shows); the Remove option isn't displayed for such patches.

Defining Patch Options for Groups
Using the Install and Remove options, in conjunction with groups of test computers, gives you an easy mechanism to test new patches within your organization. You can push new patches to a selected group of test systems, evaluate the servers and their applications to make sure everything is still running properly, then deploy the patches throughout the rest of the organization.

The ability to group together sets of computers is a new feature of WSUS—one that SUS sorely lacked. SUS administrators typically didn't want to deploy the same set of patches to their servers that they'd deploy to desktops (for example, most servers don't need to have Windows Media Player—WMP—patched), so they invented creative workarounds for that situation, usually involving running multiple SUS servers within their organization. WSUS removes the need for using multiple SUS servers by letting administrators group computers together according to criteria that suit their organization. When you approve a patch for installation, you can define different options for different groups of computers. For instance, you might want to have servers detect only whether or not a patch is necessary initially, whereas end-user desktops have the patch installed automatically. You can designate multiple actions for each patch that WSUS stores and distinguish those actions by groups of computers.

Besides defining the appropriate detect, install, and remove options that you want to apply to a patch, you can define a date and time by which WSUS and Automatic Updates will force an installation if it hasn't already taken place. This capability is a lifesaver when the CIO wants a guarantee that the latest security hotfix can be deployed throughout the enterprise within a certain timeframe. To set a deadline for a patch, click the None option next to the Deadline field, which Figure 6 shows. Doing so displays the Edit Deadline dialog box that Figure 7 shows.

Basically, you have three options when it comes to considering a deadline for a patch: Let users apply it whenever they want to; let users apply it whenever they want to, but force an installation if a certain date and time pass; or force an installation immediately. To let users apply the patch when they want, simply leave the Deadline field set to None when you select to install a patch. To ensure that users perform an installation by a specific date and time, set the deadline in the Edit Deadline dialog box. After the specified deadline has passed, users will be required to install the patch. Finally, to force a patch out throughout your organization as quickly as possible, simply set date and time values to the current date and time, and all systems will start working on the update as soon as possible.

Configuring Clients
You'll need to make some configuration changes to Automatic Updates clients so that they can receive patches deployed by WSUS. You must reconfigure the clients to talk with your WSUS server instead of the default Windows Update server that Microsoft manages. By default, the Automatic Updates client will always try to attach to Microsoft's Windows Update server. However, with WSUS, you're effectively running your own version of Windows Update, so you'll need to reconfigure the client accordingly.

If you've ever configured Automatic Updates before, you might be thinking that you don't remember seeing anywhere that you could add or change a server name. You're right; to make these changes, we'll need to go into the registry. Start the registry editor and navigate to the HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows subkey. Under this subkey, you might find the WindowsUpdate subkey in your configuration. Don't worry if you don't see it; it might not exist on some systems because it isn't created by default. Create the HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate subkey, if it doesn't already exist. This subkey will be the container for two values that we'll create: one to tell Automatic Updates that it should look for a WSUS server, and another to tell Automatic Updates where it can find the WSUS server.

Next, under the WindowsUpdate subkey, you'll need to create a subkey called AU, then for the AU subkey a REG_DWORD value called UseWUServer that has a value of 1 (true). This value tells Automatic Updates to use a custom WSUS server instead of the standard Windows Update server that Microsoft maintains.

While you're still in the AU subkey, create an additional value of type REG_DWORD and name it AUOptions. This value defines how you want the Automatic Updates client to behave: Simply notify users that patches are available, notify and download the patches, or do a full installation. I recommend that you initially enter a value of 3 (notify and download); you can change the value later, if necessary.

Next, navigate back to the HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate subkey and add two REG_SZ values named WUServer and WUStatusServer. For both values, enter the URL for your WSUS server, as Figure 8 shows. These values tell Automatic Updates where it can find your custom WSUS server.

Of course, manually making registry changes to every workstation and server in your organization could be a considerable task. Therefore, I recommend that you use Group Policy to set these parameters, or distribute a .reg file within your organization (perhaps through a logon script) to apply the changes to each system you maintain.

While you're twiddling around in the registry to set these values, you might also want to change some of the other standard Automatic Updates client parameters. Those parameters, which Web Table 1 lists are stored in the HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU subkey.

Worry-Free Patching
Now you can sit back, relax, and watch WSUS do all the patch-deployment work for you! As long as you have a correctly configured implementation, WSUS can retrieve patches for you, approve them, and require them to be installed throughout your organization. The headaches of patching are a thing of the past, and I know that I sleep a little better knowing that I have a tool like WSUS available to help me when I need it most.