Events
Apr 29, 2 PM - Apr 30, 7 PM
Join the ultimate Windows Server virtual event April 29-30 for deep-dive technical sessions and live Q&A with Microsoft engineers.
Sign up nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
The following section is to provide a quick FAQ surrounding the Network Connectivity Status Indicator (NCSI) in Windows.
Important
The public NCSI probe servers, previously hosted by Azure Front Door, have been hosted by Akamai since June 20, 2023.
Microsoft recommends as best practices that firewall rules be used to allow NCSI traffic and shouldn't be based on IP addresses. If you observe any failed NCSI probes, first check that enterprise firewalls or proxies for client probes aren't blocked. If the probes used to work before the mentioned date, rules added to allow outbound HTTP requests to 13.107.4.52 is the issue.
You can modify your outbound rules in the Windows Defender Firewall with Advanced Security by clicking Start > type wf.msc > and select Enter. An outbound rule should be created based on originating service.
NLS (Network List Service) applies to:
NLA (Network Location Awareness) service applies to:
For users behind an external hardware-based firewall, we recommend that customers work with their hardware vendors to build the appropriate rules for their environment as each have different controls and configurations in implementation. NCSI probes follow the same requirement as Windows Updates regarding allowing the hostnames through and not mapping to specific IP addresses.
Active probes are triggered by the following events that the NCSI monitors indicating that the network state might need to be refreshed:
When new network conditions are met, either wired, wireless, or behind a VPN, the network interface becomes ready for use and the active probe tests for network connectivity. An example is when a wireless connection is established:
[Microsoft-Windows-NCSI/Analytic ] Transitioning to State: Interface NetReady
Interface Luid: 0x47008000000000
A successful probe provides the following output:
[Microsoft-Windows-NCSI/Analytic ] Active Internet Probe finished on interface {426b6867-b0e4-4ff9-a14b-dd6a4345c24e} (true) {426b6867-b0e4-4ff9-a14b-dd6a4345c24e}, true, true, false, true, false
Many things can prevent an active probe from reaching the internet probe server or receiving a response from a server reaching the client successfully. They are as follows:
If the hop count recorded for the interface is at least the system minimum, it updates the interface capability to internet. No more active probes are done for this interface unless one of the events described in “When are active probes sent?” occurs.
If NCSI sees that the connectivity is local-only, the following conditions are true:
The default hop count is 8 but this isn't always optimal for enterprises. A value of 3 is suitable for most enterprise infrastructures.
Note
Microsoft doesn't recommend non-enterprise users changing this hop count value as they're subject to change.
Several factors influence whether a passive probe should execute based on passive polling data. The following conditions must be met:
If the passive probe is allowed to run, it does so every 15 seconds. This can be overridden by editing the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\PassivePollPeriod
Probe content along with the predefined DNS probe host is found in the following path:
HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet
Note
Starting with Windows 10 build 14393 (1607), web probe (HTTP) requests are sent to www.msftconnecttest.com/connecttest.txt
.
The expected response for HTTP 200 OK should contain the payload "Microsoft Connect Test", for example:
HTTP:Request, GET /connecttest.txt
HTTP:Response, Status: Ok, URL: /connecttest.txt
Before, www.msftncsi.com/ncsi.txt
was used, and the expected response is HTTP 200 OK with payload containing "Microsoft NCSI". For a DNS probe, the query is sent to dns.msftncsi.com
. For example:
Query for dns.msftncsi.com of type A on class Internet
Response - Success, 131.107.255.255
Note
4-c-0003.c-msedge.net is typically recognizable as the entry point to MSFT services network which includes Microsoft’s hosted internet probe servers. The "4" is for IPv4. 6-c-0003.c-msedge.net is for IPv6.
Starting in Windows 11, HTTP is always used. You might see DNS activity but its purpose is to identify where to send the HTTP probe. Before this, if no proxy exists, NCSI probes using DNS. Example:
[Microsoft-Windows-NCSI/Analytic ] Active Internet Probe (DNS) started on interface {426b6867-b0e4-4ff9-a14b-dd6a4345c24e}
There are several reasons as to why a network probe might fail. For any failures encountered, it's logged in the Event Viewer for investigation.
Output | Description |
---|---|
ActiveDnsProbeFailed | The DNS probe failed. Verify via a packet capture. |
ActiveHttpProbeFailed | The DNS name for the probe server wasn’t resolved. NSCI failed before attempting to send the web probe request. This could be due to DNS failure, failure to connect to the proxy server, etc. Verify via a packet capture. |
ActiveHttpProbeFailedButDnsSucceeded | The probe server DNS name was resolved but the HTTP probe to that resolved IP address failed. Use a packet capture application and verify the data capture. |
ActiveHttpProbeFailedHotspotDetected | The HTTP probe didn’t get past a hotspot or captive portal. This is typically determined when an HTTP response 200 is received, but the response payload doesn’t contain the text file connecttest.txt. Alternatively, a non-200 HTTP status code, such as 302 or 304, might be received. This status code will normally be observed when handling issues where the wireless connection cannot be established. Verify via a packet capture. The user may need to authenticate the hotspot or the hotspot configuration may need to be modified. |
NoAddress | The target adapter has no preferred IP address assigned. There is a bigger issue involved that can't be resolved through NSCI. |
NoGlobalAddress | Same as NoAddress but specific to IPV6 interfaces. |
NoRoute | The interface that the probe is being sent on has no route to the internet in the routing table. Some scenarios where this can happen is when a newly connected VPN hasn’t yet changed the routing table with new routes, or in forced tunnel VPN scenarios in which after the VPN interface is connected, the physical interface drops to local connectivity as the route table was modified. |
PassivePacketHops | Not a failure. Received packets indicate some level of connectivity. This change reason is used when capability is being raised, not lowered. |
Here's an output of a probe failure:
[Microsoft-Windows-NCSI/Analytic ] Active Internet Probe finished on interface {426b6867-b0e4-4ff9-a14b-dd6a4345c24e} (false) {426b6867-b0e4-4ff9-a14b-dd6a4345c24e}, false, true, false, false, false
[Microsoft-Windows-NCSI/Operational ] Capability change on {426b6867-b0e4-4ff9-a14b-dd6a4345c24e} (0x6008001000000 Family: V4 Capability: Local ChangeReason: SuspectDnsProbeFailed) {426b6867-b0e4-4ff9-a14b-dd6a4345c24e}
Note
If the probe failure was due to traversing a proxy NCSI sets the connectivity state to None. If the failed probe didn't traverse (went direct), NCSI sets the connectivity state to Local.
When NCSI is able to get an active probe with matching expected content "Microsoft Connect Test". There’s nothing NCSI can do about being behind a hotspot other than detecting and reporting it. It's up to the user to authenticate with the hotspot so traffic is allowed out to the internet.
NCSI’s responsibility to the system to accurately report connectivity as local when its' probes are being redirected. Only the internet hosted probe server should return the expected content proving internet connectivity.
Here's an example of what a probe failure might relay:
[Microsoft-Windows-NCSI/Analytic ] Active Internet Probe finished on interface {426b6867-b0e4-4ff9-a14b-dd6a4345c24e} (false)
{426b6867-b0e4-4ff9-a14b-dd6a4345c24e}, false, true, false, false, false
[Microsoft-Windows-NCSI/Operational ] Capability change on {426b6867-b0e4-4ff9-a14b-dd6a4345c24e}
(0x6008001000000 Family: V4 Capability: Local ChangeReason: SuspectDnsProbeFailed){426b6867-b0e4-4ff9-a14b-dd6a4345c24e}
This behavior is by design. Windows wants users to know when they connect to a network that requires captive portal authentication. Windows used to display a small popup for a short duration encouraging users to select it to open a browser. Users would often miss this not knowing it would open a browser for authentication. For more, see a browser opens when connecting to a corporate or public network.
The following list of URLs mentions or implies msftconnecttext.com
:
This is done by Microsoft Office making an API call to get_IsConnectedToInternet. If applications such as Microsoft Office is able to indicate no internet connectivity, but you're able to browse websites, this indicates an NCSI problem. If you can't browse or perform other basic network operations, this might be a general network issue, and NCSI troubleshooting wouldn't apply.
The taskbar network icon relies on NCSI and the same rule applies even if it indicates no network activity. This could be due to a more generic network issue other than NCSI.
Linux doesn't have built-in APIs (Application Programming Interface) for applications to check for continuous internet connectivity changes. They must implement their own network checks from the ground up, or use various Linux utilities to continuously check over time for changing network conditions.
Additionally, some Linux applications don't perform connectivity checks. They send the packets and handle errors after the fact whereas NCSI allows applications to alert the user of immediate connectivity problems.
Note
The enterprise must ensure their infrastructure doesn't block an HTTP or DNS active probe. This can happen if any of the following are misconfigured:
For general consumers, there are less potential hindrances that don't require user configuration out of the box. Issues occur when VPNs or third-party software are introduced which can intercept, misroute, or delay NCSI active probes.
Events
Apr 29, 2 PM - Apr 30, 7 PM
Join the ultimate Windows Server virtual event April 29-30 for deep-dive technical sessions and live Q&A with Microsoft engineers.
Sign up nowTraining
Learning path
Configure networking on Windows clients - Training
MD-100 Configure networking on Windows clients
Certification
Microsoft Certified: Azure Network Engineer Associate - Certifications
Demonstrate the design, implementation, and maintenance of Azure networking infrastructure, load balancing traffic, network routing, and more.