Section 7.6. Windows Server Update Services

7.6. Windows Server Update Services

The bane of every administrator's existence. The pain in the rear of system management. That never-ceasing headache that pounds at CIOs everywhere. You might have guessed by now that I'm speaking of patch management.

And I use the term "management" loosely. In 2003, there were more than 40 updates that needed to be applied to a new Dell computer running Windows XP. There were over 20 updates for Windows 2000 Service Pack 3 that needed to be applied to new systems before Microsoft released Service Pack 4 in the summer of 2003. And right now, machines running Windows XP Service Pack 2--released in summer of 2004--need around ten patches, including a couple that require rebootsto get up to speed. This ever-growing hairball of security fixes, bug fixes, critical updates, and patch revisions has almost gotten to the point where it would be easier to disconnect all machines from the Internet and work with stone tablets than deploy new systems.

It shouldn't be that way, and Microsoft realizes that. They've come out with a tool that's not perfect, that has limited functionality, and isn't very flexible. But it's got two great things going for it: It's timely, and it works fairly well. That product is Windows Server Update Services (WSUS), and this chapter will focus on installing, implementing, and administering WSUS on your network. I'll also cover a comparison between WSUS and a flagship network and system-management product (Systems Management Server), and how to monitor WSUS for failures.

7.6.1. About Windows Server Update Services

As part of its Strategic Technology Protection Program, Microsoft sought to leverage its Windows Update technologythe software that runs the universal update site for all but the oldest versions of Windowsand integrate it into a LAN-based patch management solution. WSUS at this point does NOT focus on adding new features to already released software; it's only concerned with critical updates that allow administrators to somewhat easily deploy critical updates to servers running Windows 2000 or Windows Server 2003, and desktop computers running Windows 2000 Professional or Windows XP Professional. It's designed to work especially in networks with an Active Directory implementation, but it will function without one.

Installing WSUS on your network requires at least one server, running either Windows 2000 Server or Windows Server 2003 (for the purposes of this chapter, I'll assume you're using the latter) connected to the Internet running the actual server component of WSUS. This server needs, for all practical purposes, at least a 1 GHz processor and 512 MB of RAM. This machine acts as a local version of the public Windows Update site, which contains critical updates and service packs for all supported operating systems. This server synchronizes with the public Windows Update site on a schedule that the corporate administrator selects. That administrator then approves or rejects the availability of certain updates on the WSUS server. You can also have multiple WSUS servers on an intranet and configure which client machines are directed to specific WSUS servers for updates.

On the client side, WSUS also requires the Automatic Updates feature of Windows 2000 Service Pack 3 and higher, Windows XP Professional at any revision level, or any edition of Windows Server 2003. Directed by a variety of methods, the client computers that are running this Automatic Updates feature are sent to the local network's WSUS server on a set schedule to download updates appropriate to their machines. The WSUS server will analyze the operating system, service-pack level, and any currently installed updates, and push only those updates that are both needed AND that have been approved by the administrator beforehand.

7.6.2. Using Windows Server Update Services: On the Server Side

There are a few phases to the WSUS installation. First, you should download and install the software, which includes the Windows SQL Server 2000 Desktop Engine (WMSDE):

Go to the WSUS web site at http://go.microsoft.com/fwlink/?LinkId=24384.
Download WSUSSetup.exe to a folder on the server where you want to install the product.
Double-click the file using the server on which you want to install or upgrade WSUS.
Click Next on the Welcome screen to continue.
Decide whether to accept or reject the license agreement, and click Next.
The Select Update Source screen appears. Here, you can choose where the client computers will get their updates. You can either allow the WSUS server to store update content locally by clicking the Store updates locally checkbox and selecting a location on your filesystem, or direct clients to the Internet-based Microsoft Update site by leaving it unchecked. Click Next to continue.
The Database Options page is next, where you select the software used to store information about the updates that are offered. Select the default option of using WSMDE, which the wizard will install for you, unless you have an available instance of a SQL Server 2000 database to use instead. Click Next.
Next comes the Web Site Selection page, where you specify the web site that WSUS will use. Be careful to note the two important addresses presented on this page: the URL that clients will use to get updates, and the URL for the administrative console. If you're installing WSUS on a computer that already has a web site running on port 80, you may need to create a custom web site running on a different port. You can use IIS Manager (in the Administrative Tools area of the Start menu) to accomplish this. Click Next to continue.
You should now see the Mirror Update Settings page, where you specify which management role this WSUS server should serve. For the purposes of this demonstration, you're installing the first WSUS server on your network, so you can skip this screen. (It comes in handy when you have multiple WSUS servers that should contain identical updates and approval records within their databases.) Click Next to continue.
On the Ready to Install Windows Server Update Services screen, confirm your selections, and then click Next.

