none
Is it just me, or is update.microsoft.com down ?

    Question

  • For the last 12 hours or so, all attempts to access update.microsoft.com from here in the UK, from two different locations, have failed. ICMP Ping and Tracerts fail to complete. The tracerts, from the two locations, using two different carriers, all seem to end at the same last leg on *.ntwk.msn.net. Also, attempts to Activate a WindowsServer2008 are also failing, and I suspect for the same or similar reason.

    This is the same behaviour from different desktops and operating systems (7,8.1 and WinServer2008) from the two locations. Also, the router in one of the locations allows me to run a tracert on it, and it also fails at the same point.

    As social media isn't awash with others complaining about being able to access update.microsoft.com, has there been a change of FQDN required ?

    No McAfee etc applications or software firewalls (other than Windows) are in use in any of the different devices failing to connect.

    Example below.

    Any help or thoughts appreciated.

    Iain.

    C:\Users\Administrator>tracert update.microsoft.com

    Tracing route to update.microsoft.com.nsatc.net [65.55.138.110]
    over a maximum of 30 hops:

      1     7 ms     8 ms     7 ms  cpc6-sgyl36-2-0-gw.18-2.cable.virginm.net [80.19
    2.32.1]
      2     6 ms     7 ms     6 ms  sgyl-geam-1b-ge347.network.virginmedia.net [62.2
    52.41.253]
      3     6 ms     7 ms     5 ms  sgyl-core-2b-ae2-0.network.virginmedia.net [195.
    182.178.94]
      4    11 ms    15 ms    10 ms  leed-bb-1b-ae5-0.network.virginmedia.net [81.97.
    48.81]
      5    17 ms    19 ms    44 ms  leed-bb-2a-ae2-0.network.virginmedia.net [62.254
    .42.121]
      6    15 ms    15 ms    15 ms  manc-bb-2a-ae0-0.network.virginmedia.net [62.254
    .42.65]
      7    15 ms    19 ms    24 ms  brhm-bb-2a-ae1-0.network.virginmedia.net [62.254
    .42.49]
      8     *        *        *     Request timed out.
      9    19 ms    19 ms    18 ms  tcl5-ic-2-ae0-0.network.virginmedia.net [212.250
    .15.210]
     10    19 ms    18 ms    18 ms  m322-mp2.cvx3-a.ltn.dial.ntli.net [213.104.85.66
    ]
     11    86 ms    87 ms    86 ms  xe-8-1-0-0.nyc-96cbe-1b.ntwk.msn.net [207.46.45.
    225]
     12   121 ms   122 ms   125 ms  xe-1-0-0-0.sn1-96cb-1a.ntwk.msn.net [207.46.43.8
    0]
     13   123 ms   125 ms   124 ms  xe-10-2-0-0.sn1-96cb-1b.ntwk.msn.net [207.46.46.
    193]
     14   151 ms   150 ms   147 ms  ae11-0.lax-96cbe-1a.ntwk.msn.net [204.152.141.13
    6]
     15   156 ms   155 ms   157 ms  ae9-0.by2-96c-1a.ntwk.msn.net [207.46.42.176]
     16   154 ms   156 ms   156 ms  ae0-0.by2-96c-1b.ntwk.msn.net [207.46.40.233]
     17     *        *        *     Request timed out.
     18     *        *        *     Request timed out.
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21     *        *        *     Request timed out.
     22     *        *        *     Request timed out.
     23     *        *        *     Request timed out.
     24     *        *        *     Request timed out.
     25     *        *        *     Request timed out.
     26     *        *        *     Request timed out.
     27     *        *        *     Request timed out.
     28     *        *        *     Request timed out.
     29     *        *        *     Request timed out.
     30     *        *        *     Request timed out.

    Trace complete.

    Thursday, June 12, 2014 11:27 AM

Answers

  • I still believe this is a cleint side issue.

    1) that's odd but clearly shows an issue. depending on the input you send, after you push enter the webserver should respond with an error. I think this might still be a connectivity issue.

    2) not our LAN; Microsoft's LAN/DMZ. It is best practice to not allow icmp in the whole network so it is normal that a tracrt to a public websites stops responding after a given point.

    3) something else that works is no guarantee another thing would

    4) that's bevause both dns as tracert result seem fine.

    5) dns might rersolve another IP because MS uses a lot of servers/datacenters

    6) the required setting depends on your environment. If you don't know, check with your network admin. If other public sites are working, proxy probably is not required (check if you can telnet to websies that work in IE).

    7) hu???? if http://update.microsoft.com works in IE, the issue is not really clear to me (as I undertood that url not working was the issue). If windows update itself is failing, it will give an error code, could you post the error code? 


    MCP/MCSA/MCTS/MCITP

    Friday, June 13, 2014 9:36 AM

