Section 7.5. About Software Update Services

7.5. About Software Update Services

Patch management is one of the most difficult but necessary tasks an administrator faces in the wake of viruses and security vulnerabilities that plague our connected world today. However, even though Microsoft operating systems have been the target of many a hacker and virus writer for the past five years or so, there hasn't been a Microsoft-endorsed, low-cost method of distributing operating system updates to an installed base of computersincluding both clients and servers.

That changed in 2003. As part of its Strategic Technology Protection Program, Microsoft sought to use its popular Windows Update technologythe software that runs the universal update site for all but the oldest versions of Windows. The result of this effort was a new free product called Software Update Services, or SUS. SUS at this point does not focus on adding new features to already released software; it is concerned only with critical updates, allowing administrators to easily deploy critical updates to servers running Windows 2000 or Windows Server 2003, as well as desktop computers running Windows 2000 Professional or Windows XP Professional. All in all, SUS deals with pretty much the same set of updates available from Windows Update, which most people are familiar with. It's designed to work especially well in networks with an Active Directory implementation (and you even can install SUS on a domain controller), but it will function without one.

You need the following to install and use SUS on your network.

One server connected to the Internet running the actual server component of SUS

This machine acts as a local version of the public Windows Update site, containing critical updates and service packs for all supported operating systems. This server synchronizes with the public Windows Update site on a schedule, which the corporate administrator selects, and then that administrator approves or rejects the availability of certain updates on the SUS server. You also can have multiple SUS servers on an intranet and configure which client machines are directed to specific SUS servers for updates. Each SUS server needs to have IIS installed, and anonymous access should be granted on the IIS root of the SUS server. Of course, take care here to lock down IIS 6 using some of the information discussed in Chapter 8.

The Automatic Updates feature of Windows 2000 Service Pack 3 and higher or Windows XP Professional at any revision level

Directed by a registry change or by an applied GPO, the client computers that are running this automatic updates feature are sent to the local network's SUS server on a set schedule to download updates appropriate to their machines. The SUS server will analyze the operating system, service pack level, and currently installed updates and push only those updates which are both needed and approved by the administrator beforehand.

7.5.1. Using SUS: On the Server Side

SUS installation comprises two phases. First, you should download and install the software:

1. Go to the SUS web site at http://www.microsoft.com/sus.

2. Download Sus10sp1.exe to a folder on the server where you want to either install SUS 1.0 SP1 or apply the service pack to an existing installation of SUS 1.0.

3. Double-click the file using the server on which you want to install or upgrade SUS.

4. Click Next on the Welcome screen to continue.

5. Decide whether to accept or reject the license agreement, and click Next.

6. Select the Typical checkbox unless there's a good reason for you to use a custom installation. Click Next.

7. Make a note of the location with which you can direct clients to SUS. Click Install to begin the actual file copy.

8. When the file copy finishes, make a note of the location of the SUS administrative pages. Then click Finish to exit the wizard.

The administrative web site for SUS will open. The default address for these pages is /SUSAdmin">http://<SUSServerName>/SUSAdmin. You also can navigate through Start All Programs Administrative Tools, and click Microsoft Software Update Services. You'll see something much like that shown in Figure 7-12.

Figure 7-12. The SUS administrative web site home page

The first step is to configure the options for your SUS server. In the left pane, click Set Options. Here's a description of the sections on this page.

Select a proxy server configuration

You use this option to tell SUS whether to connect to the Windows Update web site using a proxy server or to use a direct Internet connection. Fill out this form with settings similar to how you configure Internet Explorer.

Specify the hostname your clients use to locate this update server

Here you configure how the server will respond to update requests from client computers on your network. This is useful if you have a SUS server on a machine that is hosting other web sites with IIS; this option helps to separate requests for SUS from requests for other sites being served on the machine. I recommend using the full DNS name here and not just a NetBIOS name for maximum compatibility and performance.

Select which server to synchronize content from

Here you can instruct SUS to download updates directly from the public Windows Update site, from another SUS server located somewhere on your network, or from a manually created network share. You also can select whether to use the list of approved updates from other SUS servers, or to use only that server's store in tandem with the local server's list of approved updates.

Select how you want to handle new versions of previously applied updates

If a new version of a patch or other hotfix is issued, here's where you can select whether to automatically approve the revision for distribution, or treat it as a new patch that an administrator needs to approve manually.

Select where you want to store updates

