Robert,
Thanks for the suggestions. I agree that these are good tools. Your ideas
are a great way to go about debugging the fault.
The actual problem appears to have been either at Microsoft or between me
and Microsoft. The service started answering wtih no changes on my part later
in the day.
I have some experiance developing large shared Internet systems, and I
understand many of the issues MS must face. Even so, I think the architecture
of the update tools and server systems is clearly not as rich or robust as it
might be. I say this to be constructive, not critical.
At this point the errors generated by the client applciation (the activeX
control and page logic) are not very helpful when connectivity fails. There
is really only one message for many situations. I think we need a way to get
much more diagnostic information, and of course that requires a combination
of more inteligence on the control, and more services on the net. For
example, I need to have alternate locations that can at least respond to let
me know I am reaching the correct general site, even if the update service
can not now handle the connection.
I am well prepared to wait for the service to come back, but I need to at
least know that I am able to reach the proper site. This is actually a
complex thing to do, and I understand that it may not be perfect. I do think
that building more debug capactiy into the service and the control is
reasonable considering the importance of updates to a Microsoft customer. As
an administrator and customer, I should not have to debug Microsoft's tool.
It should come with a wide range of dependable diagnostic modes to tell me
and the support team what is happening and how to fix it (or wait for it to
get fixed),
I use a variety of update products for many systems including commercial
tools from third parties for the MS environment. Most offer more stability,
feedback, and diagnostic services than the currnet Microsoft offering. I
believe MS can do better, and should. I do not expect miracles, but I would
like to see some improvments in this update service. I especially want to
have more diagnostic information to work with when I have to call support, or
maybe enough to know I can just wait and not bother support. This would save
MS money, and make me a lot happier - a win-win as I see it.
"Robert Aldwinckle" wrote:
> "Cecil Thornhill" <Cecil > wrote in message
> news:60CAAF02-9F5A-42A0-85B3-...
> > Suddenly (updates were fine Friday last time I did them) MS Updates do not
> > work. I have tried all listed solutions (KB and help articles) but still just
> > get 0x80072EFD. I did get through for a brief time today so all three of my
> > XPProSP2 systems are current as of now, but the failures are very distrubing.
> >
> > Port 443 works fine, my router and hardware firewalls are fine, all other
> > systems are as they have been - no new installs...What gives? If the service
> > is having a problem or outage I can live with that, but we get no warning or
> > feedback, so how can we tell if it is US or MS?
> >
> > How can I debug this?
>
>
> FiddlerTool + RPASpy could show you the URLs involved.
> netcap + Ethereal could show you any other protocol problems.
>
>
> >
> > Yes I can download from the MS downloads site just fine...so the net is up
> > and I can reach other ssl sites fine as well (so the port works). Any real
> > diagnostic tool would be appreciated.
> >
> >
>
>
> Good luck
>
> Robert Aldwinckle
> ---
>
>
>
Similar Threads
Linear Mode
