Home
.. About WSUS Wiki

WSUS
.. WSUS FAQ
.. WSUS on SBS
.. WSUS Troubleshooting
.. WSUS News Groups
.. Known WSUS Issues
.. WSUS Links
.. WSUS Wish List

WSUS Documents
.. WSUS Deployment Guide
.. WSUS Installation Guide
.. WSUS Release Notes
.. WSUS Best Practice

SUS
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues

Wiki Community

 .. Wiki Contributors
.. I Love WSUS
.. WSUS Wiki Diary
.. Wiki Statistics
.. To Do Page

Miscellaneous Stuff
.. Other Resources
.. Do You Know?

WSUS uses a client-server architecture. The WSUS client, which runs on client computer, wakes up on a regular basis and queires a WSUS server to find applicable updates. The WSUS client is also designed to update itself, via what is known as self-update. The idea is that the client will look for, and download, both the OS and applicaiton updates, but also updates to the client iteself. The latest version of the AU client is requried for client computers to interact fully with the WSUS server

In most cases this mechanism works ok, and clients get updated as needed and are able to check in with the WSUS server. But on some systems, client computers either do not properly check in with the WSUS server or do not selfupdate. These problems are both fairly rare and easy to overcome.

This page contains a set of client configuration checks you can make on client computers that are not connecting to WSUS properly, and a set of know issues.

Client Configuration checks

1. The first thing to check is whether the client computer is using the latest Automatic Update client version. 

 The current version of the Windows Update Agent (the WSUS client component in AU) is determined by the version of the WUAUENG.DLL, located in %systemroot% \system32 folder. If the version of WUAUENG.DLL is 5.4.3790.1000 or greater, the WSUS client (or WUA) is installed. A version less than 5.4.3790.1000 indicates that SUS or earlier AU version 1.0 is installed.

If you have an earlier version of the AU client, it must be updated in order to work with WSUS. Computers running Windows XP with Service Pack 2 (SP2) already have the WSUS client installed.

The AU client, when contacting the WSUS server, will automatically update itself to the latest WSUS version if the self-update files are properly setup on the server. When connected to Windows Update or Microsoft Update, the AU client will also be able to self-update if it is not running the latest version. In addition, the AU client can also be updated by using a signed stand-alone, installation package that is available from Microsoft.

For further instructions on how to detect the need for, and or download the standalone latest release version of WUA, see the Updating the Windows Update Agent section of the
Windows Update Agent API portion of the WSUS SDK at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wus/wus/portal.asp .

On the left navigation, from Windows Server Update Services -> Windows Update Agent API -> Using the Windows Update Agent API -> Updating the Windows Update Agent.

2. If you want AU clients to update from a WSUS server in your environment, be sure you have set anonymous access permissions on the virtual Self Update directory and that it is on a Web server running on port 80. WSUS uses IIS to automatically update client computers to the WSUS-compatible Automatic Updates software version. To do this, WSUS Setup creates a virtual directory named Self Update, under the Web site running on port 80 of the computer where you installed WSUS. This virtual directory, called the “self-update tree”, contains the WSUS-compatible Automatic Updates software. Earlier Automatic Updates client versions can only update if they find the self-update tree on a Web server running on port 80. The access permissions on this virtual directory must be set to allow anonymous access. This Automatic Updates version check is done every time the client checks-in with the server to detect new approved updates.

3. Be aware of GP replication time which may cause delay in your clients’ self-update process the first time a WSUS server and client are mapped. If clients have been mapped to WSUS servers using GP in an Active Directory environment, the timing of AU client check in with the WSUS server can be impacted by AD GP refresh timing (generally about every 90 to 120 minutes depending on environment). Clients mapped to servers in a non-Active Directory environment can be forced to check in and update right away by running wuauclt/detectnow from the command prompt .

