Hope all the TechEd attendees have been enjoying themselves – I know I’ve been busy racing from one end of the conference center to the other. Turns out that the conference center is about 1.5 miles long and TechEd is spread throughout a mile of it. And it never fails, the next place I have to be is always the furthest point from where I am the moment before.
So far, I’ve been concentrating on sessions around Exchange 2010, so look for some Exchange and Outlook related posts as soon as I get a little bit more time to get everything I’ve been learning straight in my head.
This morning I’m starting out with a session on some technology that’s pretty critical to most systems administration – WSUS. I know it’s time for me to review and potentially adjust how we monitor and update computers in the office and I’m hoping this WSUS session will help move those tasks higher up on my project list.
Ran into an interesting Windows Update issue today. I have a freshly built Windows 2008 Server and have it set to automatically run Windows Update. The majority of the updates were installing with incident, but it kept reporting a problem installing two updates – KB967723 (TCP/IP vulnerability) and KB976098 (time zone update).
The error code was 80070490, which isn’t particularly helpful. Most mentions of it I’ve run across in the ‘net involve Vista users who seem to think they need to reinstall their OS. Also not helpful and hopefully not the same problem!
Windows Update was happily installing other updates after the failed attempts, so the problem was specific to those two updates. The event log reported 4374 Warning – “package is not applicable for this system.” Seems that for some reason the Windows Update service was calling the wrong version of the package, as both of those updates apply to all the current Windows operating systems. Downloading each package and manually installing them did the trick.
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.