Home
.. About WSUS Wiki

RSS

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?

Site Meter


Terms of Use
Trademarks
Privacy Statement

 

Client Configuration Checks & 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.

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


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.

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.


Comments:

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

Hi,  I cannot see any clent computers on the wsus consol.  It is a default instal on port 80.  Access to the selfupdate files prompts you to download them so access is ok via the wsus server.   I use group ploicy for the targeting.  I've tried the various fixes with no result (including deleting the autoupdate regkeys susclentid and accountdomainsid);  Server 2003 (fully patched) with XPsp2 and 2ksp4 clents not showing the microsft toor for the autoupdate is reported back as the latest...   The only fix I have not tried is the IIS fix but this is a payable option by the looks of things...

Any ideas!  Help!

Dave.

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

FIXED! My clients are now reporting to the WSUS server, sucking down updates and generally behaving themselves.

The solution was to set the update & stats servers in the AD group policy to "http://myserver:8530". I guess this is because I has a SUS server installed previously and it needs the port explicitly defined. Stupid me, I thought that the admin console ran on a different port to the client when logging in.

I forced an update to my clients by running "gpupdate /force" then a "wuaclt /detectnow" on each system (I guess I could have waited for them to self register).

Arc.

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

I can't get ANY of my clients to appear in any computer group, including my WSUS server itself.

Previously my clients updated from a SUS server (which was running on the same system as my new WSUS server but has now been removed).

I've disabled the old SUS policy and created a WSUS policy, I can confirm that this IS on the client systems. I've checked the client version (which is 5.8.0.2469) and confirmed all registry entries. I've run the client diagnostic tool which passes all tests. From the IIS server logs I can see that the clients are contacting the IIS server for the client AU package, but nothing they won't appear in any group on the WSUS server. :-(

Help!

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

Since about 13th of december last year my W2K servers will not report to the WSUS server anymore.

This is what You see in the log file:

2006-01-11 15:53:37 2416 e4c AU Triggering AU detection through DetectNow API

2006-01-11 15:53:37 2416 974 AU #############

2006-01-11 15:53:37 2416 974 AU ## START ## AU: Search for updates

2006-01-11 15:53:37 2416 974 AU #########

2006-01-11 15:53:37 2416 974 AU <<## SUBMITTED ## AU: Search for updates [CallId = {651DF526-1D87-4CAF-B089-2CC99EA83119}]

2006-01-11 15:53:37 2416 1254 Agent *************

2006-01-11 15:53:37 2416 1254 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]

2006-01-11 15:53:37 2416 1254 Agent *********

2006-01-11 15:53:37 2416 1254 Setup *********** Setup: Checking whether self-update is required ***********

2006-01-11 15:53:37 2416 1254 Setup * Inf file: C:\WINNT\SoftwareDistribution\SelfUpdate\Default\wusetup.inf

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\cdm.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\iuengine.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuapi.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuauclt.exe: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuauclt1.exe: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuaucpl.cpl: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuaueng.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuaueng1.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wucltui.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wups.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wups2.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup Update NOT required for C:\WINNT\system32\wuweb.dll: target version = 5.8.0.2469, required version = 5.8.0.2469

2006-01-11 15:53:37 2416 1254 Setup * IsUpdateRequired = No

2006-01-11 15:53:37 2416 1254 PT +++++++++++ PT: Synchronizing server updates +++++++++++

2006-01-11 15:53:37 2416 1254 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://my-wsus-server/ClientWebService/client.asmx

2006-01-11 15:53:37 2416 1254 PT Initializing simple targeting cookie, clientId = b23dbf4d-b434-4e2c-a5e0-667205a88794, target group = Server, DNS name = my-wsus-client

2006-01-11 15:53:37 2416 1254 PT Server URL = http://my-wsus-server/SimpleAuthWebService/SimpleAuth.asmx

2006-01-11 15:53:37 2416 1254 PT WARNING: SyncUpdates failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200