The next step is to make sure that your WSUS server can receive update information from the Internet. If you restrict Internet access via your firewall to certain domains, be sure to add the following domains to your exceptions list:

http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
http://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com

7.6.2.1. The administrative console

To open the administrative console for WSUS, open the Start menu, point to All Programs, Administrative tools, and then select Microsoft Windows Server Update Services. You can also open this console from your web browser by surfing to http://WSUSServerName/WSUSAdmin. You can also navigate through Start, All Programs, Administrative Tools, and click Windows Software Update Services. You'll see something much like that in Figure 7-16.

You may need to set a proxy server configuration if you use such a system to connect to the Internet. To do so, on the console toolbar, select Options, and then click Synchronization Options. Select the Use a proxy server when synchronizing checkbox in the Proxy server box, and then enter the appropriate name and port number. (This form is used in much the same way that you would Internet Explorer's options.) You can also enter credentials should they be needed by clicking the Use user credentials to connect to the proxy server box. To apply these settings, click Save settings under Tasks, and then click OK to confirm this action.

7.6.2.2. Synchronizing content

When you start the content synchronization process, which actually retrieves the updates for you to configure and deploy, the WSUS server goes out to either the public Windows Update servers or another local WSUS server (as configured in the "Mirror Update Settings" section) and downloads the entire library of available critical updates and service packs for each language you've configured. This initial synchronization usually results in about 150 MB worth of data being transferred for just

Figure 7-16. The WSUS administrative screen

English updates, or close to 600 MB of data for updates in every localization. After that, WSUS is able to determine if any new updates have been released since the last time you synchronized.

To synchronize content, surf to the WSUS administrative web site, and then do the following:

On the toolbar, click Options.
Click the Synchronize Now button under Tasks to begin the transfer.

There are also some advanced synchronization options that you can set, which can all be found under Options on the toolbar and Synchronization Options. Under Update Files and Languages, click Advanced, then read the warning and click OK. Then, select your preferred option or options:

Use the "Download updates to this server only when updates are approved" option to determine if updates should be fetched from Microsoft Update during the synchronization process itself, or if updates should be downloaded only when an update is approved. This is a great bandwidth management feature.
Use the "Download express installation files" option to specify whether express installation files should be downloaded during synchronization for faster installation on client computers.
Use the Languages section to filter updates that are written in languages that aren't deployed on your network, so that when you synchronize, bandwidth and time isn't wasted downloading patches for those localized versions. You can choose to match the locale of the server, download all localizations regardless, or to download updates in languages that you specify in a list.

7.6.2.3. Creating a computer group

Computer groups are an important part of even the most basic WSUS systems. Computer groups enable you to target updates to specific sets of computers that likely share some common criteria. WSUS ships with two default groups, called All Computers and Unassigned Computers. When each client computer initially contacts the WSUS server (more on that process a bit later in the chapter), the server adds it to both these groups. Of course, it's likely that you'll want to create your own computer groups, since you can control the deployment of updates much more granularly with them. For example, you can create a group named Test that contains some lab machines. You can initially deploy a new patch to the test group, and then, once you've verified the patch works on those machines, roll it out to other groups. Since there's no limit to the number of custom groups you can create, you can also block off machines into departments, function, roles, or any other denominator you wish to use.

Setting up computer groups takes three steps. First, specify whether you intend to use server-side targeting, which involves manually adding each computer to its group by using WSUS; or client-side targeting, which involves automatically adding the clients by using either Group Policy or registry keys. Next, create the computer group on WSUS. Finally, move the computers into groups by using whichever method you chose in the first step.

In this section, I'll talk about server-side targeting, since it's the most likely method you'll use by far.

To specify that you'll use server-side targeting to select members of computer groups:

In the console toobar, click Options, and then click Computer Options.
Click "Use the Move computers" task in Windows Server Update Services in the Computer Options box.
Within Tasks, click Save settings, and then OK to confirm your selection.

Next, create a computer group. In this example, we'll create the Test group I mentioned earlier:

In the console toobar, click Computers.
Within Tasks, click "Create a computer group."
Enter test into the "Group name" box and then click OK.

Finally, add a machine to that group. Of course, you'll need to follow the instructions within the client-side portion of this chapter to get the Automatic Updates software deployed, which will populate the WSUS console with a list of available computers. Once that's done, though, follow these steps to add a machine to a group:

In the console toobar, click Computers.
In the Groups box, click the All Computers group, and then in the list, click the computer you want to move into the Test group.
Under Tasks, click "Move the selected computer," select the Test group, and click OK to perform the move.

And that's all there is to it. Lather, rinse, and repeat until you have a group structure appropriate to your network and deployment methodology.

7.6.2.4. Approving content

Now that you have an actual library of updates on or near your WSUS host machine, and you've defined a couple of computer groups, you can approve the updates individually for distribution to client machines within your network. The approval process makes it easy to withhold patches until further testing is done, which partly assuages the general fear that's caused by installing patches that might cause more problems than they fix. To begin the update approval process, do the following:

In the console toolbar, click Updates. On the resulting page, you'll see only critical and security updates that have been approved for use on client computers; this is by virtue of a filter that you can later adjust to view only updates relevant to what you're currently administering.
Within the update list, select the updates that you would like to approve. You can click the Details tab for more information about the updates, and you can select multiple updates at one time using the shift key.
When you've finished your selection, click "Change approval" under Update Tasks.
The Approve Updates dialog box appears. Click Install within the Approval column for the Test group, and then click OK.

WSUS will notify you when the approval is complete. In the righthand pane, where all the updates are shown, each patch's status is shown as one of five possible values. A new update is one that was just recently downloaded and hasn't been approved yet. An approved update is available for distribution to each client machine. An update that isn't approved will not be distributed to clients, but the actual patch file remains in the library on the WSUS host machine. An updated patch indicates a new version of an earlier patch that currently exists in the library. And finally, a temporarily unavailable patch is one whose dependent files were downloaded incorrectly, could not be found, or were otherwise unable to be located by WSUS.

If, for some reason, you would like to clear the list of approved updates, you can clear all checkboxes on the list of available updates and then click Approve. This will remove any available updates from the WSUS catalog, and your client machines will stop downloading the updates until you approve more fixes. This will not, however, uninstall the patches from the client machines.

7.6.2.5. Checking the status of update deployments

Once a full 24 hours has passed, you can check the status of the approved update deployment. On the console toolbar, click Reports, and then on the resulting page, click Status of Updates. You can apply a filter by adjusting the settings under View, and you can change the view (perhaps to see the status of an update by computer group and then by computer, for example) by adjusting the controls on that page.

You can also print a status report by clicking "Print report" under Tasks.

7.6.2.6. Pushing out the automated updates client

Once your client computers first contact the WSUS server, the latest Automatic Updates software installed on your client computers will self-update to the latest version. There is one exception to this: the version of Automatic Updates included with Windows XP without any service packs cannot update itself automatically. You'll need to manually push this out via Group Policy, a login script, or "sneakernet"-style management.

You can install the updated Automatic Updates client on your clients by using the MSI install package, self-updating from the old Critical Update Notification (CUN) tool, installing Windows 2000 Service Pack 3 or 4, installing Windows XP Service Pack 1 or 2, or installing Windows Server 2003.

You can download the Automatic Updates client from the Microsoft web site at the WSUS web page, located at http://www.microsoft.com/WSUS. On a standalone machine, the AU client can simply be added by running the MSI file on the machine.

Manually installing a file can quickly become a pain when you have more than just a few machines to handle. Fortunately, because the client installation program is in the form of an MSI, you can easily push the program to clients by using Group Policy. To create a new GPO, assign it to your computers, and then have it installed automatically:

Open the Active Directory Users and Computers MMC snap-in.
Right-click the domain or organizational unit to which you're interested in deploying the client, and select Properties.
Click the Group Policy tab.
Click New to create a new Group Policy object (GPO). Type in a name for the GPO.
Select the new GPO from the list, and click Edit to open the Group Policy Object Editor.
Expand Computer Configuration, and then select Software Settings.
Right-click Software Installation in the left pane, select New, and then click Package.
Enter the path to the Automatic Updates MSI file you downloaded from the web. Make sure you use a network path and not a local path to ensure that your clients can find the file at boot time. Click Open.
Choose Assigned to assign the package to the computers in the domain or organizational unit, and then click OK.
Allow time for polices to replicate through the domain. Usually this is accomplished within 15 minutes.
Restart the client computers. The client software should be installed before the Logon dialog box is displayed, although on Windows XP machines you might need to reboot up to three times for the software installation policy to take effect (this is because of the fast logon optimization feature).
The application will be installed in the context of the local computer, so make sure that authenticated users have rights on the source folders.

You can also deploy the client MSI through a logon script by calling MSIEXEC followed by the client software file name as an argument. The software will be installed as requested.

7.6.2.7. Configuring the automatic updates client

The Automatic Updates client doesn't have any user-interface options for determining the origin of updates to install. You must set this with either a Registry change on each of the client computers or through Group Policy, either locally or based through a domain. Once the changes take effect, you'll be able to see the machines within the Computers page of the WSUS console.

Through a domain-based Group Policy, direct clients to the WSUS server by using the following procedure:

Open the Default Domain Policy GPO in Active Directory Users and Computers and click the Edit button.
Expand Computer Configuration, Administrative Templates, and Windows Components.
Select Windows Update. The right pane will contain four options that pertain to the Automatic Updates client, as depicted in Figure 7-17.

Figure 7-17. Group Policy options for WSUS and AU

These options are described here in more detail:

Configure Automatic Updates: This option specifies whether this computer will receive security updates and critical bug fixes. The first option makes sure that the currently logged-on user is notified before downloading updates. The user will then be notified again before installing the downloaded updates. The selcond option ensures that updates will automatically be downloaded, but not installed until a logged-on user acknowledges the updates' presence and authorizes the installation. The third option makes sure that updates are automatically downloaded and installed on a schedule that you can set in the appropriate boxes on the sheet. The fourth option, which will only appear if the AU software has updated itself to the version compatible with WSUS, allows local administrators to use AU in Control Panel to select their own configuration. To use this setting, click Enabled, and then select one of the options.
Specify Intranet Microsoft Update Service Location: This option designates a WSUS server from which to download updates. To use this setting, you must set two server name values: the server from which the Automatic Updates client detects and downloads updates, and the server to which updated workstations upload statistics. You can set both values to be the same server.
Enable Client-Side Targeting: This option enables client computers to automatically populate groups on thw SUS server. To use this option, click the Enabled option and then type the name of the group to which this computer should belong on the WSUS and then click OK. Keep in mind that you need to actually create the group on the WSUS server for this to take effect.
Reschedule Automatic Updates Scheduled Installations: This option specifies the amount of time to wait after booting before continuing with a scheduled installation that was missed previously for whatever reason (power outage, system powered off, network connection lost, and so on). If the status is set to Enabled, a missed scheduled installation will occur the specified number of minutes after the computer is next started. If the status is set to Disabled or Not Configured, a missed scheduled installation will simply roll over to the next scheduled installation.
No Auto-restart for Scheduled Automatic Updates Installations: This option designates whether a client computer should automatically reboot or not when an update that's just installed requires a system restart. If the status is set to Enabled, Automatic Updates will not restart a computer automatically during a scheduled installation if a user is logged in to the computer. Instead, it will notify the user to restart the computer to complete the installation. If the status is set to Disabled or Not Configured, Automatic Updates will notify the user that the computer will automatically restart in five minutes to complete the installation.
Automatic Update Detection Frequency: This option details the hours that Windows will use to figure out how long to wait before contacting the WSUS server to see if new updates are available. This time is actually determined by using the hours specified in this option and subtracting anywhere from zero to 20% of the hours specified. This offset helps to manage load. If the status is set to Enabled, you need to specify the number of hours; if it's set to Disabled or Not Configured, AU will check for new updates every 22 hours.
Allow Automatic Update Immediate Installation: This option specifies whether AU should automatically install updates that don't interrupt Windows or need a reboot. If you enable this option, AU will auto-install such updates; if you disable it, they will not be immediately installed.
Delay Restart for Scheduled Installations: This setting defines the amount of time AU will wait before executing a scheduled reboot. If this setting is enabled, the scheduled restart will happen after the number of minutes you specify. If this setting is disabled or not configured, the default waiting period is five minutes.
Re-Prompt for Restart with Scheduled Installations: If this setting is enabled, a scheduled restart will occur in the specified number of minutes after the prompt for restarting was postponed by the user. If this setting is disabled or not configured, the scheduled restart will take place ten minutes after the first prompt.
Allow Non-Administrators to Receive Update Notifications: If this setting is enabled, all users can receive notifications that updates are ready for download and/or installation. If this setting is disabled or not configured, AU will notify only logged-on administrators that pending update action is necessary.
Remove Links and Access to Windows Update: If this setting is enabled, end users cannot get updates from a Windows Update web site that you have not approved. If this policy is not enabled, the Windows Update icon remains in place for local administrators to visit. Such local administrators can in fact install unapprovcd updates.

You will want to allow 10 to 15 minutes for the changes to the domain's policy to replicate among all domain controllers. To manually initiate detection of these client machines, on the client, open a command prompt and type wuauclt.exe /detectnow.

To adjust the Group Policy on a machine that isn't managed by Active Directory, you need to load the appropriate templates into the Microsoft Management Console. Follow these steps:

Click Start, select Run, and type GPEDIT.msc to load the Group Policy snap-in.
Expand Computer Configuration and Administrative Templates.
Click Add/Remove Templates, and then click Add.
Enter the name of the Automatic Updates ADM file, which you can find in the INF subdirectory within your Windows root. In addition, you can find it in the INF subdirectory within the WSUS server machine's Windows root.
Click Open, and then click Close to load the wuau.adm file.

You can now adjust the policy settings as described in the previous subsection.

Finally, to adjust some of these behavior settings through Registry changes, use the appropriate key for each of the following settings:

To enable or disable Automatic Updates: Create the value NoAutoUpdate in the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD with possible values zero (enabled) or one (disabled).
To configure the update download and notification behavior: Create the value AUOptions in the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD that includes integers 2 (notify of download and notify before installation), 3 (automatically download but notify before installation), 4 (automatically download and schedule the installation), and 5 (let the local administrator choose the setting).
To schedule an automated installation: Create the values ScheduledInstallDay and ScheduledInstallTime in the key:
HKEY_LOCAL_ _MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value for each is a DWORD. For ScheduledInstallDay, the range is from 0 to 7, with 0 indicating every day and 1 through 7 indicating the days of the week, Sunday through Saturday. For ScheduledInstallTime, the range is from 0 to 23, signifying the hour of the day in military time.
To specify a particular WSUS server to use with the Automatic Updates client: Create the value UseWUServer in the key:
HKEY_LOCAL_MACHINE\_SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD; set it to 1 to enable the custom WSUS server name. Then, create the values WUServer and WUStatusServer in the same key, of types Reg_SZ, and specify the name (with the http://) as the value.
To specify how long to wait before completing a missed installation: Create the value RescheduleWaitTime in the key:
HKEY_LOCAL_MACHINE\_SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD that ranges from 1 to 60, measured in minutes.
To specify whether to restart a scheduled installation with a currently logged-in nonadministrative user: Create the NoAutoRebootWithLoggedOnUsers value in the key:
HKEY_LOCAL_ _MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD that can be 0, which indicates that a reboot will indeed take place, or 1, which indicates the reboot will be postponed while a user is logged on.

7.6.3. Using WSUS: On the Client Side

To configure Windows XP to work with WSUS, first enable the Automatic Updates feature. In Windows XP, do the following:

Open the Control Panel. Navigate to the System applet and open it.
Click the Automatic Updates tab.

In Windows 2000, do the following:

Open the Control Panel.
Navigate to the Automatic Updates applet and double-click it to open it.

You'll see the System Properties dialog box for the feature, as shown in Figure 7-18.

Figure 7-18. Configuring Automatic Updates on the client side

As the administrator, you select how updates are downloaded, signaled to the user, and subsequently installed on client machines. The currently logged-on user, if that person happens to have administrator credentials, is notified through a small update icon in the system tray as well as an information "bubble" that pops up when the download is complete. In addition, an administrator can determine if updates have been downloaded by looking at the system log. If the current user isn't an administrator, Windows will wait until one logs on to offer the notification that updates are available for installation.

7.6.3.1. Update download and installation

Updates are downloaded in a background thread by the Background Intelligent Transfer Service (BITS), which is an extension to Windows. BITS detects inactivity over a network connection and uses it to download large amounts of data from remote sites. BITS will detect when a user initiates activity over a connection and then pause the download process, waiting for the next idle period to resume it.

On the Automatic Updates property sheet, click the first option to have the currently logged-on user notified before downloading updates. The user will then be notified again before installing the downloaded updates. Use the second option if you want updates automatically downloaded, but want to wait until a logged-on user acknowledges their presence and authorizes the installation. Finally, click the third option if you want updates automatically downloaded and installed on a schedule that you can set in the boxes.

The update installation process proceeds depending on what you select in the boxes. When updates have finished downloading, the notification bubble will appear in the system-tray area of the machine, and an administrative user can double-click the bubble to open the Ready to Install dialog box, shown in Figure 7-19.

Figure 7-19. The Ready to Install dialog box

You can click the Remind Me Later button to defer the installation of updates for a set period of time, ranging from half an hour to three days from the current time.

If you've configured Automatic Updates to install fixes on a regular schedule, the updates will be downloaded in the background and automatically installed on that schedule. Automatic Updates installs the update and restarts the computer if an update requires that, even if there's no local administrator logged on. If an administrator is logged on, she will have the chance to cancel the process; if a normal user is logged on, he will receive a notification of the impending process and a countdown to its initiation. However, if updates have finished downloading between the configured install time and the current time, the notification will appear in the system tray as described earlier in this section. The user will not have the option to click Remind Me Later, but he can choose to install the updates at that time to have the process over with before the predetermined installation time.

7.6.3.2. Monitoring the client-side system

WSUS and the Automatic Updates client provide several event templates that are written to the system event log to describe the current status of the update process, any errors that are encountered, and a brief notation of what updates were successfully installed. You can program an event-log monitoring tool to monitor for certain event IDs that are specific to WSUS. This tool will give you a picture of your network's health with regards to updates. Table 7-3 lists these events and their meanings and contexts.

Table 7-3. WSUS and AU client event log messages
Event ID	Label	Description
16	Unable to connect	The client can't connect to either the Windows Update site, the Microsoft update site, or the WSUS server, but will continue trying indefinitely.
17	Install ready; no recurring schedule	Updates have been downloaded and are ready to be installed, but an administrator must log on and manually start the installation process.
18	Install ready, recurring schedule	Updates have been downloaded and are ready to be installed. The date this install is scheduled to occur is listed within the event description.
19	Install success	Updates have been successfully installed; these have been listed.
20	Install failure	Some updates didn't install correctly; these have been listed.
21	Restart required, no recurring schedule	Updates have been installed, but a reboot is required, and until this reboot is complete Windows cannot fetch more updates for installation. Any user can reboot the machine.
22	Restart required, recurring schedule	Updates have been installed, but a reboot is required and has been scheduled within five minutes.