SUS How-To Guides

HOW TO: Configure and Use Automatic Updates in Windows XP…kb;EN-US;306525

HOW TO: Schedule Automatic Updates in Windows XP and Windows 2000…kb;EN-US;327838

HOW TO: Configure Automatic Updates to Prompt You Before You Download Updates in Windows XP…b;en-us;Q283629

HOW TO: Force Automatic Updates 2.2 to Perform a Detection Cycle…b;en-us;Q326693

HOW TO: Configure Automatic Updates by Using Group Policy or Registry Settings…kb;EN-US;328010

HOW TO: Configure and use Automatic Updates in Windows 2000…kb;EN-US;327850

Disabling Auto Update Service in Control Panel Does Not Shut Down the Service…b;en-us;Q283151

Description of the Automatic Update Feature in Windows XP…b;en-us;Q294871

Automatic Updates 2.2 Client Does Not Detect Approved Updates from Software Update Services…b;en-us;Q323184

Software Update Services Resources

Software Update Services Interactive Simulation:

Download SUS software:

Download Automatic Updates Client:

Software Update Services 1.0 ADM File for Service Pack 1:

SUS Deployment Guide:

SUS white Paper:

Sign Up for the SUS Newsletter:

More Information:

If you have any questions/ doubts/ queries, feel free to post on

Microsoft SUS Discussion Groups Home:

You can access MS SUS News Group from Google;



Software Update Services (SUS) Limitations

Like any piece of software, SUS Server does have some limitations that you should be aware of:

SUS only distributes critical patches – it will not download any driver updates.

SUS only delivers patches for the Windows 2000, XP and 2003 operating systems. It will never download patches for Windows 9x and Windows NT 4

SUS will not deliver patches for Office, ISA, SQL, and Exchange.

SUS will not deliver patches for Non-Microsoft operating systems.

With SUS you cannot roll out patches from the clients, you can only Un-approve, which will restrict future installations, but it will not un-install those from the clients.

SUS lacks reporting features, its tough to know the patches installed at the clients.

With SUS you cannot target the clients; it’s automatically targeted to all those computers configured with AU for local SUS.

Reboots can affect logged in users, there is no way to say NO if a patch requires a reboot.

AU Client will check in SUS Server for Approved patches at a random time, 17-22 hours and it’s not possible to increase/decrease this time.

How Updates Deployed Via SUS Behave for Users

It’s also important to understand how the Automatic Updates client behaves for the logged in user when SUS is used to deploy updates.

Users with Local Admin Privileges:

  • AU client activity is transparent to all those users with local admin privilege.
  • They will see notification balloons.
  • They will be prompted according the configured AU option, if applicable
  • Most importantly, they can delay or postpone the reboot.

Normal Users or Users without Local Admin Privileges:

  • For normal users, all AU Client activity is hidden.
  • They won’t see notification balloons.
  • They will not be prompted of any of the AU OPTIONS, so options 2 & 3 as noted in the previous article will not.
  • They cannot postpone any required reboots, as the NO options will be grayed out.

Configuring Software Update Services (SUS) Client Settings

You can always configure AU Client settings thru Group Policy Settings, or manually via the Registry Editor; for the purpose of this illustration, we’ll focus on the configuration of update settings via a GPO.

Configuring AU Client settings via Group Policy

The simplest (and arguably the best) way of configuring Automatic Update Client settings is by use of Group Policy objects in Active Directory Environments. This method allows greater granularity and control over how the Automatic Updates Client behaves, and to apply any changes to it. You will need to configure the AU client using a GPO if you want to get updates from your Local SUS server.

At this point, you’ll want to download the WUAU.adm Template from the Microsoft web site. See the direct link in RESOURCES Section at the end of this article.

Next, you will need to identify the target clients that will use your SUS Server to obtain critical patches. Here are the steps:

1. Open Active Directory Users & Computers.

2. Open the GPO from the target OU.

3. Add a new policy & expand the Computer Configuration container.

4. Expand the Administrative Templates container

5. Right click Administrative Templates in the MMC and import the WUADM template in to the Policy from \windows\inf directory or the \winnt\inf directory, depending on your OS.

Snapshot of Add/Remove WUAU.adm Template.

6. Expand the Windows Components container

7. Click the windows updates container

