Windows Update Services (WUS) is the new name for Software Update Services (SUS). Except it might not be. Last week, Thomas Lee (who is well placed to comment on such things, being both a Microsoft Regional Director and an MVP) quite rightly pointed out that WUS a) sounds bad; and b) is not an accurate description of what the product does.

For more information about SUS/WUS see SUSserver.com and the Windows Update Services Wiki.

I’ve spent the last few days working on a Microsoft Software Update Services (SUS) proof of concept for a client. In my last job, I implemented a hierarchy of SUS servers across Europe, to manage our Microsoft patch distribution. The system works – but it is a v1.0 product, and is somewhat limited in its management capabilities (for example, if one group of computers needs a different level of patching, then a separate SUS server must be used).

Introduction to SUS

SUS is a security toolkit component born out of the Microsoft Strategic Technology Protection Program (STPP), designed to help Microsoft customers help protect themselves after a number of widespread worms exploited vulnerabilities in Microsoft software. SUS enables administrators to quickly and reliably deploy the latest critical updates and security updates to Windows 2000 and Windows Server 2003-based servers, as well as to desktop computers running Windows 2000 Professional or Windows XP Professional.

In addition to critical and security updates, SUS now provides Windows service packs. SUS can be used to deliver Windows XP SP1, Windows 2000 SP4, and all future service packs for Windows 2000, Windows XP, and the Windows Server 2003 family of products.

How does SUS work?

SUS uses the automatic updates feature in Windows 2000 (SP3 or later), Windows XP (SP1 or later) and Windows Server 2003, but whereas normally, automatic updates are pulled from MicrosoftÂ’s Windows Update servers, SUS allows update requests to be serviced from internal servers.

Each SUS server can be configured to pull updates from the Microsoft Windows Update servers, or from other SUS servers within the organisation, allowing a hierarchy of servers to be established. Once downloaded, updates have to be approved by an administrator before they are released to clients. Approved updates are then pushed to clients and installed according to settings defined in an Active Directory group policy object (GPO) .

An interactive simulation of SUS is available on the Microsoft web site.

Client-side features

The client is based on the Windows automatic updates technology but with significant enhancements for improved manageability. Client-side features include:

• Guaranteed installation of approved updates: administrators can configure automatic updates to automatically download updates and schedule their installation for a specified time. If the computer is turned off at that time, the updates can be installed as soon as the computer is turned on.
• Scheduled installation options: administrators can be allowed to download and install updates manually. All other users are prevented from tampering with the installation of updates.
• Built-in security: before installing a downloaded update, automatic updates verifies that Microsoft has digitally signed the files.
• Accurate detection of necessary updates: the same technologies used for the Windows Update website scan a particular system and determine which updates are applicable.
• Background downloads: the background intelligent transfer service (BITS) – a bandwidth-throttling technology – is used to download updates. Because this technology uses only idle bandwidth, downloads do not interfere with other network activity.
• Chained installation: Windows update technologies are used to chain downloaded updates such that, if multiple updates are being installed and one or more of them requires a restart, they are installed together and a single restart requested.
• Manageability: within an Active Directory environment, an administrator can configure the behaviour of updates using group policy. Otherwise, an administrator can remotely configure automatic updates using registry keys through the use of a logon script or similar mechanism.
• Multi-language support: the client is supported on localised versions of Windows.

Server-side features

The SUS server service is based on the same technology used on the public Windows Update website that has been servicing Windows customers since 1998. Server-side features include:

• Windows critical updates, security updates, and service packs: SUS can be used to distribute Windows critical updates, security updates, and service packs for Windows 2000, Windows XP, and Windows Server 2003.
• Built-in security: the administrative pages are restricted to local administrators on the computer that hosts the updates. The synchronisation validates the digital certificates on any downloads to the update server. If the certificates are not from Microsoft, the packages are deleted.
• Selective content approval: updates synchronised to an SUS server are not made automatically available to the computers that have been configured to receive updates from that server. The administrator approves the updates before they are made available for download. This allows the administrator to test the packages before deploying them.
• Content synchronisation: an SUS server can be automatically or manually synchronised with the public Windows Update service. An administrator can set a schedule for the server to automatically synchronise at preset times. Alternatively, an administrator can manually synchronise.
• Server-to-server synchronisation: because administrators may need to run SUS on multiple servers inside an organisation in order to make the updates local to computers for downloading, SUS allows synchronisation from to another server running SUS instead of Windows Update. This allows for a single point of entry for updates into the network, without requiring that each SUS server download updates from the external Microsoft source. In this way, updates can be more easily distributed across the enterprise.
• Update package hosting flexibility: administrators have the flexibility of downloading the actual updates to their intranet site or pointing computers to a worldwide network of download servers maintained by Microsoft. Downloading updates directly might appeal to an administrator with a network closed to the Internet. Large networks spread over geographically disparate sites might find it more beneficial to use the Microsoft-maintained download servers. In this scenario, an administrator would download and test updates at a central site, then point computers requiring updates to one of the Windows Update download servers while maintaining control over which updates are installed.
• Multi-language support: although the SUS administrative interface is available in only English or Japanese, the server supports the publishing of updates to multiple operating-system language versions. Administrators can configure the list of languages for which they want to download updates.
• Remote administration via HTTP or HTTPS: the SUS administrative interface is web-based and therefore allows for remote (internal) administration using Internet Explorer 5.5 or later.
• Update status logging: administrators can specify the address of a web server where the automatic updates client should send statistics about updates that have been downloaded and whether the updates have been installed. These statistics are sent using the HTTP protocol and appear in the Microsoft Internet Information Services (IIS) log file of the web server.

