strafeonline

Late last year we installed a Windows 2008 Standard x32bit server for a client. This system was running great, until (or so it seemed), a botched Windows Update patch caused the whole Windows Update system to fail with error 0×80070005. The system, and Windows Updates, were running fine for about two months before it was promoted to a domain controller.

The Windows Update 0×80070005 error is common on Vista machines and somewhat easily fixed (just Google for the error; plenty of results). Rarely have I seen it mentioned in forums and blog posts relating to a Windows Server 2008 system. We’ve manually installed critical updates on the affected system every few months to keep it current - which is a pain. Service Pack 2 failed to install as well, leading us around in circles with System Update Readiness Tool requests and so on.

We’ve just installed a new Dell PowerEdge R610 - Windows Server 2008 Standard x64 SP1 - to act as a primary domain controller, which was performing Windows Updates just fine until we added the Active Directory Domain Services role and ran DCPROMO. After we rebooted, Windows Updates stopped working and presented with the dreaded 0×80070005 error.

The last update to be applied was KB955430, which:

Updates to the Windows Vista and Windows Server 2008 installation software are included in this update. The installation software is the component that handles the installation and the removal of software updates, language packs, optional Windows features, and service packs. This update is necessary to successfully install and to remove Windows Vista SP2 and Windows Server 2008 SP2 on all versions of Windows Vista and Windows Server 2008. This update is not necessary to successfully install the service pack if you install the full file version of the service pack. The full file version of the service pack includes this update.

I have a hunch that a combination of Win 2008 SP1, ADDS, the KB955430 patch, and the system being a domain controller (so; after installing ADDS, running DCPROMO and rebooting) cause the Windows Update mechanism to fail.

As this new R610 is not yet in production, I demoted it using DCPROMO, rebooted, but kept the ADDS role installed. The server now queries Windows Update and our internal WSUS server correctly, AND lets us install SP2

The 0×80070005 error is resolved! Updates are located correctly via Winows Updates and WSUS and install correctly. SP2 also installs correctly; whereas before it would not.

Unfortunately, as soon as you re-promote the system to a domain controller, Windows Updates fail again with the same 0×80070005 error.

Frustrating!!