8. In this container you will be able to configure

  • Configure Automatic Updates
  • Intranet Microsoft Update Service Location
  • Reschedule Automatic Updates Scheduled installations
  • No auto-restart for scheduled Automatic Updates installations.

Use the Resultant Set of Policies (RSOP), like Group Policy Management Console, GPMC, or GPRESULT.EXE to investigate if the policies are being correct applied to your client systems.

NOTE: Group policy is not the only way to deploy the AU Client Settings; you can edit the Registry manually to configure these settings on individual systems. For more information on the necessary Registry configuration changes, see Mohammed AthifKhaleel’s article Manipulating SUS Settings through the Registry.

Are your Automatic Updates working with SUS?

Once SUS is installed and AU clients are configured, you’ll want to ensure that everything is working correct. To test, follow these simple steps:

TEST SUS: First, make sure it’s synchronizing with Microsoft Update Server daily, looking at its Synchronization and Application Event logs. Isn’t that simple?

Test Automatic Updates: This is more important for Automatic Updates, as SUS will only approve updates, which then have to be “pulled” from the server by the AU client. First, you have got to make sure AU gets appropriate settings via the GPO used to deploy them. To test this, just do a simple reg query from command prompt using the Reg query “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /s command, as shown below:

WUServer REG_SZ http://Your-SUS-Server-IP/Hostname
WUStatusServer REG_SZ http://Your-SUS-Server-IP/Hostname

NoAutoUpdate REG_DWORD 0x0
AUOptions REG_DWORD 0x3
ScheduledInstallDay REG_DWORD 0x0
ScheduledInstallTime REG_DWORD 0x3
UseWUServer REG_DWORD 0x1
RescheduleWaitTime REG_DWORD 0x1e

This is where normal troubleshooting should always start. If you happen to find any errors, reference the Error Codes mentioned in SUS Deployment Guide.

Installing Software Update Services (SUS)

Preparing for the installation and then actually installing SUS Server is completed in 5 easy steps:

1. Ensure that the system that will run SUS meets operating system requirements – in this case a server running Windows 2000 Server or Windows 2003 Server.

2. Prior to installing the SUS package, there are some prerequisites to that need to be addressed The server must have:

  • An NTFS Partition with at least 4 GB enough to store patches.
  • Internet Information Services (IIS), configured to allow ANONYMOUS ACCESS on the Default Website where SUS will be installed.
  • Internet Explore version 6.

3. Installation is completed via a typical Windows wizard – the process itself is straightforward and without surprises. By default, it will store patches in c:\sus\content, but this directory location can be changed if necessary.

4. After the installation process is complete, open Internet Explorer and browse to http://Your-SUS-Server-Name-or-IP/Susadmin to access the SUS Server administrative interface. Click on SET OPTIONS:

  • To configure the Proxy server settings, if necessary
  • To set the language to download patches,
  • Set the synchronization schedule and connect the server to the Internet to synchronize and download all of the patches from Microsoft Windows Update using SUS’s Web-based interface.

Snapshot of SET Options from SUS ADMIN Console.
5. Once the server is installed and configured, it’s up to you “approve” individual patches, deciding which should be approved for installation on your network’s client systems.

Configuring Software Update Services (SUS) Clients

In larger environments, Automatic Update client settings are typically configured via Group Policy. We’ll get to configuring update setting via Group Policy later in this series. For now, we’ll explore the various configuration options available via the System applet in Control Panel.

One of the most commonly asked questions is about how updates get from the SUS system to network clients. To understand this you have to have a better understanding of the Automatic Update settings on client systems. AU options mean the available options to configure the AU client. These settings let you specify if automatic updates are enabled on a given computer. If the service is enabled, you must select one of the three available options:

AU OPTION 1 = Notify before downloading any updates and notify again before installing them.

When the Automatic Update client finds updates, it notifies the user to download the patches. Once the patches are downloaded, it notifies the user to user to install those updates. The Notification Balloon pops up in the Taskbar.

AU OPTION 2 = (Default setting) Download the updates automatically and notify when they are ready to be installed

When the Automatic Update client finds updates, it downloads these patches automatically. Once the patches are downloaded, it notifies the user to user to install those updates. The Notification Balloon again pops up in the Taskbar.

AU OPTION 3 = Automatically download updates and install them on the schedule specified below.

When Automatic Update Client finds updates, it downloads the patches automatically. Once the patches are downloaded, they are also installed automatically.

