Cannot access Microsoft web site

[Muleskinner]

Since automatically installing the April security updates from Microsoft, I
am unable to get access to www.microsoft.com. That does not include those
sites with something infront of microsoft; like www.support.microsoft.com.
those site work just fine.

I have tried all of those things suggested on this newsgroup but no help.

Any help is appreciated.

Bill

 

[Guest]

try removing update KB835732 and see if that helps.
there are bugs ,varying different parts of the system.

 

[C. A. Upsdell]

Since automatically installing the April security updates from Microsoft, I
am unable to get access to www.microsoft.com. That does not include those
sites with something infront of microsoft; like www.support.microsoft.com.
those site work just fine.

I have tried all of those things suggested on this newsgroup but no help.

Same problem, and someone else reported something similar. Try Ping: does
it map www.microsoft.com to www2.microsoft.akadns.net ? If so we all have
the identical problem.

I can use Opera or Mozilla, but some sections of www.microsoft.com only work
with IE.

 

[Muleskinner]

Tried that, no help.

Bill

try removing update KB835732 and see if that helps.
there are bugs ,varying different parts of the system.

 

[Muleskinner]

Yep. Same thing. It does map to www2.microsoft.akadns.net. I tryed to go
to that site and got the Yahoo Search page. I guess that site has been
shut down. That still doesn't help, though. Still locked out of the
microsoft main web site.

 

[H Leboeuf]

"akadns" is used by some tracking parasite.

Try this: Tools > Internet Options > Advanced > Browsing
Uncheck the Enable 3rd party browser extensions

If this clears your problem then find out who the culprit(s) is/are with
these tools.

Let AD-Aware Scan your system for advertising Spyware
http://www.lavasoftusa.com

and:

SpyBot-S&D
http://security.kolla.de/

p.s Reset the 3rd party browser setting.

More: This may be caused by a third-party program (adware, spyware,
parasite).
Get AdAware and SpyBot and run them both. Keep them up to date.
Dealing with Unwanted Spyware, Parasites, Toolbars and Search Engines
http://mvps.org/winhelp2002/unwanted.htm

Additional link:
http://aumha.org/a/quickfix.htm
--

If these tools fails then get help from this forum

Go to http://www.spywareinfo.com/downloads.php#det
Download "Hijack This!" [freeware] or download direct (below):
http://www.merijn.org/files/hijackthis.zip

If you get a 404 error or Access denied, try:
http://216.180.252.218/~spywareinfo.com/downloads/tools/hijackthis.zip

Unzip, double-click "HijackThis.exe" and Press "Scan".

When the scan is finished, the "Scan" button will change into a "Save Log"
button.
Click: "Save Log" (generates "hijackthis.log")

Next, HijackThis | Config [button] | Misc Tools [button]
Click: Generate StartupList log [button] (generates "startuplist.txt")

Next, go to the below location:
http://www.spywareinfo.com/forums/

Sign in, then copy and paste both files in your message.

HijackThis Quick Start Help
http://www.tomcoyote.org/hjt/

The Tutorial if you want to know more about the results or the .log file.
http://www.merijn.org/htlogtutorial.html
_______________________________________
Source: Mike Burgess http://www.mvps.org/winhelp2002/


Henri Leboeuf
Web page: http://www.colba.net/~hlebo49/index.htm
===

 

[C. A. Upsdell]

"akadns" is used by some tracking parasite.

Try this: Tools > Internet Options > Advanced > Browsing
Uncheck the Enable 3rd party browser extensions

If this clears your problem then find out who the culprit(s) is/are with
these tools.

Doesn't fix problem. Also, I have used Spybot, Ad-aware, HijackThis, and
CWshredder, Norton AntiVirus -- all with the latest updates -- with no
problem found.

My gut feeling is that it is a problem created by one of the April security
updates.

One odd characteristic of my problem is that, when trying to access
www.microsoft.com, IE *sometimes* gets part of the HTML: it stalls and
eventually times out, but View Source reveals that *some* of the HTML is
loaded.

Help!

 

[C. A. Upsdell]

try removing update KB835732 and see if that helps.
there are bugs ,varying different parts of the system.

Tried that, no effect.

 

[C. A. Upsdell]

"akadns" is used by some tracking parasite.

Don't think so. Did a google search on akadns.net, appears to be an Akamai
server that Microsoft uses to cache its site.