You can select whether to download the updates from Windows Update in real time or batch-download them and store them on the SUS server. You also can select the localities for which you'd like to store critical updates and security hotfixes. (I've found that this filter doesn't always work as expected. Sometimes updates in other languages are stored regardless of the settings I've configured; of course, your mileage may vary.)

7.5.1.1 Synchronizing and approving content

When you start the content synchronization process, the SUS server goes out to either the public Windows Update servers or another local SUS server (as configured in the Set Options section) and downloads the entire library of available critical updates and service packs for each language you have configured. This synchronization usually results in about 150MB of data being transferred for just English updates, or close to 600MB for updates in every localization.

To synchronize content, open the SUS administration web site and then do the following:

1. In the lefthand navigation pane, click Synchronize server.

2. Click the Synchronize now button in the right pane to begin the transfer.

You also can opt to schedule your synchronizations automatically so that you don't have to remember to resynchronize every time a new update is released. On the Synchronize server page, click Synchronization schedule. A dialog box such as that shown in Figure 7-13 will appear.

Figure 7-13. Setting a synchronization schedule for the SUS host machine

Set your desired options for synchronization and then click OK. Be aware that if the SUS server can't connect to the appropriate upstream update source, it will repeat its attempts four times, spacing out each attempt by half an hour. You can adjust this using the Number of synchronization retries to attempt on a scheduled synchronization failure drop-down box on the Schedule Synchronization dialog box.

Now that you have an actual library of updates on or near your SUS host machine, 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, partly assuaging the general fear that's caused by installing patches that might cause more problems than they fix. To begin the update approval process, follow these steps:

1. In the navigation pane, click Approve updates.

2. In the righthand pane, select the updates that you want to approve, and click Approve when you've finished your selection.

SUS 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 has not been approved yet. An approved update is available for distribution to client machines. An update that is not approved will not be distributed to clients, but the actual patch file remains in the library on the SUS 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 file was downloaded incorrectly, could not be found, or is otherwise unable to be located by SUS.

If, for some reason, you want 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 SUS 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.

The SUS server will record an entry to the synchronization log whenever the server attempts to connect to its upstream provider. You can access this log from the SUS administrative web site using any standard web browser; you also can access it directly from the SUS host machine in the autoupdate\administration directory of the SUS web sitethe filename is history-Sync.xml. The log entry contains the time of the last synch, whether the operation was completed, the date and time of the next scheduled synchronization, the contents of the operation and whether each component was successfully installed, and whether the synchronization was routine or manual.

The SUS server also keeps a log of all approved updates, which you can find in the same place as the synchronization log with the filename history-approve.xml.

7.5.1.2 Pushing out the Automated Updates client

If you are upgrading an installation of SUS 1.0, the Automatic Update software installed on your client computers will self-update to the latest SUS 1.0 SP1 client software. This will occur after the SUS 1.0 server has been successfully updated to SP1 and synchronized with the latest content available on the Windows Update servers.

