I encountered this problem on all new servers machines installed and joined to domain (the old ones worked fine). I found a recovery method on the Internet that helped me. Run the following command:
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose /log secsetup-repair.log
This command reset the permissions and from then on everything worked OK.
I got the 0x80070643 error on a Windows 2000 Server while installing .NET Framework 2.0 via WSUS. In my case, I had only 500MB left on my System Drive. "Cleaning up" the drive solved the problem.
I encountered this problem on a Windows 2000 server. Not only were automatic updates failing but also Service Packs. Looking in the windows update log I found the following exception hex: Error 0x8007F004 (access is denied).
I first made sure that the entire %systemroot% directory structure was set to full control access for both the local administrators group and the system group. I then verified that the registry (HKLM) hive was also OK by pulling the system off the wire and running the following to reset any potential GPO related changes:
”secedit /configure /cfg basicsv.inf /db basicsv.sdb /log basicsv.log /verbose“.
This will output a log file to %systemroot%\security\basicsv.log. In looking through this log, I found several registry keys that were showing “access is denied”. I opened up regedt32 and viewed the registry key security to show that only the Everyone group had been granted read access. Attempts to modify the registry key gave me “access is denied” errors. I attempted to take ownership of the keys but got the same result. I then created a new account and added it to the local administrators group. Logged in with that account, successfully took ownership of the failed keys, propagated through inheritance permissions from the tree, rebooted the machine, and was then able to successfully apply patches again. I suspect that this condition can be attributed to viral activity on the box, although I could not find any evidence to prove that for sure.
The Microsoft article ME319585
Also from a newsgroup post: "For WinXP, renaming or deleting the Catroot2 folder may solve the problem. See ME326815
link and follow the steps 6 to 8 in the Resolution section (do a reboot first so the computer is "fresh"). Then try to install the update again."
Some of the Windows 2000 security updates appear to try and access the M: drive if Exchange 2000 is installed. This seems to cause the updates to fail. Stopping the Exchange Information store, or applying the update manually seems to fix the problem.