SUS group policy object settings

The SUS group policy object settings are defined in a single administrative template file, wuau.adm.

Future enhancements

According to Microsoft’s FYI publication, Microsoft is looking to improve the patching experience through further integration of the many channels through which updates are issued, improved Windows Installer (MSI) technology and SUS v2.0, which is currently due for a Summer 2004 release with a number of benefits including:

• SUS administrators will be able to uninstall updates.
• Forced patch application (by a certain date).
• Improved granularity in scheduling downloads.
• Better reporting tools.
• Support for Office 2003, SQL Server, Exchange Server and critical driver updates.

For anyone having difficulty diagnosing issues with Microsoft Software Update Services (SUS), I’ve produced a SUS troubleshooter diagram. In addition, the following resources may be useful:

• SUSServer.com.
• SUS statistics report (for analysing IIS logs).

Following on from my overview of Microsoft Software Update Services (SUS), this post suggests some best practices that should be applied to patch management using SUS.

Check daily for correct SUS synchronisation

Each day, the Microsoft Software Update Services administrative tool should be used to view the synchronization log. This will indicate if there were communications issues when the SUS server attempted to download updates. Sometimes this may be caused by a temporary network or server outage and the synchronisation process can be re-run.

Test updates before approval

Before approving updates, they should be fully tested on using reference PCs away from the production network. All updates that have been downloaded from the Microsoft Windows Update servers to SUS will be available at c:\inetpub\sus\content\. The level of testing required must be set to satisfy the organisation’s internal requirements. Generally there will not be problems with other Microsoft products (and any such problems will be well publicised); however updates should ideally be integration tested against the desktop standard operating environment (SOE) including any third-party products in use.

Even if the network is protected from an Internet-based attack, laptop users are always vulnerable, and in general, the risk associated with the application of a critical update is lower than the risk of not applying that patch.

Examine the IIS logs

IIS maintains log files of all client requests. Although complex, these can be found at %systemroot%\system32\logfiles\w3svc1\. A tool for examining IIS logs is available on the Internet and will show clients contacting the server and downloading updates.

Small logs may indicate a problem with client downloads but could also indicate that there are no updates to be downloaded at that time.

Examine the client logs

When updates have recently been approved, examining %systemroot%\windows update.log will confirm whether or not updates have been successfully downloaded to a client. Spot checks can be used to check that the SUS process is performing well.

A successful download will be recorded similarly to the following:

2004-02-13 14:05:09 14:05:09 Success IUCTL Starting
2004-02-13 14:05:09 14:05:09 Success IUCTL Downloaded iuident.cab from http://susservername.domainname.com to C:\Program Files\WindowsUpdate\V4
2004-02-13 14:05:09 14:05:09 Success IUENGINE Starting
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:10 14:05:10 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:10 14:05:10 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:11 14:05:11 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:11 14:05:11 Success IUENGINE Determining machine configuration
2004-02-13 14:05:12 14:05:12 Success IUENGINE Querying software update catalog from
2004-02-13 14:05:12 14:05:12 Success IUENGINE Determining machine configuration
2004-02-13 14:05:12 14:05:12 Error IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdatedrivers/getmanifest.asp (Error 0x80190194)
2004-02-13 14:05:12 14:05:12 Success IUENGINE Shutting down
2004-02-13 14:05:12 14:05:12 Success IUCTL Shutting down
2004-02-13 14:11:05 14:11:05 Success IUCTL Starting
2004-02-13 14:11:05 14:11:05 Success IUENGINE Starting
2004-02-13 14:11:05 14:11:05 Success IUENGINE Install started
2004-02-13 14:11:07 14:11:07 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:07 14:11:07 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:26 14:11:26 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:26 14:11:26 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:45 14:11:45 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:45 14:11:45 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:49 14:11:49 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:49 14:11:49 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:13:09 14:13:09 Success IUENGINE See iuhist.xml for details: Install finished
2004-02-13 14:13:09 14:13:09 Success IUENGINE Shutting down
2004-02-13 14:13:09 14:13:09 Success IUCTL Shutting down

The error message in the transcript above can be ignored as SUS cannot serve driver updates (unlike Microsoft’s public Windows Update servers, for which the automatic updates client is also used).

Check for security misconfigurations

The Microsoft Baseline Security Analyzer (MBSA) should be run periodically to check for security issues. For example, if a workstation has not been restarted after updates have been applied, then it will not download new updates from SUS. MBSA will highlight workstations which are not fully patched.