Useful Links:

Microsoft Software Update Services
(SUS)

Software Update Services (SUS) is a free tool provided by Microsoft that allows you to implement a local source for hotfixes and other system updates to Windows 2000 and higher clients using the "Automatic Updates" service.

SUS is hosted on a Windows 2000 or higher server.  The administrator of the server configures it to check periodically with Microsoft's servers for new updates and fixes which are downloaded to the SUS server.  The admin must approve new updates before they become available to client machines.

Clients are configured via group policy to contact the designated SUS server and then take whatever action the administrator wants, including automatically installing any updates that are found at a specified time.

Last Update : Fri Jul 8 14:44:26 2005

Some common questions about SUS

• What can SUS do for me?

• What are the server requirements?  Does it need a dedicated machine?

• What systems are supported as clients?

• What kinds of updates does SUS handle?  

• How do I configure clients to use SUS?

• Can I control what updates the clients receive?

• Don't some hotfixes require a reboot?

• How (and when) do clients retrieve the updates?

• What about machines that are powered off at the designated time?

• How can I have machines "opt out" of using SUS?

• Is SUS already in use at Yale?

• Should I run my own SUS server?

• I'd like to try updating some of my clients via SUS but don't want to set up a SUS server myself.

• How can I verify that SUS is working on my clients?

• Does the SUS server keep any logs of client activity? 

• Gotchas and glitches 

What can SUS do for me?

SUS is a way for administrators to keep targeted machines up to date with "approved" hotfixes and other operating system updates that Microsoft designates as important. This provides three major benefits:

1. The list of updates to be installed on a client is managed by the SUS server's administrator so updates which have not been tested aren't installed on clients.

2. Client machines do not need to contact Microsoft directly to get their updates, reducing demand on the link to the internet.

3. Updates can be installed automatically without user interaction.

What are the server requirements?  Does it need a dedicated machine?

SUS requires a server with sufficient disk space to hold all of the updates that it downloads from Microsoft.

SUS is an IIS-driven service but it also makes changes to IIS on installation in ways that "break" other web sites hosted from the same server. This means that SUS could be hosted on a machine that is not already running IIS but it's best to give SUS a dedicated server.

SUS is not a high-load service so even a modest machine can support a very large number of clients.  Microsoft documentation indicates that a PIII-700 server with 512MB of RAM can support up to 15,000 client systems.

What systems are supported as clients? 

SUS functions as as a local server for the Automatic Updates service for Windows machines.  Automatic Updates is supported on Windows 2000 SP2 and higher, and is installed as part of Windows 2000 SP3 and SP4. The Automatic Updates client is included with Windows XP and Windows Server 2003.

If you have Windows 2000 SP2, you can download the automatic updates client from the link above. A better choice would be to update your machine with a newer service pack.

What kinds of updates does SUS deliver?

According to Microsoft's SUS FAQ, SUS delivers these kinds of updates:

• Windows Critical Updates
• Windows Critical Security Updates
• Windows Security Roll-ups
• Service Packs
• Other updates and tools distributed by Microsoft

Note that SUS does not deploy updates or service packs for applications, such as for Microsoft Office or SQL server.

The next version of the server named "Windows Update Services" will deliver updates for Microsoft Office applications as well as layered server products like SQL Server. WUS is still in "beta" is not expected to be available until 1Q 2005 at the earliest.

How do I configure clients to use SUS?

Clients are configured via group policy with two parameters: the address of the SUS server to contact, and what to do with any updates that are received from that server.

The name of the server is specified as a URL. The choices on what to do with the updates are the same as when manually configuring automatic updates:

1. Notify that updates are available so download can be initiated manually
2. Download updates automatically and notify when they are ready for install
3. Download and apply updates automatically at a designated time.

For the third option (install automatically), the administrator can specify the time that the updates are installed.  If necessary, a reboot will be forced on the target machine.

When a client system is configured this way via group policy, the "Automatic Updates" control panel applet is completely "grayed out":

Can I control what updates the clients receive?

The administrator of the SUS server must manually approve all new updates that are received from Microsoft. Until updates are approved, they are not propagated to clients.

Microsoft also occasionally updates hotfixes so SUS has the option to automatically approve updates to already-approved hotfixes, or require the updated versions to be manually approved as well.

Don't some hotfixes require a reboot?

Not all updates require a reboot, but many do.

If a reboot is needed to complete a hotfix that is being automatically installed, the automatic updates service will force one.