Note that, although I can't access www.microsoft.com using IE, I can access
www2.microsoft.akadns.net.

 

[the binary kid]

C.A.,

Excuse my ignorance, but...
You've lost me with this PING procedure.
Could you please explain it so I can check it as well.
Thanks.

-----Original Message-----
updates from Microsoft,
I newsgroup but no help.

Same problem, and someone else reported something similar. Try Ping: does
it map www.microsoft.com to www2.microsoft.akadns.net ? If so we all have
the identical problem.

I can use Opera or Mozilla, but some sections of

www.microsoft.com only work

 

[Nobody Anon]

I also had the same problem some weeks ago. I couldn't get into Dell's secure
website and so I had to reformat my hard disk and install just the Windows SP1.
I haven't bothered with various security packs because they are doing more
damage than protecting me. I am sure this may not be the best option for
everybody but I am not bothered with security that much as long as my email and
password does not leak out.

The alternative is to do a restore your system using Restore Point. System
Restore is a component of Windows XP Professional that you can use to restore
your computer to a previous state but you need to know the date when your
system was last working properly.

Hope this helps.

 

[C. A. Upsdell]

Excuse my ignorance, but...
You've lost me with this PING procedure.
Could you please explain it so I can check it as well.
Thanks.

Okay. When I found I could not access www.microsoft.com, one of the things
I did was to ping it. The results were:

C:\DOCUME~1\CHUCK>ping www.microsoft.com

Pinging www2.microsoft.akadns.net [207.46.156.188] with 32 bytes of
data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 207.46.156.188: Packets: Sent = 4, Received = 0,
Lost = 4 (100% loss),

Three things are notable about this. First, ping timed out. Second,
www.microsoft.com was somewhere mapped into www2.microsoft.akadns.net . And
third, despite the timeouts, I can access www.microsoft.com with other
browsers: just not with IE.

Now, if I go to www2.microsoft.akadns.net , what I get is what appears to be
Microsoft's home page, which seems reasonable given that (as other research
indicated) the akadns URL is an Akamai server which Microsoft uses to cache
its site. Indeed, when I use the Akamai URL, all the normal Microsoft pages
appeared to be there.

So ping might imply a problem with www.microsoft.com ... but someone else
said that it is normal for pings on www.microsoft.com to time out ... so I
don't know what ping's results mean in this instance.

So here I am -- one of several people -- wondering why we can't get to
www.microsoft.com using IE. There is some (small) indication that the
problem began after the installation of the April security updates, but this
may be a red herring.

 

[H Leboeuf]

This HOSTS file from Mike Burgess suggest that "akadns.net" is a tracking
service.
http://www.mvps.org/winhelp2002/hosts.htm
--
Microsoft is not one listed (restricted) in the file. But they may be using
is for other reasons.


Henri Leboeuf
Web page: http://www.colba.net/~hlebo49/index.htm
===

 

[C. A. Upsdell]

This HOSTS file from Mike Burgess suggest that "akadns.net" is a tracking
service.
http://www.mvps.org/winhelp2002/hosts.htm

Akadns.net is an Akamai server for caching sites, used by a number of
companies, including Microsoft. The hosts file you cite refers to
Ticketmaster, which would appear to be just another Akamai customer. One
could reasonably wish to block some of Akamai's customers without blocking
others.

Since I cannot access www.microsoft.com, but I can access the Microsoft site
using the Akamai URL, this kind of hints to me that, when IE and Ping look
for www.microsoft.com, they may be confused when www.microsoft.com is mapped
to the Akamai server.

 

[Robert Aldwinckle]

View Source reveals that *some* of the HTML is loaded.

Have you checked for the possibility of an MTU problem?

Here's a repost of a similar reply about that

<excerpt>
If you can ping the problem site try the MTU size test outlined in this article.

<title>KB314825 - How to Troubleshoot Black Hole Router Issues</title>

If you can't get through with a ping, that complicates this procedure
but you could still do those tests with any intermediate nodes
that tracert shows you even if ICMP is blocked before reaching
the final destination.

</excerpt>

A related diagnostic I often suggest is to get some statistics
using a command window procedure. Here's a repost of a reply
I gave earlier this year to somebody who was having the same
problem as you. Substitute the IP address that your ping
is giving you for the one in this example.

<excerpt>
Try using telnet instead. To instrument your test use netstat -s

