|
7.5. About Software Update ServicesPatch 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.
7.5.1. Using SUS: On the Server SideSUS installation comprises two phases. First, you should download and install the software:
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 pageThe 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.
7.5.1.1 Synchronizing and approving contentWhen 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:
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 machineSet 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:
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 clientIf 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.
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.
Open the Active Directory Users and Computers MMC snap-in, and then do the following:
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 perspectiveThe 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:
Figure 7-14. GP options for SUS and AU
Here's a detailed description of each option.
To modify these settings on a machine that is not a member of an Active Directory domain, follow these steps:
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.
7.5.2. Using SUS: On the Client SideTo configure Windows XP to work with SUS, first enable the Automatic Updates feature. In Windows XP, do the following:
In Windows 2000, follow these steps:
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 2000You, 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.
7.5.2.1 Update download and installationThe 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 UpdatesYou 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 systemSUS 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.
7.5.3. Common Problems and WorkaroundsUsing 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:
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.
If you are trying to debug client-side SUS problems that might present themselves, consider clearing the SUS-related registry keys:
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.
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.
|
|