We seem to have several clients that can't scan or patch. In the ScanAgent.log we see:

CScanTool::Execute- Failed at AddUpdateSource, error = 0x80004005

- - - - - -Scan Failed for ToolUniqueID={9A3A916C-C182-4801-A0B3-709F0F172D5B}, with Error=0x80004005

The WUAHandler.log shows:

Unable to find or read WUA Managed server policy.

Unable to read existing WUA Group Policy object. Error = 0x80004005.

Enabling WUA Managed server policy to use server: http://SERVERNAME.Company.COM:80

Failed to Add Update Source for WUAgent of type (2) and id ({9A3A916C-C182-4801-A0B3-709F0F172D5B}). Error = 0x80004005.

These all tend to be various clients in various OU's that have no GPO's related to WSUS. Other clients in the same OU's are scanning and patching fine. I have tried to uninstall and reinstall these clients, re-register WUA .dll's, upgrade the WindowsUpdateAgent, and even delete the SoftwareDistribution folder so that it would recreate it. I still get the same errors. I know I have had several PCs rebuilt, but that isn't the best solution if there is something else that can be done. Any help would be greatly appreciated.

Thanks.

My group also has this issue. Is anyone from Microsoft (or anywhere else) going to reply or comment?

I am noticing that the server is listed as http://SERVERNAME.Company.COM:80. Perhaps I missed it but, is that in fact the correct server? I assume you would have caught that.

Maybe more useful, I wonder if it has to do with the fact it is using port 80. Is the same server running the reporting point role? That could end up causing a conflict on port 80. I think that the recommendation and the way I have always done it is to use the custom WSUS port of 8530/8531. You could try changing that using the wsusutil tool from the WSUS installation to change to the custom website. Then you would need to change the ports in the SUP component.

Had the same issue. Issue appears to be with corrupt policy info locally on the machine. Typically going to c:\windows\system32\grouppolicy\machine and delete registry.pol As soon as I do that I can tell the client to perform an updates scan and all is well. More than likely there is a more elegant solution, but that resolves this error message for me. HTH.

• Marked as answer by messamt Friday, March 27, 2009 7:37 PM

Had the same issue. Issue appears to be with corrupt policy info locally on the machine. Typically going to c:\windows\system32\grouppolicy\machine and delete registry.pol As soon as I do that I can tell the client to perform an updates scan and all is well. More than likely there is a more elegant solution, but that resolves this error message for me. HTH.

• Marked as answer by messamt Friday, March 27, 2009 7:37 PM

bmsmith1911 - Thanks for the workaround. It worked great. I don't know how many times I have looked up the same error, and found my own post. Finally an answer that seems to work for me!

Had the same issue. Issue appears to be with corrupt policy info locally on the machine. Typically going to c:\windows\system32\grouppolicy\machine and delete registry.pol As soon as I do that I can tell the client to perform an updates scan and all is well. More than likely there is a more elegant solution, but that resolves this error message for me. HTH.

I had same problem and deleting registry.pol in GroupPolicy fixed the issue, right away.
Vielen Dank bmsmith1911!!!!
--emax

Hey Guys,

I've experience the same issue before. All I did was remove and clear the origion policy on the client machine then send a new policy. The tool i used to remove and refresh the policy was Right-Click tools found on MyItForum. http://myitforum.com/cs2/blogs/rhouchins/archive/2008/04/09/sccm-right-click-tools.aspx its a pretty useful tool. Check it out!

I am experiencing the same issue except that the registry.pol file doesn't exist in c:\windows\system32\grouppolicy\machine.  GPO appears to be applying successfully.  I can see the settings in the registry and the success event in the event log, but this file never gets created.  I have tried taking ownership of the folder, replacing the permissions on it, granting Everyone full control, nothing works.  I somehow got it to work on one XP machine but have not been able to recreate the fix.  Once the registry.pol file appeared on that one machine, the scans started working. 

I finally figured out what the problem was in my environment.  These clients have a local user account with a local security policy that restricts that user to only being able to use one application.  The way I understand it, the only way to keep that local user policy from applying to the local Administrator account also was to put a deny ACL on the c:\windows\system32\grouppolicy\user\registry.pol file.  The deny ACL on this file denied the whole Administrators group, which includes Local System.  Once I changed it to allow the Administrators group and deny only for the local Administrator account, the scans started working.  The SCCM client needs to modify the local machine security policy for the scans to work.  Without access to this file, a user (or even the Local System) cannot modify the local security policy at all.  That is why I was getting "Access Denied" errors.

Had the same issue with one machine not reporting back its Software Update status. Deleting the registry.pol worked for me too. As soon as I deleted the file and then forced a Software Update scan through the CM client, the Wupdate.log showed proper connectivity. Took a while for the console to update.

Great! Worked immediatly! Thank you for supporting the communitiy with this helpful hint!

bmsmith1911 you sir are the man (or woman) lol.  Your solution worked for me!!!!  Thanks!!

Thanks!. That worked for me too!

c:\windows\system32\grouppolicy\machine and delete registry.pol

(Unable to read existing WUA Group Policy object. Error = 0x80004005.)

• Edited by dude -d Wednesday, December 17, 2014 1:16 PM

Thanks!. That worked for me too!

c:\windows\system32\grouppolicy\machine and delete registry.pol

(Unable to read existing WUA Group Policy object. Error = 0x80004005.)

• Edited by dude -d Wednesday, December 17, 2014 1:16 PM

Thanks!  Fixed it for me too