NCSI, or the Network Connectivity Status Indicator, is that annoying icon in the system tray that insists on telling you that you have no internet access despite your being perfectly able to surf the web.

Normally this discrepancy doesn’t matter, but if you’re using Office 2013 and trying to connect to Office 365 it poses a problem, as the Office suite will not connect to cloud services if the PC thinks it’s offline.

Working out why NCSI is wrong requires understanding how it works – or at least is supposed to work. This Technet article explains its behavior in Vista, which is where NCSI was first introduced. Then we have this blog post, which is backed up by the author’s own packet traces. The blog post is quite good and does a better (and seemingly more accurate) job explaining NCSI than the Technet article, but there are a couple of points I’d like to clarify based on what we saw in our environment.

To very quickly summarize how NCSI determines connectivity status:

• It first performs an HTTP request for http://www.msftncsi.com/ncsi.txt, then
• Performs a DNS lookup for dns.msftncsi.com to confirm the proper IP address is returned.

This should typically work well in a simple home environment, but in an enterprise there are any number of points where the HTTP request can be intercepted: perimeter firewall, IDS/IPS, proxy, content filter, endpoint firewall, antivirus, etc. And if that request fails, Windows considers you to be disconnected from the Internet.

What kept throwing us off during our own troubleshooting of this problem was that while we saw the DNS queries for www.msftncsi.com as the system tried to resolve the webserver IP, we never saw the HTTP request go out. The Technet article indicates this should happen the first time a user logs on after a reboot, and both articles refer to it happening the first time a computer joins a new network.

That latter point seems to be correct, but it’s important to note the “new” part of that statement: a network connection coming online is not sufficient, rather the network detected has to be different. It’s not clear what constitutes different, but changing proxy settings appears to be sufficient; disconnecting the network cable is not.

As to the former statement: Perhaps in Vista the HTTP request happened when a user logged on, but on 7 and 8.1, this is not what we saw. Instead we only saw the HTTP request go out once, as the computer started up. To be clear, a user login was not triggering network detection, and we never saw that HTTP request go out again after the computer booted. That means – and this is the important part – that if that initial HTTP request during boot fails, the system will think you are disconnected from the Internet and will never discover otherwise.

Remember all those possible applications that can interfere with the HTTP request? If any of them are keyed to only permit traffic based on the logged on user, you may have an issue, since the HTTP request will almost always be sent before anyone is logged on. That was our problem; we needed to allow all traffic to www.msftncsi.com even if nobody was logged on to a PC.

There’s one other caveat to be aware of: the HTTP request comes through winhttp, which does not inherit IE’s proxy settings. So if you’re using an explicit proxy without WPAD, you will need to manually configure winhttp with your proxy settings.

Other than the clarification those two points, the blog post linked earlier seems correct and is a good reference if you’re looking to change any other NCSI settings. Hopefully you won’t have to.

Update 9-27-16: While working on an unrelated problem, I found our Win 10 machines are reaching out to http://www.msftconnecttest.com. I don’t have the time right now to test this but on the surface it seems this is yet another online check that MS has started using. I recommend allowing traffic to this site as well.