Have you ever wondered how Windows knows you’re connected to the Internet? You may have noticed the over the network icon by the clock, have you ever wondered what happens in the background? This blog aims to find answers to these and related questions.
When a Windows machine connects to a network, there are two technologies, Network Location Awareness (NLA) and Network Connection Status Indicator (NCSI); it uses to automatically identify the network it is connecting to and whether or not it has access to the Internet. We are specifically going to talk about Network Connection Status Indicator (NCSI) in this blog, for more information on Network Location Awareness (NLA) and firewall profile determination please refer to the following blog http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx
Network Connection Status Indicator (NCSI)
Network Connection Status Indicator (NCSI) is part of NlaSvc (the Network Location Awareness service) and is responsible for detecting Internet connectivity status. It is also responsible for dynamically detecting corporate network connectivity status when using DirectAccess. This in turns is used by the Network List Manager to report network connectivity through a NLM_CONNECTIVITY Network List Manager API call (http://msdn.microsoft.com/en-us/library/windows/desktop/aa370795(v=vs.85).aspx). Applications and services can then use this information to filter networks, based on the attributes and signatures, to choose the networks best suited to their tasks.
Network Awareness collects characteristics such as the Domain Name System (DNS) suffix of the computer, the forest name, and gateway address of networks that the computer has connected to. 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 (including the ability to send a DNS query and obtain the correct resolution of a DNS name)
Since the connection status icon can only show the status for one connection it will aggregate the individual statuses and display the most limited connection. Therefore if more than one network adapter is present, but only one probe succeeds, Windows will still report “Limited Access “and indicate a Local only status. In Microsoft DirectAccess, NCSI is also used for Inside/outside determination (Outside corporate network or Inside corporate network). To do this the NCSI process tries to communicate with the I/O (Inside/Outside) server using an HTTPS query.
How does it work?
NCSI is designed to respond to changes in network conditions, and examines the status of a network connection in a variety of ways. First it uses an active probe to determine the status. For example, in an active probe NCSI tests connectivity by trying to reach http://www.msftncsi.com, a simple Web site that exists only to support the functionality of NCSI. Eventually, as other programs begin generating Internet traffic, NCSI switches to a passive monitoring process that assumes responsibility for detecting changes to the network status.
The Active Probe Process
Every time a network configuration event occurs (meaning that something has changed in the network configuration), the NCSI process performs several tests to identify the network’s connectivity status. The first step NCSI performs is a DNS query for www.msftncsi.com. The second step is and HTTP get request for http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text “Microsoft NCSI.” Last it will perform a DNS query for dns.msftncsi.com.
Note: In an environment that does not have a proxy; a DNS probe will be used if the system remains in the same network as the network that a previous active probe detected.
What does this look like underneath?
To see what really happens underneath I took a network trace using Microsoft Network Monitor while I was trying to connect to my wireless router and this is what I saw:
First I filtered on DNS and HTTP, we see that the client sends a DNS query for www.msftncsi.com and we get a DNS response with a list of IP addresses:
WIRELESS 192.168.0.1 DNS DNS:QueryId = 0x7F51, QUERY (Standard query), Query for www.msftncsi.com of type Host Addr on class Internet
192.168.0.1 WIRELESS DNS DNS:QueryId = 0x7F51, QUERY (Standard query), Response – Success, 184.108.40.206, 220.127.116.11 …
When connecting for the first time to a network, NCSI performs an HTTP probe to determine internet connectivity. The client makes an HTTP request to get ncsi.txt, once the client gets the HTTP/1.1, Status: Ok it is successfully able to determine the status of the network connection.
WIRELESS ncsi.glbdns.microsoft.com HTTP HTTP:Request, GET /ncsi.txt
ncsi.glbdns.microsoft.com WIRELESS HTTP HTTP:Response, HTTP/1.1, Status: Ok, URL: /ncsi.txt
If that probe is successful, NCSI uses a DNS probe on subsequent connections to the same network that looks like this:First the client makes a standard DNS Query for an A record of dns.msftncsi.com
WIRELESS 192.168.0.1 DNS DNS:QueryId = 0x84AF, QUERY (Standard query), Query for dns.msftncsi.com of type Host Addr on class Internet
192.168.0.1 WIRELESS DNS DNS:QueryId = 0x84AF, QUERY (Standard query), Response – Success, Array[18.104.22.168,22.214.171.124,2A01:111:2005:0:0:0:1:1,126.96.36.199,2A01:111:2006:6:0:0:1:1,188.8.131.52,2A01:111:2020:0:0:0:1:1,184.108.40.206,2404:F800:2003:0:0:0:1:1,220.127.116.11,2A01:11
Then we see the client make a standard DNS Query for an AAAA record of dns.msftncsi.com
WIRELESS 192.168.0.1 DNS DNS:QueryId = 0x7C87, QUERY (Standard query), Query for dns.msftncsi.com of type AAAA on class Internet
192.168.0.1 WIRELESS DNS DNS:QueryId = 0x7C87, QUERY (Standard query), Response – Success, Array[FD3E:4F5A:5B81:0:0:0:0:1,18.104.22.168,2A01:111:2020:0:0:0:1:1,22.214.171.124,2A01:111:2005:0:0:0:1:1,126.96.36.199,2A01:111:200F:1:0:0:1:1,188.8.131.52,2A01:111:2006:6:0:0:1:1,184.108.40.206
Note: NCSI uses the MAC address of the gateway to uniquely identify a network and whether it should do the DNS probe or the HTTP probe.
The Passive Probe Process
When other programs generate Internet traffic, NCSI begins to use passive monitoring, and passive monitoring detects the correct network status based on the successful completion of the TCP connection made by other programs.
What if I want to disable NCSI?
Microsoft does not recommend disabling NCSI, but some of NCSI’s functionality can be safely disabled or reconfigured.
Typically we see customers that are concerned about the probes sent from NCSI (HTTP probe to www.msftncsi.com, DNS probe to dns.msftncsi.com). While there is a group policy setting to disable active probes, it has the potential side effect of causing an inaccurate network status. If you are concerned about the probes, an alternative is to reconfigure the probes to use your own instead of Microsoft’s public’ servers.
There are two options to change the NCSI probe behavior – disable the probes, or create an internal NCSI server. Both options are discussed below:
Disable the probes. This can be set by a group policy setting via this registry key:
Value: EnableActiveProbing (DWORD) defaults to 1
Setting this value to 0 will disable active probes. A potential side effect is that, the machines may determine that they don’t have internet connectivity and display a or exclamation “!” on the network icon and “limited” connectivity in the network UI.
To use a Group Policy setting to prevent NCSI from communicating across the Internet:
1.Click Start, type gpmc.msc, and then press ENTER. Select an appropriate Group Policy object (GPO).
2.Expand Computer Configuration, expand Administrative Templates, expand System, expand Internet Communication Management, and then click Internet Communication settings.
3.In the details pane, double-click Turn off Windows Network Connectivity Status Indicator active tests, and then click Enabled.
Note: gpmc.msc ONLY works if you have the GP Management Console installed from RSAT tools in Win7 or as an added feature on a W2k8 R2 server that is not the (PDC) emulator.
Create an internal NCSI server. Setup a HTTP server inside the network and reconfigure NCSI to use that server for its probes instead. The probe can be customized through the following registry key:
• Value: ActiveWebProbeHost (REG_SZ) defaults to “www.msftncsi.com”
• Value: ActiveWebProbePath (REG_SZ) defaults to “ncsi.txt”
• Value: ActiveWebProbeContent (REG_SZ) defaults to "Microsoft NCSI"
We can also configure these settings with a Group policy, but if we use Group Policy to prevent NCSI from connecting to http://www.msftncsi.com, applications that perform checks for the existence of Internet connectivity might experience performance delays until group policy is applied. Also, if a computer running Windows 7 or Windows Server 2008 R2 is brought into a hot spot that requires a sign-in, the computer might not detect the hot spot.
Hosting your own NCSI server
What if we have a requirement where we don’t want to send the request to http://www.msftncsi.com, but we don’t want to disable NCSI either, what should we do?
….Hmmm tricky question….
Answer – We can host our own NCSI server.
This is what I did to host my own NCSI server.
I created my own NCSI page called prachand.ncsi.com on my webserver and I configured it to send /ncsi.txt as a plain text file with the content “Prachand NCSI”. I then changed all of the registry values to point to the values for my server, and it worked!
In the capture that I took, I saw requests were being made to my local server instead of Microsoft’s server. The system was still determining the status of the internet connection correctly. The user agent on the requests was still Microsoft NCSI, indicating that it was indeed the same service making the requests.
There are 2 steps that we need to follow.
1. Host a website
a. Host Header of the site MUST be prachand.ncsi.com
b. In the Root Directory create a TEXT file called ncsi.txt
c. Ncsi.txt must contain ONLY “Prachand NCSI” [ Without the Quotes]
2. Host a DNS Zone
a. Create a DNS zone named: ncsi.com
b. In the zone create 2 records:
- prachand (resolves to the IP address of the server hosting prachand.ncsi.com)
- dns (resolves to 220.127.116.11)
In the background we would access http://prachand.ncsi.com/ncsi.txt which would in turn result as dns.msftnsci.com to 18.104.22.168
Blocking active probing should also be acceptable. Please have a look at the following Microsoft KB article, which explains the mechanism of active probing and passive probing: http://support.microsoft.com/kb/947041
What kind of issues with NCSI does Microsoft see?
With different Firewalls and Antivirus programs we come have across issues where NCIS probes have been blocked. Here are a few examples that we have come across:
• VPN miniport driver Network Connectivity Status Indicator (NCSI) may show a limited access status when connected through a 3rd Party VPN when no split tunneling is used. When the VPN client is loaded, the Windows capture shows that we aren’t receiving DNS replies for “dns.msftncsi.com”. Prior to the reboot, the Windows capture shows that we *do* receive DNS replies to identical DNS requests, but after the VPN miniport is loaded, the local interface never receives the DNS reply that has arrived back through the VPN interface. The easiest solution is to enable split tunneling but if that is not an option you should contact the vendor.
• Firewalls/Anti-Virus We have also seen an issue where 3rd party Firewalls/Anti-Virus blocked the URL http://www.msftncsi.com/ncsi.txt resulting in a limited access status in the taskbar, even though there is Internet Connectivity. Adding “*.msftncsi.com” to the list of trusted URLs should resolve the issue.
If you suspect a similar issue please contact your application vendor to assist with a workaround.
1) What information does NCSI forward to the Microsoft site?
There is no information gathered by Microsoft with NCSI. The NCSI client first makes a DNS query followed by an HTTP request. These requests are very common operations for accessing just about any network.
The privacy statement for Network Awareness (which includes NCSI) is on the Microsoft Web site at:
2) What is the impact if NCSI is disabled on the clients and servers?
If NCSI is prevented from connecting to http://www.msftncsi.com, applications that rely on NCSI to report the Internet connectivity status might be affected. Also, if a computer running Windows 7 or Windows Server 2008 R2 is brought into a hot spot that requires a sign-in, the computer might not detect the hot spot.
3) Is there a supported configuration for hosting the NCSI server internally and, if so, what is the impact?
Yes, it is possible but not recommended. Hosting it yourself could potentially lead to incorrect detection of Internet access which could affect applications that depend on this status. It is primarily intended for testing or lab use so that Internet access can be simulated.
Hopefully this blog has helped you understand the process involved with detecting Internet connectivity status and the ways you can configure it to prevent issues in your environment.
Appendix K: Network Connectivity Status Indicator and Resulting Internet Communication in Windows Vista http://technet.microsoft.com/en-us/library/cc766017(v=WS.10).aspx
Appendix H: Network Connectivity Status Indicator and Resulting Internet Communication in Windows 7 and Windows Server 2008 R2 http://technet.microsoft.com/en-us/library/ee126135(v=WS.10).aspx
The network connectivity status incorrectly appears as "Local only" on a Windows Server 2008-based or Windows Vista-based computer that has more than one network adapter http://support.microsoft.com/kb/947041
– Prachand Kumar with additional information from David Pracht