Have you ever been connecting to a new wireless network and seen the following pop-up balloon?
Whenever I connect to a WiFi network which requires in-browser authentication, such as university networks and hotel access points, Windows somehow magically knows. Windows also knows when your internet connection isn’t working, and can differentiate between having local LAN access, no network access at all, or full internet access. But how?
This week’s question of the week is one I myself asked about this very topic. I guessed that there must be some online Microsoft site that Windows is checking to determine the state of the connection, but I wanted proof, not just speculation.
Tobias Plutat and Jeff Atwood both replied with information about the (NCSI) service, first introduced in Windows Vista.
When called on by Network Awareness, NCSI can add information about the following capabilities for a given network:
- Connectivity to an intranet
- Connectivity to the Internet (possibly including the ability to send a DNS query and obtain the correct resolution of a DNS name)
NCSI is designed to be responsive to network conditions, so it examines the connectivity of a network in a variety of ways. For example, NCSI tests connectivity by trying to connect to a simple Web site that exists only to support the functionality of NCSI.
Windows does indeed check a Microsoft site for connectivity, using the Network Connectivity Status Indicator site. There are a few variations of the connection checking process:
- NCSI performs a DNS lookup on then requests This file is a plain-text file and contains only the text Microsoft NCSI.
- NCSI sends a DNS lookup request for dns.msftncsi.com. This DNS address should resolve to 131.107.255.255. If the address does not match, then it is assumed that the internet connection is not functioning correctly.
The exact sequence of when which test is run is not documented; however, a little bit of digging around with a packet sniffing tool like Wireshark reveals some info. It appears that on any connection, the first thing NCSI does is requests the text file (step 1 above). NCSI expects a 200 OK response header with the proper text returned. If the response is never received, or if there is a redirect, then a DNS request for dns.msftncsi.com is made. If DNS resolves properly but the page is inaccessible, then it is assumed that there is a working internet connection, but an in-browser authentication page is blocking access to the file. This results in the pop-up balloon above. If DNS resolution fails or returns the wrong address, then it is assumed that the internet connection is completely unsuccessful, and the “no internet access” error is shown.
The order of events appears to be slightly different depending on whether the wireless network is saved, has been connected to before even if it is not in the saved connections list, and possibly depending on the encryption type. The DNS and HTTP requests and responses showing up in Wireshark were not always consistent, even connecting to the same network, so it’s not entirely clear what causes different methods of detection under different scenarios.
Some people may be concerned about Windows “phoning home” to Microsoft with their PC’s information through this service. According to Microsoft’s documentation, NCSI retains the time of access and IP addresses of requests made to www.msftncsi.com:
IIS logs are stored on the server at These logs contain the time of each access and the IP address recorded for that access. These IP addresses are not used to identify users, and in many cases, they are the address of a network address translation (NAT) computer or proxy server, not a specific client behind that NAT computer or proxy server.
