"cairey" <> wrote in message
news:BFC1AFD0-9F31-4001-A8BB-
....
> "Robert Aldwinckle" wrote:
>> Are you sure that the update is downloading? I don't think that that
>> is clear from the log.
> I'm pretty sure the update is downloading. The progress bar when it updates
> is visible. Whether or not it's getting properly saved to the hard drive in
> the "right way" I don't know.
Then try the diagnostic I first suggested to Alain Caillet.
If there are files being downloaded this procedure should
show you where they are being saved:
<quote>
BTW I have just found out how much stuff gets written in that
SoftwareDistribution directory. (I ran FileMon filtering on that
directory name while trying to get AU working.) For a Q&D way
to list all the changes made in it on a particular day you could use
this command pipeline:
dir/s/od | findstr "Directory 2004-09-18"
Modify that for your system as necessary. For example, the word
"Directory", the date format and of course the date itself.
A reason for doing this is that it might expose things that are being
done which are not reflected by the traces. Also by comparing your
results with someone else's whose WU was working better it could
give a more concrete list of what is not being done.
</quote>
Now that I am aware how critical the contents of that directory may be
I regret not cleaning it up before upgrading from XPsp2RC2.
After not having much success getting AU working again I tried
a suggestion that Torgeir Bakken has been making recently:
<quote>
To reset the pending download you now have, clean out the Download
folder (WU5's temporary download folder) located here:
%windir%\SoftwareDistribution\
(%windir% is typically C:\Windows)
You can use the procedure described here:
http://v5.windowsupdate.microsoft.co...cleid=11&ln=en
You might need to delete the DataStore folder mentioned in the link
above, as well as the EventCache folder.
</quote>
FWIW I had to delete the contents of all three subdirectories
he mentioned: Download, DataStore and EventCache
before wuauclt.exe kept working. (More about that below.)
>> The 8007 class of errors seem to have something to do with
>> authentication. So my guess would be that you could next take
>> a look at that regarding your BITS service. E.g. check in the
>> Log On tab of the BITS Properties page what account BITS
>> is supposed to be run under.
>>
>> Etc.
> I get the message failed to install when I try to install it basically,
> and that is my exact log of those errors. I have tried your advice.
> My BITS service is running on Local System Account.
I think that BITS was a bad guess. Now that I have used
Torgeir's advice I have found that wuauclt.exe is the other process
which is sending the error message. After restarting the AU service
(per the troubleshooting article) check to see if wuauclt.exe is running
and notice its account. My guess is that it may be running under the
same account that the svchost.exe that wuauserv runs under.
Use Task Manager to see the accounts. To identify the correct PID
that the service runs under enter this command:
tasklist /svc /fi "Imagename eq svchost.exe"
If wuauclt.exe is not running I have found that you can make it run
by using the Windows Update site. BTW I found it necessary to press
Ctrl-F5 to refresh all the bits being used by that page and that caused
the WUV5 controls to be redownloaded.
Another way to start it apparently (which I am still experimenting
with) is: Run... wuauclt /detectnow
That would also make that process run under your account.
It doesn't stay running; so I suspect that things still aren't
quite right but the log is a lot cleaner now. More importantly
on my XPsp1 partition I was given the opportunity to update
to XPsp2RTM which proves that WUV5 does work (which
I was beginning to have some doubts about <g>).
I think my problems with AU on the client side are being
further confused by the apparent lack of any updates
being offered by the server that way. E.g. on my XPsp1
partition WU shows 3 updates total but AU only shows
the one I mentioned.
HTH
Robert
---