You can install the updated Automatic Updates client on your clients using the Microsoft Installer (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 installing Windows Server 2003.

You can download the Automatic Updates client from the Microsoft web site at the SUS web page, located at http://www.microsoft.com/sus. On a standalone machine, you can add the Automatic Updates client by running the WUAU22.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, with the client installation program being in the form of an MSI, you can easily push the program to clients by using GP. To create a new GPO, assign it to your computers and then have it installed automatically.

The application will be installed in the context of the local computer, so be sure that authenticated users have rights on the source folders.

Open the Active Directory Users and Computers MMC snap-in, and then do the following:

1. Right-click the domain or organizational unit to which you're interested in deploying the client, and select Properties.

2. Click the Group Policy tab.

3. Click New to create a new GPO. Type in a name for the GPO.

4. Select the new GPO from the list, and click Edit to open the Group Policy Object Editor.

5. Expand Computer Configuration, and then select Software Settings.

6. Right-click Software Installation in the left pane, select New, and then click Package.

7. Enter the path to the WUAU22.msi. Make sure you use a network path and not a local path to ensure your clients can find the file at boot time. Click Open.

8. Choose Assigned to assign the package to the computers in the domain or organizational unit, and then click OK.

9. Allow time for polices to replicate through the domain. Usually this is accomplished within 15 minutes.

10. Restart the client computers. The client software should be installed before the logon dialog box is displayed.

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

7.5.1.3 Configuring the Automatic Updates client from a server perspective

The Automatic Updates client does not have any user interface options for determining the origin of updates to install. You must set this via either a registry change on each client computer or through GP, either locally or based through a domain.

Through a domain-based GP, direct clients to the SUS server using the following procedure:

1. Open the Default Domain Policy GPO in Active Directory Users and Computers and click the Edit button.

2. Expand Computer Configuration Administrative Templates Windows Components.

3. Select Windows Update. The right pane will contain four options that pertain to the Automatic Updates client, as depicted in Figure 7-14.

Figure 7-14. GP options for SUS and AU

You will want to allow 10 to 15 minutes for the changes to the domain's policy to replicate among all domain controllers, or manually initiate replication via Active Directory Sites & Services as you learned in Chapter 5.

Here's a detailed description of each option.

Configure Automatic Updates

This option specifies whether this computer will receive security updates and critical bug fixes. The first option has the currently logged-on user notified before downloading updates, and notified again before installing the downloaded updates. The second option has updates automatically downloaded, but not installed until a logged-on user acknowledges his presence and authorizes the installation. The third option has updates automatically downloaded and installed on a schedule that you can set in the appropriate boxes on the sheet. To use this setting, click Enabled, and then select one of the options.

Specify intranet Microsoft update service location

This option designates a SUS 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.

Reschedule Automatic Updates scheduled installations

This option specifies the amount of time to wait after boot 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 when an update that is 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 notifying 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.

To modify these settings on a machine that is not a member of an Active Directory domain, follow these steps:

1. Click Start, select Run, and type GPEDIT.msc to load the GP snap-in.

2. Expand Computer Configuration and Administrative Templates.

3. Click Add/Remove Templates, and then click Add.

4. Enter the name of the Automatic Updates .ADM file, called WUAU.ADM, which you can find in the INF subdirectory within your Windows root. You also can find it in the INF subdirectory within the SUS server machine's Windows root.

5. Click Open, and then click Close to load the template.

Now you can adjust the policy settings as described in the previous subsection.

Finally, to modify some of these settings through the registry, do the following.

To enable or disable Automatic Updates

Create the value NoAutoUpdate in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key. The value is a DWORD with the possible values 0 (enabled) or 1 (disabled).

To configure the update download and notification behavior

Create the value AUOptions in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key. The value is a DWORD that includes the following integers: 2 (notify of download and notify before installation); 3 (automatically download but notify before installation); and 4 (automatically download and schedule the installation).

To schedule an automated installation

Create the values ScheduledInstallDay and ScheduledInstallTime in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key. 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, respectively. For ScheduledInstallTime, the range is from 0 to 23, signifying the hour of the day in military time.

To specify a particular SUS server to use with the Automatic Updates client

Create the value UseWUServer in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key. The value is a DWORD; set it to 1 to enable the custom SUS 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 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key. 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 that the reboot will be postponed while a user is logged on.

7.5.2. Using SUS: On the Client Side

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

1. Open the Control Panel. Navigate to the System applet and open it.

2. Click the Automatic Updates tab.

   

   On systems with XP Service Pack 2 installed, you can find this through the Security Center in the Control Panel.

   
   

In Windows 2000, follow these steps:

1. Open the Control Panel.

2. Navigate to the Automatic Updates applet and double-click to open it.

You will see the properties screen for the feature, which is depicted in Figure 7-15.

Figure 7-15. Automatic Updates in Windows XP and Windows 2000

You, as the administrator, 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 updates' download is complete. If the updates are not configured to automatically download, a similar bubble will appear notifying the current user of the availability of new updates. As well, an administrator can determine if updates have been downloaded by looking at the system log on the client itself. If the current user is not an administrator, Windows will wait until an administrator logs on to offer the notification that updates are available for installation.

If you configure these update settings through GP, the user can see the settings, but they will be grayed out and the user won't be able to change them through the user interface.

7.5.2.1 Update download and installation

The updates are downloaded in the session's background by the Background Intelligent Transfer Service (BITS) 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 will pause the download process, waiting for the next idle period to resume it.

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

The update installation process proceeds depending on the preceding selection. 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 raise the Ready to Install dialog box, featured in Figure 7-16.

Figure 7-16. Installation dialog for Automatic Updates

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

If you have 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 no local administrator is logged on. If an administrator is logged on, he will have the chance to cancel the process; if a user without administrative privileges logged on, he will receive a notification of the impending process and a countdown to its initiation. However, between the set install time and the current time, if updates have finished downloading, the notification will appear in the system tray much as described just 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.5.2.2 Monitoring the client-side system

SUS 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 SUS to have a picture of your network's health when it comes to updates. Table 7-3 lists these events and their meanings and context.

Table 7-3. SUS/Automatic Updates client event log messages

Event ID	Source	Type	Label	Description
16	Automatic Updates	Warning	Unable to connect	The client can't connect to either the Windows Update site or the SUS server, but will continue trying indefinitely.
17	Automatic Updates	Information	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	Automatic Updates	Information	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	Automatic Updates	Information	Install success	Updates have been successfully installed; these have been listed.
20	Automatic Updates	Error	Install failure	Some updates did not install correctly; these have been listed.
21	Automatic Updates	Information	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	Automatic Updates	Information	Restart required; recurring schedule	Updates have been installed, but a reboot is required and has been scheduled within five minutes.

7.5.3. Common Problems and Workarounds

Using policy settings that control installation of unsigned software can interfere with the ability of the Automatic Updates client to do its job. In particular, if you have the Warn but allow installation option within Software Restriction in GP set when dealing with code that isn't signed, you will run into problems with some updates. Microsoft occasionally releases unsigned code updates, and because Windows is instructed to prompt for a warning, the procedure stops, waiting for confirmation that it's OK to install the update. Of course, this confirmation can never occur because the installation is unattended, so Automatic Updates simply stops. If you encounter this issue, you need to the running update processes (normally named IUENGINE) using a tool such as Sysinternals' Process Explorer (you can find this at http://www.sysinternals.com). The built-in Windows Task Manager won't let you it.

Also, some machines experience an "obsession" over certain patches, which might or might not be caused by SUS but also aren't limited to SUS itself. If a machine tends to require the same patch repeatedly, using both SUS and a manual visit to the Windows Update web site, the best course of action is to clear Internet Explorer's cache: this typically will repair the problem.

If your SUS server doesn't synchronize correctly, make sure the server isn't sitting behind a prohibitively tight firewall. To synchronize, SUS only requires communication through port 80, but it also must be able to access the following (nonbrowseable) URLs:

• http://www.msus.windowsupdate.com

• http://download.windowsupdate.com

• http://cdm.microsoft.com

You might also be having a problem, particularly on a low-bandwidth connection, where the currently available service packs are choking your Internet pipe and causing the synchronization process to fail. To turn off the service packs, download the service packs from Microsoft using any web browser at other times during the day, and then manually copy them to the SUS content\cabs folder on your SUS server. Using Windows 2000 Service Pack 4 and Windows XP Service Pack 1 as examples, rename those downloaded files to w2ksp4_en_7f12d2da3d7c5b6a62ec4fde9a4b1e6.exe and XPSP1A_8441053935ADBFC760B966E5E413D3415A753213.exe, respectively. Now you can continue using SUS without worrying about SUS failing on service pack downloading attempts.

Future service pack releases will have their own codes, which you will need to confirm with Microsoft before deploying this way.

If you are trying to debug client-side SUS problems that might present themselves, consider clearing the SUS-related registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\WindowsUpdate\Auto Update\DetectionStartTime

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\LastWaitTimeout

You also can refresh the Windows Automatic Updates service from the command-line by stopping it using net stop wuauserv, followed by net start wuauserv. These steps usually solve most client-side SUS problems; to verify things are back to normal, wait 15-30 minutes and then inspect the file %SystemRoot%\Windows Update.log for activity.

You have to leave the system alone after you clear the registry keys and restart the AU services, or BITS will never detect a system idle enough to synchronize updates from the SUS server.

If it seems like the Automatic Updates client is simply frozen and lists updates that are available but it never actually downloads them, you can check out the status of any downloads using the BITS administrative utility, located in the Support directory on an XP CD. Install that, and then after clicking Start Download in the Automatic Updates client interface when it notifies that updates are ready to install, open a command prompt and type bitsadmin /list /allusers /verbose. It might display information on download attempts and why they're failing. It's also prudent to ensure that anonymous access is granted on the IIS root of the SUS server, and that the SUS folder (and in particular, the SUS\Content\Cabs folder) grants everyone access. BITS attempts to download from that Cabs folder and issues would arise if it can't access it.

By early 2005, the next version of SUS will be released, and will be renamed to Windows Update Services. Keep the jokes about the acronym that creates to yourself.