E.g. I just did that with the address that you gave with the following
five commands entered in a command window:

netstat -s >before.txt
telnet 207.46.244.188 80

<wait for the screen to clear and type GET /
then press Enter
netstat -s >after.txt
fc before.txt after.txt >diff.txt
notepad diff.txt

Here is a summary of that comparison (by subtracting the changed
statistics and reporting only non-zero results):

Packets Received = 36
Received Packets Delivered = 36
Active Opens = 1
Segments Received = 36
Segments Sent = 30

Note: for some reason my first attempt was dropped before I had
had a chance to type the GET command.

Make sure that you minimize the number of other Internet applications
to make your results comparable. Do more than one capture
if necessary to prove that your results are repeatable.

Note that this procedure bypasses the use of DNS.
Your ping test showed that your DNS seems to be working fine
but if the above test works try it again with the symbolic address.
In order to bypass the dnscache and ensure that you do a real lookup
you should first do:
ipconfig /flushdns
(After that I would also do:
ipconfig /displaydns | find /i "microsoft"
just to be sure that no unexpected entries are being added by your
HOSTS file.) Then if you do the same kind of comparison of before
and after statistics you will probably see some indication of the lookup
being done (e.g. with changes in Datagrams statistics).

If it turns out that these tests are successful we will have proved that
connectivity is not the problem. Therefore, it would have to be something
particular that IE and that site are both doing together.
</excerpt>


But considering the deviousness of malware these days I think that
the only way to guarantee that your requests are really going first to the
sites you expect them to is to trace them and verify that. Fortunately XP
makes that possible relatively easily with its netcap utility.


HTH

Robert Aldwinckle

 

[C. A. Upsdell]

New datum: I just discovered that my problem accessing www.microsoft.com
does not occur if I logon as someone else: I had created 4 accounts, all
with administrator privileges, and only with my account can IE not access
www.microsoft.com .

Have you checked for the possibility of an MTU problem?

Here's a repost of a similar reply about that

<excerpt>
If you can ping the problem site try the MTU size test outlined in this article.

<title>KB314825 - How to Troubleshoot Black Hole Router Issues</title>

Using ping with the smallest MTU size (548) still results in timeouts. But
I am inclined to think that the ping tests are not relevant, since Mozilla
and other browsers have no problem at all: it is just IE.

A related diagnostic I often suggest is to get some statistics
using a command window procedure. Here's a repost of a reply
I gave earlier this year to somebody who was having the same
problem as you. Substitute the IP address that your ping
is giving you for the one in this example.

<excerpt>
Try using telnet instead. To instrument your test use netstat -s

E.g. I just did that with the address that you gave with the following
five commands entered in a command window:

netstat -s >before.txt
telnet 207.46.244.188 80

<wait for the screen to clear and type GET /
then press Enter

Results in:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Sun, 02 May 2004 18:50:40 GMT
Connection: close
Content-Length: 35

<h1>Bad Request (Invalid Verb)</h1>

Connection to host lost.

netstat -s >after.txt
fc before.txt after.txt >diff.txt
notepad diff.txt

Here is a summary of that comparison (by subtracting the changed
statistics and reporting only non-zero results):

Packets Received = 36
Received Packets Delivered = 36
Active Opens = 1
Segments Received = 36
Segments Sent = 30

Here's the result of the diff, but I have no idea what the results mean:

Comparing files before.txt and AFTER.TXT
***** before.txt

Packets Received = 329015
Received Header Errors = 0
***** AFTER.TXT

Packets Received = 329080
Received Header Errors = 0
*****

***** before.txt
Received Packets Discarded = 0
Received Packets Delivered = 307983
Output Requests = 241235
Routing Discards = 0
***** AFTER.TXT
Received Packets Discarded = 0
Received Packets Delivered = 308048
Output Requests = 241294
Routing Discards = 0
*****

***** before.txt

Active Opens = 4373
Passive Opens = 469
***** AFTER.TXT

Active Opens = 4374
Passive Opens = 469
*****

***** before.txt
Current Connections = 2
Segments Received = 228314
Segments Sent = 177265
Segments Retransmitted = 280
***** AFTER.TXT
Current Connections = 2
Segments Received = 228358
Segments Sent = 177311
Segments Retransmitted = 280
*****

***** before.txt

Datagrams Received = 74574
No Ports = 5065
Receive Errors = 0
Datagrams Sent = 63418
***** AFTER.TXT