4. Another variable that will impact client check-in behavior is the Automatic Updates detection frequency setting. By default, this value is set to the maximum of every 22 hours. This means that every 22 hours, minus a random offset, AU polls or checks in with the WSUS server for approved updates. Every time the client checks in, it also verifies it has the latest version of the client and if not, it self-updates from the server. This setting can be modified via policy or by directly editing the local policy or registry on the client. The minimum frequency is one hour. If clients have been mapped to a WSUS server via local policy or direct registry editing, without detection forced by running wuauclt/detectnow, it could be up to 22 hours until that client will self-update and appear in the WSUS Admin Console.

5. Imaged clients with a duplicate client ID will only appear once in the WSUS Admin Console. Each AU client must have a unique id which is created for each individual install. When imaging systems it is recommended always to use SysPrep. The WSUS admin console will only display one client for each unique ID. If you have multiple clients created from one image which are sharing the same ID, only one will appear in the WSUS admin console. All clients will check in and download updates, but only one will appear and display status in the WSUS admin console. In cases where clients are not checking in, and they were created from images without running SysPrep, the following steps will reset the existing duplicative client IDs.
a. Run regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
b. Delete the PingID, SUSClientID and the AccountDomainSID values
c. Stop and start the Wuauserv Service
d. From the command prompt run: wuauclt /resetauthorization /detectnow

or-

From the command line, once you are sure the AU client is properly configured and not disabled, you could run a batch file (which might look something like this sample) and get the same results:

rem Fixes problem with client machines not showing up on the server due to imaging method

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v AccountDomainSid /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v PingID /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
cls
@echo Triggering detection after resetting WSUS client identity
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

Additionally the following VBScript can be deployed via group policy to perform the above function automatically at logon. The script creates a registry key that will allow the script to check if it has been run on that client before. If it has it ends without performing any further changes.

Dim objShell, strKeyPath, strValueName,strComputer

set objShell = wscript.createObject("wscript.shell")

const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"
strValueName = "SUSClientIdReset"

objRegistry.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
IF (dwValue = "1") THEN
            'do nothing
      ELSE
            'Fixes problem with client machines not showing up on the server due to imaging method
            objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientId"
            objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientIdValidation"

   Set colServiceList = objWMIService.ExecQuery ("Select * from Win32_Service where Name = 'wuauserv'")

   For Each objService in colServiceList
    If objService.State = "Running" Then
    objService.StopService()
    Wscript.Sleep 10000
    objService.StartService()
    End If
   Next
   
            objShell.Run("wuauclt /resetauthorization /detectnow ")
   Wscript.Sleep 10000   
            objShell.Run("wuauclt /r /reportnow")

            'Set reg value for SUSClientIdReset for checking against later.
   dwValue = "1"
            objRegistry.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
End If

Just save the above scipt as a *.vbs.

Known Client Issues:

1. Some clients have been impacted by a known issue in with Windows Server 2003 http.sys and IIS. In some cases, this transient issue will appear to prevent clients from checking in, because they receive invalid responses from the server after some attempts. It was previously believed to be an issue with IIS compression and there was a workaround suggested to disable compression, and then rename the %windir%\system32\inetsrv\suscomp.dll file and restart the IIS, and the Update Services service. Further Investigation shows the problem source to be a known condition with IIS and http.sys, which is not related to compression, and for which there is an available hotfix. It is not recommended to disable compression as this will not impact the problem source, and possibly increase network traffic & server load, while reducing the number of clients you can effectively serve. Further information about the issue and obtaining the hotfix can be found:

NOTE: Be sure to include all text between '(' and ')' when navigating to this hot fix location!

2. In some rare cases, AU clients have been impacted by an issue under investigation with the current W2K SP4 rollup 1 distribution package if installed via Express Install. Investigation so far reveals that when this update rollup package is installed as an Express Install, it can damage the existing client msxml3.dll. When this happens, the AU client will not be able to detect, or check in, with the server. Detection will fail with a 0x80244001 error.

Microsoft has re-released  the Win2k URP1where a change was made to the way the package installs.  The contents for the package were unchanged from the initial released version.  The re-release was only done for WSUS since the issue did not occur with SUS1.0.  The change made to the URP1 installation via WSUS or Windows Update/Microsoft Update was to remove the Express installation option and only permit the full installation capability.

This posting is provided "As Is" with no warranties, and confers no rights.