error 0x8DDD002 in IE, 0x80070005 in log

OK, I've got WU problems on a machine running XP Home SP2. WU via I
displays the following error on the web page:

>
> Error number: 0x8DDD0002
>
> To install items from Windows Update, you must be logged on
> as an administrator or a member of the Administrators group.
> If your computer is connected to a network, network policy
> settings may also prevent you from completing this
> procedure.

'KB article #316524' (http://support.microsoft.com/kb/316524/en-us
precisely describes the issue but doesn't solve it. I've been postin
this problem 'over at sysinternals
(http://www.sysinternals.com/forum/fo...?TID=3521&PN=1) a
well since I was using their lovely freeware to analyze this a bi
further but so far I've not been able to track it down. Please read u
on what I've tried so far and save me some time.

I've seen some other posts here describing the same problem but hey
let's crack this together..


Starting on Jan 6 -- coinciding with the publication of Microsoft's wm
patch and the first time the issue was noted -- the WU log begins t
show 0x80070005 error codes. Google tells me that this is possibl
related to incorrect permissions on certain registry entries, a ke
consideration in the 'KB article
(http://support.microsoft.com/kb/316524/en-us) mentioned above.

One of the first things I've tried was to set the permissions of

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\WindowsUpdate

and

\WINDOWS\SoftwareDistribution

to *everyone *and *full control / read access* (in XP Home you have t
go into safe mode to set the security settings for the folder, as man
previous posters have noted as well). Apparently the permissions didn'
stick -- I checked on the permissions with Sysinternal's 'AccessEnum
(http://www.sysinternals.com/Utilities/AccessEnum.html) tool and foun
them *not* set to 'everyone'. So I tried again, and now it seems t
stick in both cases. No joy though with regards to WUpdate.

I've also taken a snapshot of registry key accesses with 'RegMon
(http://www.sysinternals.com/Utilities/Regmon.html) while trying t
access WU via IE but I haven't been able to analyze it yet.

Any thoughts?

PS. I'll post a typical WU log session here in a minute for you
perusal. Or look at it over at my sysinterals post. Oh, and let me kno
if you need any more details on the system / config, etc

--
archi
Posted via http://ms-os.com Forum to Usenet gatewa

Looking at the log file again, I noticed that the file *\..\wuredir.cab
in the *%windir%\SoftwareDistribution* folder was where things seem t
go wrong during the update sessions. Posters elsewhere have als
pointed at the SoftwareDistribution folder as the most likely source o
trouble. I decided to go with elective surgery and delete th
%windir%\SD folder while in safe mode. Huzzah!

Problem solved. Others 'confirm success using this method.
(http://www.annoyances.org/exec/forum/winxp/t1105035343) The plac
where you cannot read up about this is Microsoft's KB library - dare
say predictably so? You never know, MS employees might actually rea
this and revise 'their incomplete KB article #316524
(http://support.microsoft.com/kb/316524/en-us) which is supposed t
deal with precisely this issue.

Anyway, hope this will help someone.

--
archi
Posted via http://ms-os.com Forum to Usenet gatewa

"archis" <> wrote in message
news:...
>
> Looking at the log file again, I noticed that the file *\..\wuredir.cab*
> in the *%windir%\SoftwareDistribution* folder was where things seem to
> go wrong during the update sessions. Posters elsewhere have also
> pointed at the SoftwareDistribution folder as the most likely source of
> trouble. I decided to go with elective surgery and delete the
> %windir%\SD folder while in safe mode. Huzzah!
>
> Problem solved. Others 'confirm success using this method.'
> (http://www.annoyances.org/exec/forum/winxp/t1105035343) The place
> where you cannot read up about this is Microsoft's KB library - dare I
> say predictably so? You never know, MS employees might actually read
> this and revise 'their incomplete KB article #316524'
> (http://support.microsoft.com/kb/316524/en-us) which is supposed to
> deal with precisely this issue.


They do. Method 4. Deleting the folder would have the same effect
as changing the permissions in that case.


---


>
> Anyway, hope this will help someone..
>
>
> --
> archis
> Posted via http://ms-os.com Forum to Usenet gateway
>