Recently, I rolled out the Client Side Extensions for XP in order to support Group Policy Preferences. The change in the GPO to use preferences instead of scripts for mapping some drive letters was a non-event for the majority of our staff machines. But there were a few reports of the the mappings not taking place. A closer look at these machines proved that they had not recieved the update for the Client Side Extensions.
I’m running WSUS 3.0 SP1 in our office to update client machines. We have a lot of “spare” machine on the floor for use by visitors and consultants, often those machines are powered off for long periods of time. Because of this I don’t worry too much about machines that haven’t reported in to WSUS for 30+ days, unless they appear to be assigned to a regular user. When I checked WSUS for the status of the machines with the policy issue, they had not updated in a long period of time.
Those machines were throwing a “0x8024400e” error in the Windows Update log file. This error was documented a while back in the WSUS Product Team Blog. The fix to the problem is to “decline” (if not already declined) the Office 2003 Service Pack 1 update, un-decline (but not approve) it, and then decline again.
After that, the affected client machines will be able to get updates again. This worked for the all but one of the machines that I saw this problem with. The last box then threw a “80072ee2” error in the Windows Update logs.
This is related to general connectivity to the WSUS server. To solve this, I did a “hard reset” of the WSUS client by stopping the Automatic Update Service, deleting the contents of the C:\Windows\SoftwareDistribution folder and then restarting the Automatic Update service again. Then I used the wuauclt.exe tool with the “/detectnow” switch to kick of an update immediately.
Sometime this week, I’ll have to go around at turn on all those spare computers, to make sure they all report in to WSUS and confirm that no other machines need special handling.