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

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.

 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

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: http://support.microsoft.com/?id=898708 . This hotfix does require Service Pack 1 be installed to the Windows Server 2003.

Package:
-----------------------------------------------------------
KB Article Number(s): 898708
Language: English
Platform: i386
Location: (http://hotfixv4.microsoft.com/Windows%20Server%202003/sp2/Fix160692/3790/free/233375_ENU_i386_zip.exe)
Password: rYs0Tl5yII
Password Changes On: 10/12/2005
Next Password: 3)NDLn%Q

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.

Comments:

From dave4163 - 7/3/06 10:13 AM

From arc - 3/18/06 12:58 AM

From arc - 3/17/06 12:07 AM

From hrreichardt - 1/11/06 10:10 AM

From coreycook - 12/11/05 11:03 PM

From AxelLarson - 10/23/05 4:00 PM

From Robertt - 10/22/05 6:14 AM

From Athif - 8/27/05 5:48 AM

From smanross - 8/26/05 3:51 AM

From esomes - 8/4/05 12:44 PM