Endpoint Protection

In the previous installment of this article, I discussed SUS, its purpose, and some of the workings on the server side, including how to push out the Automated Updates client.   In this segment, you'll learn what happens on the client computers when SUS is active, how to monitor the client's patching activities, and how to fix or work around some common problems.   I'll also introduce two "poor man's" methods for analyzing SUS log files.

Using SUS: On the Client Side

To configure Windows XP to work with SUS, first enable the Automatic Updates feature. In Windows XP, open Control Panel, open the System applet, and click on the Automatic Updates tab.   In Windows 2000, open Control Panel, and open the Automatic Updates applet.

You will see the properties screen for the feature.   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.   As well, an administrator can determine if updates have been downloaded by looking at the system log.

Update Download and Installation

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

The update installation process proceeds depending on the above selection, the options for which were covered in the previous installment of this article.   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 on the bubble to raise 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 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 there is no local administrator logged on. If an administrator is logged on, he 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, between the set install time and the current time, if updates have finished downloading the notification will appear in the system tray much like 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.

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" object set when dealing with code that isn't signed, you will run into problems with some updates.   Microsoft occasionally releases unsigned code updates, and since 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 come since the installation is unattended, so AU simply stops.   If you encounter this issue, you need to kill the running update processes using a tool like Sysinternals' Process Explorer.   The built-in Windows Task Manager refuses to touch it.

Also, some machines experience an "obsession" over certain patches, which may or may not be caused by SUS but also isn'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 will typically repair the problem.

If your SUS server doesn't synchronize correctly, make sure the server itself 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 (non-browseable) URLs:

• http://www.msus.windowsupdate.com
• http://download.windowsupdate.com
• http://cdm.microsoft.com

You may 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 themselves at other times during the day, and then manually copy them to the 'SUS content\cabs' folder on the server itself.   Finally, rename those files to w2ksp4_en_7f12d2da3d7c5b6a62ec4fde9a4b1e6.exe and XPSP1A_8441053935ADBFC760B966E5E413D3415A753213.exe respectively.   You can now continue using SUS without worrying about SUS failing on service pack downloading attempts.

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

1. • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\DetectionStartTime
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\LastWaitTimeout

You can also refresh the Windows Automatic Updates service from the command line by stopping it using net stop wuauserv , following 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 C:\Windows\Windows Update.log for activity.

NOTE: You have to leave the system alone after that 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 downloading them, you can check out the status of any downloads using the Background Intelligent Transfer Service administrative utility, located in the Support directory on an XP CD.   Install that, and then after clicking on 'Start Download' in the AU client interface when it notifies that updates are ready to install, open a Command Prompt and type bitsadmin /list /allusers /verbose.   It may 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 result if it can't access it.

Monitoring the Client-Side System

Software Update Services 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.   The following table lists these events and their meanings and context.

Table 1: SUS/AU Client Event Log Messages

Logs

The SUS server will record an entry to the synchronization log whenever the server attempts to connect to its upstream provider.   This log can be accessed from the SUS administrative web site using any standard web browser; it can also be accessed directly from the SUS host machine in the autoupdate\administration directory of the SUS website -- the file name is history-Sync.xml.   The log entry contains the time of the last synch, whether the operation was complete, 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 can be found in the same place as the synchronization log with the file name history-approve.xml.

On the client side, essentially all client machines perform a standard HTTP GET request of the SUS server for a file named wutrack.bin, including a series of parameters which comprise the information on a client's status.   For example, an entry into the standard log might read:

2004-02-09 09:09:41 192.168.0.121 - 80 GET /wutrack.bin
V=1&U=63a9dfd44a7aca47ade26684ed5fe66a&C=iu&A=n&I=&D=&P=5.1.1677.2.0.1.
0&L=en-US&S=s&E=00000000&M=&X=031101050105756 200 Whistler+Update+Control+Pack

You can see the individual parameters, although some are coded specifically to be obscured.   One of the drawbacks of using SUS is the deficiency of its log analysis capabilities.   SUS will write a log in a standard IIS log format, but there's no utility available from Microsoft to directly import these logs and make it generally useful to an administrator.   To that end, several homegrown scripts have grown out of this problem, including one by Ken Hoover, a systems programmer at Yale University.   He has created some Perl scripts that analyze the log for patterns that match certain pertinent information.  

Ken Hoover's scripts will parse this information and give various reports on the data contained therein, including a count of the machines that have contacted the SUS server, a count delineated by the current operating system version, a comparison between a list of systems you create and ones that aren't found in the log files (useful if you're trying to determine if a system is actually contacting the SUS server), a list of machines that haven't yet installed a particular hot fix, or a detailed breakdown of all activity on a particular hot fix or a specific machine's IP address.

Hoover's scripts work with any Perl implementation, including ActiveState Perl on Windows, and they have no client dependencies -- they work exclusively with the log files on the server.   The scripts can be found at Hoover's website.

If you're looking for a bit more detailed reporting, Wayne Flynn has created the SUSReporting tool, available at http://www.susserver.com.   This tool parses IIS log files, imports them into Microsoft SQL Server, and presents a web-based report of activity through some custom ASP scripts.   The default report available is for all activity during the last 72 hours, although data is maintained perpetually within the SQL database and you can simply add a parameter to the script (?days=x) to access data for more days than the default.   The downside, of course, to this method is that you need SQL Server for the built-in scripts to work out of the box.  

In the Next Installment

In these two segments, I've discussed SUS in-depth, including how it functions, its advantages and limitations, and how to work around some problems you may encounter during use.   In the final segment, I'll introduce some freeware and commercial tools, preview their functionality and limitations, and make some recommendations of places to look for further information and resources.