If a user is logged on at the designated time, a dialog box will be displayed at the console showing a 5-minute countdown. If the user is an Administrator they will be able to abort the countdown. Non-Administrators will not be able to stop the countdown before the reboot is forced.

This means that users who frequently do long-running unattended tasks on their machines may risk disruptionby if the machine reboots while they are running.

How (and when) do clients retrieve the updates?

When clients are configured to contact a SUS server, they use a random time within a 22-hour cycle to check for updates.  Downloads are performed using the BITS service, which handles resumable downloads.  Once all of the updates are retrieved, the client waits until the designated time to install them.

The time specified in the automatic updates control panel is when the clients apply the updates, not the time that they check for updates.

What about machines that are powered off at the time I specify?

By default, if a machine is offline and "misses" an update cycle, it will wait until the next scheduled one.

Optionally, machines can be configured to go ahead with the installation after a configurable time delay when they are restarted.

I have a user in my department who doesn't want their system to be rebooted remotely. How can I have machines "opt out" of SUS?

Since SUS is configured via group policy, the usual tricks for controlling the scope of group policy apply.  Two options are:

1. Create a group of machines that want to "opt out" of being serviced by SUS and set "deny" on the "Apply Group Policy" ACE for that group of machines.  See this link on filtering group policy application for more information on how to do this.  Note that the members of the group are the computer objects, not the users since automatic updates runs under the identity of the computer and not the user.

2. Separate your OU into two groups of machines - one that is serviced by SUS and another that is not. Move machines that are "opting out" into the second OU so they are not covered by the policy.

There are other ways to do this, these are only a couple of examples.  #1 is the cleanest but takes some testing to get it working right if you haven't done it before.

Is SUS already in use at Yale?

Yes, as of June 2004 approximately 4,500 Windows systems are being updated via SUS.

At the moment, there are approximately a half-dozen SUS servers at Yale, administered by several different departments.

There is a mailing list administered by Desktop Services that is used for coordination among SUS server admins.

Should I run my own SUS server?

According to Microsoft's numbers, a single SUS server could easily support all of Yale's Windows machines.

However, client machines have different management and different tolerances for hotfix levels because of local configuration.  For example, a department may have an application which is known to "break" if a certain hotfix is applied.

It's best to see if you can use an existing SUS server to avoid duplication.

I'd like to try updating some of my clients via SUS but don't want to set up a SUS server myself.

If you want to test SUS, apply the policy named "Ken's SUS Policy (amt-sus1.its.yale.edu)" to an OU containing machines that you want to test it on. 

This policy configures targeted machines to use the SUS server amt-sus1.its.yale.edu and sets them automatically install any updates they find at 3:00am daily.

Ken Hoover (from ITS AM&T) administers this SUS server.  Please email him if you have any questions about it.

By applying this policy to your OU, you are agreeing to abide by the judgement of the SUS server's administrator about which updates should and should not be  made available to client systems. 

How can I verify that SUS is working from the client side?

Clients will contact the associated SUS server within a randomly-chosen 22 hour period to request the list of updates.  To verify that a client is contacting the SUS server, look in the file on the client in %systemroot% called "Windows Update.log".  This log file is where the client records its activity.  There should be entries in there at regular intervals showing the client's interaction with the server.

The client-side service is called "Automatic Updates".  If the client is not checking in with the SUS server, restart the Automatic Updates service (or reboot the machine).  Also make sure that the "Background Intelligent Transfer Service" is running.  This service is sometimes referred to as "BITS".  If this service is not running then the client will not be able to retrieve any updates from the server.

Does the SUS server keep any logs of client activity? 

SUS clients report status information back to the server they are drawing updates from by sending HTTP GET requests with a series of parameters that represent status information.

These parameters are documented in pages 82-92 of Microsoft's SUS Deployment Guide and can be used by parsing the IIS server's log files to extract useful information.

Ken Hoover from AM&T has put together a web page with some Perl scripts which demonstrate how this information can be used in various useful ways.  The algorithm is fairly basic and can be easly translated to any programming language that uses regular expressions for pattern matching.

There is now a web site based on this code which can generate various kinds of reports.  See http://amt-sus1.its.yale.edu.

Gotchas and glitches

Other system settings that relate to installation of software can interfere with  automatic updates.

For example, using the security policy setting that disallows installation of unsigned code can block some updates from installing correctly because Microsoft doesn't code-sign their hotfixes (Microsoft, why not??)