If the status is set to Enabled, AU client recognizes when this computer is online and checks in with the Local SUS Server for all the updates to be applied to that computer.

How Software Update Services (SUS) Works

The 5 steps below outline how SUS functions in terms of obtaining updates and deploying them to AU client systems:

  1. The SUS Server will synchronize with Microsoft’s Windows Update Servers and downloads all new or missing patches.
  2. At this point, the Administrator has an option to APPROVE the new patches, or may opt to test the patches prior to approval.
  3. Once a patch is approved, AU clients will check in for any new updates.
  4. If an AU client finds any new updates, it will download and install those patches (based on its client configuration settings).
  5. Once the patches are installed, then the logged in user is given an option to reboot (only if necessary).

Software Update Services (SUS) Components

SUS is the server-side component of the update process. On client systems, related components include the Automatic Update Client (AU) and the Background Intelligent Transfer Service (BITS).

Automatic Update Client

What is the Automatic Update Client?
Automatic Update Client enables the download and installation of Windows updates. If this service is disabled, a computer will not be able to use the Automatic Updates feature of Windows. The AU client component is installed by default along with operating systems “above” Windows 2000 SP3, Windows XP SP1, and Windows Server 2003.

When used in an SUS environment, the AU client will talk to the local SUS server and check for approved updates. If there are updates that have been approved and are needed by the client, then based on its AU options are configured (more on those options shortly) the client will install those patches.


If the AU client system is configured via Group Policy settings, all the options will be grayed out on the client system, as you see in the figure above. Normally, the AU client takes anywhere between 17 and 22 hours to check for updates on SUS SERVER. That said, this time is random and you can’t define it in the current version of SUS (SUS SP1). Just in case you’re curious, AU stores patches in C:\WUTEMP or C:\ProgramFiles\WindowsUpdate\wuaudnld.tmp while waiting for installation processes to complete.

Background Intelligent Transfer Service

What is the Background Intelligent Transfer Service?

The Background Intelligent Transfer Service (BITS) transfers files in the background using idle network bandwidth. If the service is stopped, features such as Windows Update will be unable to automatically download programs and other information. If this service is disabled, any services that explicitly depend on it may fail to transfer files. This is especially true if these clients do not have a fail-safe mechanism to transfer files (such as directly via Internet Explorer).

If an AU client detects that patches are available to be downloaded, it hooks up BITS to download those patches. The BITS service is configured for manual startup, and is started only when required.

If you want to dig a little deeper, use the Bitsadmin tool (it’s on WinXP CD – \Support\Tools\ to see a list of BITS-related jobs and what they are reporting. Specifically, run Bitsadmin /list /allusers /verbose to see what is in the queue. Here are few Bitsadmin Examples. This tool really helps in troubleshooting AU Clients and any problems that may arise.

SUS Functionality

As discussed, SUS consist of both server and client components. The follow sections outline how these elements work together.

Software Update Services (SUS) Basics

SUS is designed to automate the process of updating Windows systems with the latest patches and hot fixes. It requires that you set up what effectively becomes a local Windows Update Server, which will host a copy of patches and updates from the Internet-based Windows Update Server that you’re likely already familiar with. SUS is designed to update systems running (at least) Windows 2000 SP2, Windows XP SP1, and Windows 2003. That said, SUS does not support WIN 95, WIN98, WINME, and WINNT4.0; it will never download patches for these operating systems. If you need to update computers running these older versions of Windows, you’ll still need to go about the process manually.

Ultimately, this means that SUS can only apply patches to the following operating systems:

  • Windows 2000 Professional with Service Pack (SP) 2 & above.
  • Windows 2000 Server with SP2 & above.
  • Windows 2000 Advanced Server with SP2 & above.
  • Windows XP Professional without SP1 & above.
  • Windows XP Home Edition without SP1 & above.

SUS provides for centralized administration; an administrator can decide which available updates are to be approved for distribution to clients. Patches are downloaded in the background via the Background Intelligence Service (BITS); you’ll learn more about BITS later in this series.

SUS will never “push” any patches to its client systems. Instead, it only publishes the updates that you designate as “Approved Patches”, and then the Automatic Update feature of your Windows clients will pull the updates instead.

Unlike using, it’s important to note that SUS will never download driver updates; it only distributes critical security updates.