Step-By-Step: How to systematically troubleshoot Microsoft's Software Update Services

How to systematically troubleshoot SUS Setup problems

Microsoft's Software Update Services (SUS) is a great tool for keeping your systems up to date. Unfortunately, getting it to work sometimes requires a lot of patience and a bit of detective work. SUS needs a few basic things to function properly. First, you must have an SUS server, which must be configured correctly. Second, the Automatic Updates Client must be installed on all workstations and must be running properly. Finally, the clients must have the appropriate registry entries to tell the update client how to contact the SUS server. Here's what to do if things don't seem to be working properly.

The SUS server
Setting up the SUS server is not particularly complicated, as I explained in the article "Take control of patch management with Software Update Services." However, problems do sometimes occur.

One of the most frequent SUS Setup problems shows up if you try to store the update files on another server. Because of the way that SUS interacts with IIS, the files must be local to the server.

Another potential problem with SUS can occur if the default Web site into which SUS installed was not working properly before the installation. If the default Web site was modified to require SSL or client side certificates, or if the default pages were modified, it is possible that clients requesting information will receive error messages back; therefore, they will not get their updates.

The final problem is if the server never had updates downloaded and, if necessary, approved. The end result is that when a client requests updates, the server will not have them available. Whether you set up SUS to update automatically or choose manual approval of updates, go into the Synchronize Server page and make sure the server is synchronized. Then go into the Approve Updates page and make sure that SUS is not waiting on your approval of the updates it has downloaded.

The time to determine if the server is working is after you have set up clients and you are comfortable that they are working correctly. If the SUS server is responding to client requests, entries will be made in the default Web site's log. If everything is working correctly, then the log file should have entries in it similar to the following:
2003-05-29 01:19:09 - 80 HEAD / 0305290119 200 Industry+Update+Control
2003-05-29 01:19:09 - 80 GET / 0305290119 200 Industry+Update+Control
2003-05-29 01:19:09 - 80 HEAD /selfupdate/AU/x86/W2K/en/ 0305290119 200 Industry+Update+Control
2003-05-29 01:19:09 - 80 GET /selfupdate/AU/x86/W2K/en/ 0305290119 200 Industry+Update+Control

These entries indicate that the Web server returned an error code of 200 (success) when the client at requested an update. These four lines are the tell-tale signs that the client is talking to the SUS server. Without them, it is likely that the Automatic Updates Clients are not installed, not running, or not configured correctly.

Alternatively, if you see any error code other than 200 (success), then you have an error on the SUS Web server that you will have to resolve. You can search for help on the error code you are receiving to see what the possible causes are. In most cases, you will not see an error in this log file. You simply will not see any entries, meaning that the client is not talking to the server at all.

The Automatic Updates Client
The Automatic Updates Client was optional for Windows 2000 Service Pack 2, but starting with Windows 2000 Service Pack 3 and Windows XP, the Automatic Updates Client is already installed on every client computer on your network. If you are running Windows 2000 Service Pack 2 on your client machines, you should upgrade to the latest service pack; however, if you are unable to do that, you can distribute the Automatic Updates Client via an MSI file.

Just because the Automatic Updates Client is installed does not mean that it is operational. The automatic updates services may not be running or may be failing for some reason. Although you can check the event logs on the client, in most cases they do not contain any useful information. For unknown reasons, the Automatic Updates Client does not log its information to the event viewer. Instead, the Automatic Updates Client creates a file called "Windows Update.log" in the %SYSTEMROOT% directory. This file contains a running log of every Windows Update activity. This file includes the activities used by Windows Update from the Automatic Updates Client and the client.

If automatic updates are working correctly, you should see lines similar to the following in the log file:
2003-04-26 01:07:42  06:07:42   Success   IUCTL          Downloaded from http://sus-server to C:\Program Files\WindowsUpdate\V4
2003-04-26 01:07:42  06:07:42   Success   IUENGINE       Starting
2003-04-26 01:07:42  06:07:42   Success   IUENGINE       Determining machine configuration

These lines indicate that the Automatic Updates Client went to the SUS server and downloaded the update catalog. You will notice that the SUS server is identified in the first line. In this case, the SUS server is named sus-server and it is referenced in the form of a URL. If you see a reference to, the Automatic Updates Client is not referring to your internal server. This is an indication that the group policy (discussed below) may not have been applied correctly or the user navigated to Windows Update outside of the automatic updates. Remember that both the Windows Update ActiveX control and the Automatic Updates Client write to the same file.

If you wanted to confirm that your clients are downloading and installing patches, you could go to Windows Update and see what updates are currently available, remembering that there are some types of updates that Windows Update offers that SUS will not, such as Windows Updates and Driver Updates. Alternatively, you can review the automatic updates log file (Windows Update.Log) for lines similar to the following:
2003-05-23 03:05:00  08:05:00   Success   IUENGINE       Install started
2003-05-23 03:05:00  08:05:00   Success   IUENGINE       Installing SOFTWARE item from publisher com_microsoft
2003-05-23 03:05:00  08:05:00   Success   IUENGINE       Installer Command Type: EXE
2003-05-23 03:05:01  08:05:01   Success   IUENGINE       See iuhist.xml for details: Install finished

This indicates that the client installed one of the approved updates. This is verification that the Automatic Updates Client is working correctly.

If you do not see anything in the client log, then you should check to make sure that the Automatic Updates service is set to automatically start and that it has started. Similarly, you may want to make sure that the Background Intelligent Transfer Service (BITS) is started or is not set to disabled. The BITS service is used by the Automatic Updates Client to transfer information from the SUS server to the client. It will start automatically the first time it is needed.