All replies

  • Hi,

    It's perfecty up from here.

    the tracert shows you also have dns resolution and probably even connectivity as you end up on a MS network. the Time Outs probably occur due to some firewall refusing ICMP.

    Check if you can telnet to port 80 on update.microsoft.com

    telnet update.microsoft.com 80

    It should connect quicly and give back some html if you enter some characters and press enter. If you can't connect, check the firewall (If your environment is using a proxy perform this test from a computer with direct connectivity).

    Also make sure to test with a clean pc; a lot of malware disturbs connectivity to MS updates.


    MCP/MCSA/MCTS/MCITP


    • Edited by SenneVL Thursday, June 12, 2014 12:21 PM
    Thursday, June 12, 2014 12:21 PM
  • Thanks for the tip. But:

    1. telnet to port 80 does not return any HTML. Just the cursor moving down to the left with every return key press, i.e. I interpret that as input with no response.

    2. I get the same tracert results when I execute tests on my router, suggesting that it's not a firewall on the LAN side, but something further up the network on the WAN side. I have rebooted the router also.

    3. No new software has been installed on the separate WinVista desktop that has also been unable to connect for 18hrs now.

    4. I get the same DNS result, and tracert behaviour here on a different desktop, on an entirely separate corporate lan, using different ISP, peering etc etc. This is not managed by me, indeed a large IT team. It would be strange that two sites had the same issue with a config 'our' side of the two routers.

    Non-authoritative answer:
    Name:    update.microsoft.com.nsatc.net
    Addresses:  65.55.184.15
              157.55.240.94
    Aliases:  update.microsoft.com

    - though I supose there is the ultra slim possibility that multiple boxes on two sites have all been infected by the same malware atr once, but I doubt it.

    5. connections also fail to www.windowsupdate.com. tracerts for this resolve to another IP on the same 3rd party host.

    tracert www.windowsupdate.com
    Tracing route to www.update.microsoft.com.nsatc.net [157.56.96.156]

    6. IE's LAN Settings point at no proxy. I have tried the 'automatically detect' tickbox on and off.

    7. FYI, http://update.microsoft.com works OK in IE. How is that ? I think it resolves to a different content server (akamai)

     - but that's no use as I need the update and activation applications to work on my server.

    Thanks for your thoughts !

    Thursday, June 12, 2014 3:04 PM
  • update: telnet now doesn't connect at all (more what I expected) to the update.microsoft.com or update.microsoft.com.nsatc.net. Both yield a '23' can't connect error. I supsect that the Hyper-V server introduced a virtual NIC and that was somehow in the loop. It doesn't affect the overarching problem though, as still can't update or activate. I can't believe that MS has been down for this duration, nor such a large ISP at fault, and thus bringing darker thoughts to bear that there is malware afoot on an alleged 'clean' install from ISO, where that ISO I didn't create myself.

    Thursday, June 12, 2014 3:26 PM
  • I still believe this is a cleint side issue.

    1) that's odd but clearly shows an issue. depending on the input you send, after you push enter the webserver should respond with an error. I think this might still be a connectivity issue.

    2) not our LAN; Microsoft's LAN/DMZ. It is best practice to not allow icmp in the whole network so it is normal that a tracrt to a public websites stops responding after a given point.

    3) something else that works is no guarantee another thing would

    4) that's bevause both dns as tracert result seem fine.

    5) dns might rersolve another IP because MS uses a lot of servers/datacenters

    6) the required setting depends on your environment. If you don't know, check with your network admin. If other public sites are working, proxy probably is not required (check if you can telnet to websies that work in IE).

    7) hu???? if http://update.microsoft.com works in IE, the issue is not really clear to me (as I undertood that url not working was the issue). If windows update itself is failing, it will give an error code, could you post the error code? 


    MCP/MCSA/MCTS/MCITP

    Friday, June 13, 2014 9:36 AM
  • Hi,

    As SenneVL mentioned, did the http://update.microsoft.com work in IE?

    If the update failed, please check the update log:

    %windir%\Windowsupdate.log

    Regards.


    Vivian Wang

    Monday, June 16, 2014 10:05 AM
  • Hi

    Any update about the issue?

    Regards.


    Vivian Wang

    Tuesday, June 24, 2014 5:38 AM
  • are you able to ping public DNS such as 8.8.8.8 or 4.2.2.2?

    If you just enter manually from the web browser are you able to browse the page?


    Every second counts..make use of it. Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.
    IT Stuff Quick Bytes

    Tuesday, June 24, 2014 6:06 AM