XP SP3 clients and WSUS

[cookie_monster]

I've deployed quite a few XP SP3 boxes in the last few days and they don't seem to be downloading all updates, most have checked in and say that they have downloaded the updates but then don't contact the WSUS again. They show as not connected since the 24th but they have been turned on. As far as i can tell all of the SP2 boxes are fine and the WSUS is working ok.

 

These boxes were NOT imaged they were rolled out from a flat WDS install.

 

Tried wuauclt.exe /resetauthorization /detectnow on a couple but still nothing.

 

Any ideas?

 

Cheers.

[Michael]

Seems a little strange. I have SP3 clients checking into WSUS and downloading any required updates. Try this script:

 

@echo off
TITLE Logistix WSUS Reset Authorisation
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1.    Stops the wuauserv service
Echo 2.    Deletes the AccountDomainSid registry key (if it exists)
Echo 3.    Deletes the PingID registry key (if it exists)
Echo 4.    Deletes the SusClientId registry key (if it exists)
Echo 5.    Restarts the wuauserv service
Echo 6.    Resets the Authorization Cookie
Echo 6.    More information on http://msmvps.com/Athif
Pause
@echo on
net stop wuauserv
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
net start wuauserv
wuauclt /resetauthorization /detectnow
Pause

[cookie_monster]

It is odd, i've deleted the client id key and deleted it's account from the WSUS server then forced a scan and it appeard again but now shows as not yet reported. I'll check it again in the morning and try that script but it looks like it does what i've tried already.

 

Cheers.

[Michael]

Are your XP SP3 computer objects located in the correct OU to pick up WSUS policies?

[cookie_monster]

Yes the OU contained 30 SP2 boxes that have been rebuilt as SP3 the policies are exacty the same as they were and the accounts are in the same OU.

[powdarrmonkey]

I have found in the past that status often doesn't get reported for some hours after it starts talking to the server - sometimes up to 36. It's a PITA.

[Michael]

I have found in the past that status often doesn't get reported for some hours after it starts talking to the server

 

I would of thought that's because your clients haven't received all WSUS policies as to where to look for updates, if that makes sense? Running gpupdate /force or forcing your workstations to reboot several times should resolve the problem.

 

As a recommendation, I always configure WSUS policies on the Default Domain Policy, which does speed things up.

[ssiruuk2]

 

As a recommendation, I always configure WSUS policies on the Default Domain Policy, which does speed things up.

 

But if you have a large network that means you can only update your clients from a single WSUS server and all at the same time (or within the + / - of how the policy works). I have the WSUS policies running per room / OU to load balance between 2 WSUS servers. Also I like to have different WSUS policies for servers, desktops and laptops.

 

Microsofts documentation recommends having a dedicated GPO for WSUS updates and have it applied per OU.

[Jobos]

I had similar problems last week and solved it by reinstalling the windows update agent. Download it here: http://go.microsoft.com/fwlink/?LinkId=43264

 

Use the force option when installing:

 

WindowsUpdateAgent20-x86.exe /wuforce

[cookie_monster]

I'll have a look tomorrow it seems unlikely that i would need to reinstall the agent on 30 new built boxes though.

 

Cheers all.

[cookie_monster]

Ok i've tried Michael's script and i've reinstalled the agent but still no joy. If i delete the accounts they still reappear and show as not yet reported so the clients clearly know where to find the WSUS. I can see that SP2 boxes are reporting in and updating as normal.

 

Any more ideas?

[cookie_monster]

I seem to remember posting a couple of weeks ago about an update for Office 2003 SP1 update with a release date of 10/06/3008, this is what caused it apparently. The fix was odd i had to approve it then decline it and then repeat it appears to of worked.

 

There is now a KB on the issue.

 

http://support.microsoft.com/kb/954960

 

http://www.microsoft.com/technet/security/advisory/954960.mspx

 

EDIT

 

Yes i did post it i remember now http://www.edugeek.net/forums/windows/21553-wsus-updates.html

 

.

Edited July 30, 2008 by cookie_monster

[Geoff]

But if you have a large network that means you can only update your clients from a single WSUS server and all at the same time (or within the + / - of how the policy works). I have the WSUS policies running per room / OU to load balance between 2 WSUS servers. Also I like to have different WSUS policies for servers, desktops and laptops.

 