2006-01-11 15:53:37 2416 1254 PT WARNING: SOAP Fault: 0x000190

2006-01-11 15:53:37 2416 1254 PT WARNING: faultstring:Fault occurred

2006-01-11 15:53:37 2416 1254 PT WARNING: ErrorCode:InternalServerError(5)

2006-01-11 15:53:37 2416 1254 PT WARNING: Message:

 

2006-01-11 15:53:37 2416 1254 PT WARNING: Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"

2006-01-11 15:53:37 2416 1254 PT WARNING: ID:dd86cb16-01ed-41a8-a58b-6840054c006f

2006-01-11 15:53:37 2416 1254 PT WARNING: Sync of Updates: 0x8024400e

2006-01-11 15:53:37 2416 1254 Agent * WARNING: Failed to synchronize, error = 0x8024400E

2006-01-11 15:53:37 2416 1254 Agent * WARNING: Exit code = 0x8024400E

2006-01-11 15:53:37 2416 1254 Agent *********

2006-01-11 15:53:37 2416 1254 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]

2006-01-11 15:53:37 2416 1254 Agent *************

2006-01-11 15:53:37 2416 1254 Agent WARNING: WU client failed Searching for update with error 0x8024400e

2006-01-11 15:53:37 2416 1254 AU >>## RESUMED ## AU: Search for updates [CallId = {651DF526-1D87-4CAF-B089-2CC99EA83119}]

2006-01-11 15:53:37 2416 1254 AU # WARNING: Search callback failed, result = 0x8024400E

2006-01-11 15:53:37 2416 1254 AU #########

2006-01-11 15:53:37 2416 1254 AU ## END ## AU: Search for updates [CallId = {651DF526-1D87-4CAF-B089-2CC99EA83119}]

2006-01-11 15:53:37 2416 1254 AU #############

2006-01-11 15:53:37 2416 1254 AU AU setting next detection timeout to 2006-01-11 16:48:38

 

I was checking in tons of internet pages. I found many peaple having the same problem. But nobody knows a solution. Any ideas?

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

I have tried all the above fixes, but none of these fix the problem we are having with any of our Windows 2000 clients (be it servers or workstations) reporting in.  The error code that I am getting in the WindowsUpdate.log file = 0x8024400E.  Can anyone please help?

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

Hotfix passwords are specific to the particular instance. Two copies of the same hotfix may have different passwords. It's a free call to get a new copy sent to you. Actually, only a link and a password is sent via email. The link for you to download the fix is good for a limited time.

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

The password for the Server2003 hotfix does not work, can anyone give me the correct password.

Thanks,

Robert

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

This seems to be a BUG in .NET. I have seen a case when this happened with the installation of .NET Service Pack.

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

Ok...  Another helpful hint....

RE: client download issues relating to 0x80244008

If you are experiencing site wide issues (and 0x80244008 from the WindowsUpdate.log on your clients -- all of them) and/or an inability to log into the WSUSAdmin application (Error: "Server Application Unavailable" in IE window), you might be experiencing a .NET Framework issue on the server.  In my case, I loaded all of the Framework installables (1.1 and then the SP1, and hotfix), but because of AD Password policies on the domain -- or strong password requirements (I am suspecting), the ASPNET account wasn't able to be created properly during the Framework install (no error messages that I could find to prove it, but that's my guess), so the fix was to create an account (or use another existing one that you know the password to), modify the "machine.config" file in the CONFIG directory (under C:\Winnt\Microsoft.Net\Framework\v1.1.xxxxx) in the processmodel username and password attributes...  Yes, that's a security risk..  plain passwords and all.. There's a tool from MS to encrypt all that, but the idea is that this will get you started again.  Very annoying...  3 days and 20K internet pages worth of google searches figuring this out..  :)

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

The sample batch file worked like a charm for me.  I had a number of clients that had been imaged that were not displaying in the admin console on WSUS.  After running the batch file all the clients popped right up in the console.


Last Modified 7/30/08 8:20 AM

Hide Tools