Datagrams Received = 74587
No Ports = 5073
Receive Errors = 0
Datagrams Sent = 63431
*****

Note that this procedure bypasses the use of DNS.
Your ping test showed that your DNS seems to be working fine
but if the above test works try it again with the symbolic address.
In order to bypass the dnscache and ensure that you do a real lookup
you should first do:
ipconfig /flushdns
(After that I would also do:
ipconfig /displaydns | find /i "microsoft"
just to be sure that no unexpected entries are being added by your
HOSTS file.) Then if you do the same kind of comparison of before
and after statistics you will probably see some indication of the lookup
being done (e.g. with changes in Datagrams statistics).

If it turns out that these tests are successful we will have proved that
connectivity is not the problem. Therefore, it would have to be something
particular that IE and that site are both doing together.

Seem to do nothing different of significance.

But considering the deviousness of malware these days I think that
the only way to guarantee that your requests are really going first to the
sites you expect them to is to trace them and verify that. Fortunately XP
makes that possible relatively easily with its netcap utility.

Don't know netcap.

The thing that I noted of most interest is the new datum that the problem
appears to be specific to one WinXP account.

 

[Robert Aldwinckle]

New datum: I just discovered that my problem accessing www.microsoft.com
does not occur if I logon as someone else: I had created 4 accounts, all
with administrator privileges, and only with my account can IE not access
www.microsoft.com .

In that case you should do the same tests with both accounts
and compare the differences of the results.
Also please take care that you don't record your mistakes.
If you make a mistake start the whole procedure over again
so that you are getting a clean picture of the packets involved.
(See below.)

Using ping with the smallest MTU size (548) still results in timeouts. But
I am inclined to think that the ping tests are not relevant, since Mozilla
and other browsers have no problem at all: it is just IE.

That's what I said in my previous reply to the other poster.
Did you try it with any of the intermediate nodes as given by your tracert?

FWIW I did try that and found that the farthest intermediate node which
would return a ping could support a much larger MTU size than
I assume is being used (somewhere between 1400 and 1500). YMMV.

Results in:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Sun, 02 May 2004 18:50:40 GMT
Connection: close
Content-Length: 35

<h1>Bad Request (Invalid Verb)</h1>

Connection to host lost.

I suspect that you typed GET/

I just produced similar results by typing that
(and I didn't even need to press Enter.)

Notice that the request is GET. Then there is a space ( ).
Then there is a slash (/).

When I type GET /
and press Enter (only)
I see

<example first few lines>

HTTP/1.1 200 OK
Date: Mon, 03 May 2004 04:30:55 GMT
Server: Microsoft-IIS/6.0
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Content-Length: 39470
Content-Type: text/html
Expires: Mon, 03 May 2004 04:30:55 GMT
Cache-control: private

<!--TOOLBAR_EXEMPT-->
<HTML>
<HEAD>

Here's the result of the diff, but I have no idea what the results mean:

As I indicated it is useful to make a summary of the diff.txt output
</quote>

Extracted from below. There isn't too much point in doing this
except as an example because you have the wrong data due
to entering the wrong command at the telnet prompt.

Packets Received = 329080 - 329015 = 65
Received Packets Delivered = 308048 - 307983 = 65
Output Requests = 241294 - 241235 = 65
Active Opens = 4374 - 4373 = 1
Segments Received = 228358 - 228314 = 44
Segments Sent = 177311 - 177265 = 46
Datagrams Received = 74587 - 74574 = 13
No Ports = 5073 - 5065 = 8
Datagrams Sent = 63431 - 63418 = 13


BTW it looks to me that you probably recorded more than just that one
transaction. For example, here are my results for that same error.

Packets Received = 33384 - 33351 = 33
Received Packets Discarded = 912 - 906 = 6
Received Packets Delivered = 32472 - 32445 = 27
Output Requests = 31103 - 31075 = 28
Active Opens = 964 - 963 = 1
Segments Received = 18770 - 18764 = 6
Segments Sent = 17193 - 17185 = 8

I have no explanation for either your No Ports number
or my Received Packets Discarded number.
I think that your Datagrams Sent number could indicate
that you used a symbolic name on your telnet command
(instead of an IP address). Or perhaps some other
connection was opened and closed in the same interval.
If that happened then of course the other results would
not be comparable.


HTH

Robert
---