Microsofts documentation recommends having a dedicated GPO for WSUS updates and have it applied per OU.

 

As far as the clients care, WSUS is just a web application. There's no reason why you can't load balance multiple WSUS servers behind one IP/Hostname using either a hardware loadbalancing solution or DNS round robin.

 

Even so, I agree with you about the GPO comment. One should not needlessly clutter up the Default Domain Policy.

[Michael]

But if you have a large network that means you can only update your clients from a single WSUS server and all at the same time (or within the + / - of how the policy works). I have the WSUS policies running per room / OU to load balance between 2 WSUS servers. Also I like to have different WSUS policies for servers, desktops and laptops.

 

Microsofts documentation recommends having a dedicated GPO for WSUS updates and have it applied per OU.

 

Just because you specify Server A on the Default Domain Policy, you could still specify Server B for a Curriculum OU, Server C for a Staff OU and Server D for Domain Controllers (for example). In each OU you just specify the different server.

 

Microsoft's documentation is simply a recommendation. You must have a lot of machines to justify multiple WSUS servers. You could specify groups of computers to check in at different times or use Geoff's alternative method of load balancing.

[cookie_monster]

We have three seperate GPO's that split 500 boxes into three groups the GPO's are attached at OU level. We phase the release of patches so we can pickup issues before every client has installed the updates. We have a test setup as well of course but sometimes issues don't show up straight away. We don't have enough clients to require 2 WSUS boxes so load balancing is not an issue.

[dhoward_westexetc]

I had similar problems last week and solved it by reinstalling the windows update agent. Download it here: http://go.microsoft.com/fwlink/?LinkId=43264

 

Use the force option when installing:

 

WindowsUpdateAgent20-x86.exe /wuforce

 

I thought the Windows Update Agent was up to version 3 now? I seem to recall it was that V2 agent that caused the infamous svchost 100% CPU problem that brought XP SP2 machines to a grinding halt (and brought our network to its knees in Easter 2007!) I recall spending weeks deploying the new agent to our 800 workstations via batch script before we would allow WSUS to work again!

 

The version for the wuaueng.dll file on each XP client should be V7.xxx

 

The default interval for checking for updates is 22 hours, so if it doesn't find updates immediately you may have to wait until the next day for the client to synchronise with the WSUS server.

 

We had the same problem that this post describes, was resolved by approving then declining that update. We had the issue on new build machines, but that method on the WSUS server fixed it.

[cookie_monster]

I can't remeber exactly which update fixed the 100% svchost bug but i do know it was fixed by moving the wsus client from the same process as the GUI DOH!!! so at least the interface didn't lockup during scanning.

[dhoward_westexetc]

I am pretty sure it was the V3 agent, plus another patch for Windows Installer which solved the same issue for installation of office updates (I believe it was KB 927891).

[cookie_monster]

Yeh i think there was a patch first then the V3 agent appeared. Anyway i've sorted my issue now.

 

Cheers.

[Jobos]

I thought the Windows Update Agent was up to version 3 now? I seem to recall it was that V2 agent that caused the infamous svchost 100% CPU problem that brought XP SP2 machines to a grinding halt (and brought our network to its knees in Easter 2007!) I recall spending weeks deploying the new agent to our 800 workstations via batch script before we would allow WSUS to work again!

 

 

Well spotted. It appears I gave the old version Version 3 is here http://go.microsoft.com/fwlink/?LinkID=91237

[cookie_monster]

I notice that the patch has crawled down on the WSUS today.

 

Some computers do not receive updates from the WSUS server

 

 

SYMPTOMS

You use Microsoft Windows Server Update Services (WSUS) 3.0 to deploy software updates and hotfixes to computers that are in your organization. However, some computers do not receive updates from the WSUS server. This problem occurs if the computers have Microsoft Office 2003 or components of Office 2003 installed.

 

Note This problem affects Microsoft Windows Server Update Services 3.0 and Windows Server Update Services 3.0 Service Pack 1 (WSUS 3.0 SP1). However, in some circumstances, the following products may also be affected:

[powdarrmonkey]

I notice that the patch has crawled down on the WSUS today.

 

MS being logical again, and fixing WSUS through... wait, WSUS!