If, on the other hand, you see a Windows Update log file that indicates that the Automatic Updates Client is downloading from, you know that the client has not correctly accepted the configuration information indicating what SUS server to use.

Occasionally, I have seen situations where the Automatic Updates Client did not start going to the SUS server until the user had gone once to Windows Update. Neither Microsoft PSS nor I could explain this; it did not seem to make any sense. However, if you have a client that refuses to start talking to your SUS server, you still might try taking it first to Windows Update.

This means that the group policy that you used to set up the configuration on the client is not being correctly applied. If you have not rebooted the workstation since applying the changes to group policy, then you should do so. It is technically possible to use SECEDIT (SECEDIT /refresh_policy machine_policy) to apply the group policy changes manually, but it is easier to just reboot the client. On Windows XP, you can run GPUPDATE to get the same effect as SECEDIT since the command was changed from Windows 2000 to Windows XP.

Group Policies
Although it is possible to set up the Automatic Updates Client by pushing registry changes to the clients via a logon script, group policies are almost universally used to push automatic updates configuration; this is because an administrative template has already been created to simplify the client configuration process.

Automatic Update Administrative Template
The Automatic Update Administrative Template is included with the SUS server download but is also available separately at Microsoft's Web site. The template, which is added to the Group Policy Editor, controls all of the settings that are needed to configure the Automatic Updates Client to use the SUS server. You definitely want to use the administrative template included with the SUS server or from the download since it has all of the options that you will need, whereas the one that may already be present on the system may not.

Configuring the settings is as simple as installing the template and configuring the service. You can do so by starting the Active Directories Users And Computer MMC console and selecting Start-Programs-Administrative Tools-Active Directory Users And Computers.

Right click on the container where you want to add the group policy. Typically, this is the Computers OU. Select Properties from the context menu. Click the Group Policy tab. You should see something similar to Figure A appear.

Figure A
The group policy tab of a container

Next, Click the New button and enter a name for the new group policy.

Click the Edit button to open the group policy editor as shown in Figure B.

Figure B
The group policy editor

Right-click the Administrative Templates and select Add/Remove Templates. The add/remove templates dialog appears as in Figure C.

Figure C
The add/remove administrative templates dialog

Click the Add button. Double-click the WUAU.ADM file. If the WUAU.ADM file does not exist in the directory where the administrative templates opens up, navigate to the location where the WUAU.ADM file is and select it. You can use the search tool in Windows 2000 to locate the file if you are unable to find it. Alternatively, you can just download the file from the link above. Expand the Administrative Templates folder. Expand the Windows Components folder. Click on the Windows Update folder. Double-click the Configure Automatic Updates setting in the right pane. A dialog box opens as shown in Figure D.

Figure D
The configure automatic updates policy

Configure the automatic updates properties to auto download and schedule the installation. Select the day of the week and the time of day that works best for your organization. The defaults are generally good. If you need to continue to test, you may want to set this setting to Not Configured so that you can manually adjust the automatic update settings on the client. However, this setting will ultimately need to be set so that every computer will receive and install patches. Click the Next Policy button; the next policy will appear as in Figure E.

Figure E
The location policy

Click the Enabled radio button and then enter the name of the SUS server in URL format into both the intranet update service and intranet statistics server boxes. This policy directs the client to use the internal SUS server rather than the Microsoft servers on the Internet. Click the Next Policy button and the next policy will appear as in Figure F.

Figure F
The reschedule updates policy

In order to force clients to install the updates, even if users shut down their computer each night, the Reschedule Automatic Updates scheduled installations settings must be set. This forces missed installations to be installed once the computer is turned back on. Setting this option to 1 minute essentially forces the scheduled updates to be installed immediately after the computer is restarted. Click the Next Policy button to go to the No Auto-restart For Scheduled Automatic Updates Installation page as shown in Figure G.

Figure G
The auto-restart policy

Click the Disabled radio button to allow the system to reboot after installing updates without the user's permission. Click the OK button to apply all of the policy changes. Close the group policy editor. Click the OK button to accept the group policy.

Once you have established the policies, it is time to reboot a client to make sure that the changes have taken effect. If you have set the automatic updates, setting the Automatic Updates Client available in the control panel will not allow you to change any settings. However, it will display the current settings and will show you that the group policy was applied correctly.

You can check to ensure that the settings were applied by running GPRESULT /SCOPE COMPUTER /V. This will display a list of applied settings from the administrative templates as shown in Figure H. The computer shown in Figure H is running Windows XP. You will need to run GPRESULT with different parameters; you will see different results if you are still running Windows 2000.

Figure H
Group policy results

If you do not see these settings on a Windows XP workstation, then your group policy was not applied. Some reasons for this might be:
  • The computer being tested is not in the container or in a subcontainer where the group policy was applied.
  • The group policy has been overridden by a policy at a lower level that is not applying the settings.
  • The properties of the group policy object have been set to disable the computer policy settings.
  • The workstation has not been rebooted (or the group policies reapplied) since the group policy object was created.
  • The group policy has not fully propagated through the domain yet.

Forcing a detection cycle
Once you have double-checked everything and fixed any known errors, it is time to start a detection cycle. Unfortunately, the Automatic Updates Client can wait up to 17 hours before trying to look for updates again. Fortunately, there is a way to force a detection cycle quickly. First, go into your group policy and make sure that you do not have the Configure Automatic Updates policy set. If this is set, you cannot change the automatic updates settings necessary to force a test.

Open the Automatic Updates applet in the control panel and uncheck the Keep My Computer Up To Date checkbox and click Apply. Wait a minute and then recheck Keep My Computer Up To Date, change the other settings if necessary, and click OK. Within the next few minutes, the Automatic Updates Client should recheck for the SUS server. You can determine that checking in the Windows Update log file.


Editor's Picks