"Tom Ker" <> wrote in message
news:O9e3$
....
> Got anymore suggestions.
First let's review the ones I have already given you.
>> Do you have a trace of this?
> I'll have to get a trace done when someone is available to assist me.
For the client side this should not be a big deal if you have XPsp2 Pro.
Netcap comes with its Support Tools and is very easy to activate.
Just make sure you pick the right number for the /N:<#> NIC index.
The netcap /? help display seems to list the numbers associated
with my adapters; so that makes that choice really simple.
The .cap file that netcap creates is a binary file but the HTTP protocol
we are interested in is primarily character based. So you can actually
deduce a lot about your trace simply by browsing the .cap file in Notepad.
In order to format it so you can see more detail such as timestamp
and addressing you can use Ethereal or netmon (e.g. if you have
access to a Windows server CD).
I hope that the trace will give you a better insight about the actual
account information being transmitted with the download request
and the resulting messages that your server is giving those.
However, if the transaction is encrypted you may have to get more
help (e.g. to download and activate a WinHTTPTraceCfg.)
Hence my second question:
>> Do you know which accounts are being used in these transactions?
Even without a trace you can get clues about this from Task Manager's
Processes tab. Unfortunately the only obvious one is wuauclt.exe and
it is fairly transient. If you spot it, take note of its PID so you can tell
which messages in the log it was responsible for. The other processes
and their accounts will have to be identified by first finding their PIDs
using this command (e.g.):
tasklist /svc /fi "Imagename eq svchost.exe"
or by using something like
sc queryex wuauserv
and
sc queryex bits
The first command maps better to the Task Manager Processes tab
I think because in there you are only aware of the svchost.exe name.
Given that I suspected that the accounts being used were probably
the most significant detail needed for understanding your problem
I suggested:
>> Have a look at KB842309.
>
> BITS seems logical to me too. But, any BITS KB patch I've tried
> won't install because I have SP2 installed so the patches the KBs
> refer to are already on my system.
You're making the same misinterpretation of my suggestion that John Cehlar did.
I want you to make use of the information in that article to devise a workaround
for your problem.
> I even called MS to get the beta KB832860 (see "Known issues" section),
> but since I don't have SMS installed it refused to go on too.
Ok. So that's the first "issue" and it doesn't apply to your case.
Next issue? ("BITS 2.0 clients may not successfully complete the transfer of a file")
> Not "all the following" conditions are true on my system.
Are you referring to the 3 conditions mentioned in this issue which are
(supposedly) required to *cause* that problem (issue)?
Which conditions have you negated? My point was that most people
only think about negating the third (e.g. bypassing their proxy server
or turning off security within it). Negating one of the others would
appear to involve using some of the information in the next section
of the article. Please describe in detail how you are interpreting
this logic and what you are trying to do with it.
> Attached is the log of the last attempt I made. Thanks for the subtle hint.
<G>
Let's look at it just from the point of view of PID (and account--which is
still unknown...)
2004-10-18 13:20:28-0400 1432 1cc Checking for different Redirector at:
http://download.windowsupdate.com/ms...ir/wuredir.cab
2004-10-18 13:20:28-0400 1432 1cc WinInet: Server file is not newer. Skipping download.
So, 1432 (which I will guess was wuauserv) can communicate
somehow through your proxy server. What is the difference in
authority between the account being used by transactions initiated
by this process and the next one (which fails?)
2004-10-18 13:20:34-0400 920 db4 WU client succeeds CClientCallRecorder::BeginFindUpdates from WindowsUpdate with call id
{36574831-8AC8-4D09-80D5-FA1DD63A78BB}
2004-10-18 13:20:34-0400 920 3ac WU client executing call {36574831-8AC8-4D09-80D5-FA1DD63A78BB} of type Search Call
2004-10-18 13:20:35-0400 3568 9a4 Trying to make out of proc datastore active
2004-10-18 13:20:36-0400 3568 9a4 Out of proc datastore is now active
Now we have two more PIDs to look at. I will guess that 920 is a wuauclt.exe
but I haven't a clue what 3568 would have been. Again, though, I think the most
important detail is which account each of these is running under.
2004-10-18 13:21:54-0400 920 3ac Send failed with hr = 80072f78.
And there is the first failure (which contradicts my first idea that a previous
error might be present in the log before the one which was reported to the
end user).
Unfortunately I don't have a log which demonstrates a successful download
of XPsp2 and I stupidly lost the FileMon trace I took of my last update.
Otherwise I might have a clearer understanding of how to interpret
these messages and the rest of this log.
HTH
Robert
---
Similar Threads
Linear Mode
