Re: Update still failing with 80240020 and 8024000c
From: Robert Aldwinckle (robald_at_techemail.com)
Date: 10/27/04
- Next message: scornforth: "Javascript windows will not open in Internet Explorer since update"
- Previous message: Johnydii: "RE: Microsoft .NET Framework 1.1 Service Pack 1 remove"
- In reply to: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Next in thread: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Reply: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 27 Oct 2004 11:09:16 -0400
"lbertacco" <lbertacco@discussions.microsoft.com> wrote in message
news:CFEB3D3E-A837-4994-A6EF-A48C698060FE@microsoft.com...
> Hi Robert
>
>> I'm still not exactly clear what I have but it looks as if
>> my Download subdirectory contains only files with names
>> each having 40 hex characters and no extensions.
>
> Well, my download subdir contains those too. The tree I've shown is that of
> the SoftwareDistribution dir. My download subdir however contains, besides
> hex number named files, another (still hex number named) subdir with lots of
> other file/subdirs. Maybe this is a consequence of some old and big update ?
> (sp1?)
Oh. Perhaps. I was thinking it would represent a failed install,
e.g. thinking that running one of those executable 40-hexdigit
files would create a bunch of work folders to expand their contents
into and from there they would be installed into the appropriate existing
folders. You could actually check on that by looking at the create date
and timestamp of that mystery subdirectory. (E.g. dir/tc )
BTW What is the history of your SoftwareDistribution folder?
In my case it was created when I installed XPsp2RC1
and then I didn't realize that it would be best to clear it
after upgrading to XPsp2RTM (by CD). I eventually cleared it
as I have documented elsewhere in order to verify that AU was
working properly but there just weren't any updates being served to it.
It would have been interesting I think to see if AU would have
worked without that intervention; however, the log was definitely
cleaner (fewer error messages) afterwards.
I imagine also that if your problem is simply a question of the installing
account and the authority it has you might even have some success
simply running one of those "executables" under your own account
(assuming it has sufficient authority). Note that this is highly speculative
and again (kicking myself) would have been made much clearer if I hadn't lost
that FileMon trace I had. I think I am just going to have to wait for the
next patch to be downloaded as my next opportunity to study how it
actually works. Who knows? By the time that happens we may actually
have some better official documentation which will make all this reverse
engineering unnecessary.
>
>> What is your objective?
>
> I'd like to make this thing working again, but in a rational way. Not just
> reinstalling Windows or doing some other nonsense which might for some
> unknown reason solve this problem (and possible cause many others)
>
>> Or, if you would like to try to get WU
>> working but don't care why see if Torgeir's tip about proxycfg helps
>> you out.
> No proxy configured. And BTW my WU download updates allright, just can't
> install them.
That's why I referred you to Torgeir's posts. A recent explanation
he gave about it made it sound as if it could have wider applicability
than the name of the command suggests. The post I am thinking
of specifically definitely made mention that different accounts and
different account authority could explain why some phases of the
update could occur but not others. (It may only have been the
checking phase which could mean that the accounts used by different
programs were involved, e.g. the account used with wuauclt.exe
versus the account used with Background Intelligent Transfer Service.)
So in your case there would be a third-phase (installing) with its own
account authority questions. Hmm... what if those "executables"
we found really are run? Do you have any software or other restrictions
which might inhibit that from occurring? (e.g. trying to execute something
which doesn't have a clearly identifiable extension) Perhaps a related
question: have you checked out the sc sdshow and sc sdset commands
which others have been advised to use for their symptoms?
(e.g. maybe there is something embedded in all that cryptic stuff
which accidently implements such a restriction and prevents
the service from executing those files.) Etc.
>
> See also my post of yesterday about scheduled tasks.
I don't use the scheduler feature.
Discussing it would be off-topic for this newsgroup
so you would do better to try looking in a newsgroup
for your OS or somewhere there would be admin types
who should be more knowledgeable about automation
techniques.
Good luck
Robert
---
- Next message: scornforth: "Javascript windows will not open in Internet Explorer since update"
- Previous message: Johnydii: "RE: Microsoft .NET Framework 1.1 Service Pack 1 remove"
- In reply to: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Next in thread: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Reply: lbertacco: "Re: Update still failing with 80240020 and 8024000c"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
