Troubleshooting Windows Server Network Connection Issues: An NCSI Guidance

Table of Contents

This guide provides comprehensive assistance for troubleshooting issues related to the Network Connection Status Indicator (NCSI) in Windows Server environments. NCSI plays a vital role in determining network connectivity and is utilized by various applications and services to ascertain internet access. Understanding its functionalities and common pitfalls is crucial for maintaining seamless network operations.

Basics of NCSI¶

The foundation of network awareness in Windows lies with the Network Location Awareness (NLA) service. This service is responsible for discerning the type of network connectivity available to the system. In operating systems up to Windows 10, the NLA service loads the ncsi.dll file, which is the core component for NCSI operations. It manages network operations, receives notifications, and gathers status information. The connectivity status determined by NCSI is pivotal for numerous applications, including Microsoft Outlook, Microsoft Teams, Skype, Windows Update, Microsoft DirectAccess, and a range of third-party software, as they rely on this status to function correctly.

From Windows 11 onwards, the responsibility for these tasks transitions to the Network List Service (netprofm). Despite this change in service, the underlying principles of NCSI and its operational mechanisms remain consistent.

NCSI primarily functions through network probes, which are essentially simple network requests sent to a designated endpoint, awaiting a response to validate connectivity. These probes can be categorized into two main types: active probes and passive probes.

Active Probes¶

Active probing involves initiating a network action to explicitly check network status. This typically takes the form of a Domain Name System (DNS) lookup for a specific NCSI address or a direct request to a web probe server. While Microsoft hosts the default web probe server on the internet, organizations have the option to configure a private probe server within their enterprise network. However, utilizing a private probe server is less common in practice.

The core logic of active probing is straightforward: NCSI sends out a probe, and if it receives a valid response, the system is deemed to have internet connectivity. This mechanism provides a direct and immediate assessment of network reachability.

Important Note: Disabling active probing is generally not recommended as a troubleshooting step. Active probing is a fundamental part of NCSI’s operation, and disabling it can mask underlying issues or disrupt network status detection.

Passive Probes¶

In contrast to active probes, passive probing determines network status by analyzing data already being received and transmitted by the system. Instead of initiating new network requests, it leverages existing network traffic and system information.

Passive probes rely on network statistics derived from recently sent and received packets. Key data points include the Time To Live (TTL) values of network frames and notifications from other system components. By analyzing these passive data streams, NCSI can infer network connectivity without generating explicit probe traffic. This method is particularly useful in scenarios where active probing might be restricted or unreliable.

Troubleshooting Checklist¶

When encountering NCSI related issues, a systematic troubleshooting approach is essential. The following checklist outlines key areas to investigate and steps to take to diagnose and resolve common problems.

1. The Network Status Taskbar Icon¶

The network status icon in the taskbar serves as the most immediate visual indicator of network connectivity. It provides users with a quick overview of the network’s availability and any potential issues.

• Full internet access over Wi-Fi:
• Full internet access over Ethernet: or
• Some degree of network outage:
  • Not connected - Connections are available:
  • Identifying… No Internet access: , , or

Important Note: While the taskbar icon is a helpful indicator, it should not be solely relied upon for definitive network status. NCSI’s inability to complete a probe does not automatically mean that the client machine lacks internet access. Network connectivity can still be functional even if NCSI probes fail.

To address NCSI issues, the primary goal is to ensure that NCSI can successfully send an active probe to the internet and receive a valid response.

2. NCSI Browser Test¶

A practical step in verifying NCSI functionality is to perform a manual browser test. Open a web browser and navigate to Microsoft Connect Test (or ipv6.msftconnecttext.com for IPv6). The expected outcome is to see the text “Microsoft Connect Test” displayed in the browser.

If you are unable to retrieve this text file, several potential issues need investigation:

• Proxy Settings: Verify that the proxy settings on the client machine are correctly configured. Incorrect proxy settings can prevent access to external websites.
• Proxy Server Restrictions: Ensure that the proxy server itself is not blocking access to the Microsoft Connect Test addresses. Proxy servers can have access control lists that might inadvertently block NCSI probe destinations.

For older systems running Windows versions prior to Windows 10 version 1607, use the legacy Microsoft NCSI test (or ipv6.msftncsi.com for IPv6). The expected content in this case is “Microsoft NCSI.”

It’s important to note that sometimes a manual browser test might succeed while NCSI probes fail. This discrepancy can occur because browser tests might bypass proxy settings that NCSI is configured to use. In such scenarios, capturing a network trace can be invaluable in identifying any unusual network behavior or traffic patterns that are hindering NCSI probes.

3. Check NCSI Event Logs¶

NCSI maintains detailed event logs that can provide valuable insights into its operation and any encountered errors. To access these logs, navigate to the following path in Event Viewer: Applications and Services Logs\Microsoft\Windows\NCSI\Operational.

Reviewing these event logs can reveal specific error messages, warnings, or informational events that pinpoint the cause of NCSI failures. Events might indicate issues with probe attempts, DNS resolution, or connectivity problems. Analyzing the timestamps and details of these events can guide further troubleshooting steps.

4. Check the Registry Location for Any Changes¶

Crucial Note: Active probing must be enabled for NCSI to function correctly. Ensure that active probing is not disabled through Group Policy or registry settings.

The configuration parameters for NCSI’s active probes, including the HTTP web probe server, path, expected probe content, and DNS probe host and content, are defined within the Windows Registry. The relevant registry path is:

HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet

It is essential to verify that the values under this registry key are set to their default, recommended settings, unless a deliberate customization is required. Incorrect or modified values can lead to probe failures.

Default Values in Windows 10, version 1607 and later versions:

Name	Type	Data
(Default)	REG_SZ	(value not set)
ActiveDnsProbeContent	REG_SZ	131.107.255.255
ActiveDnsProbeContentV6	REG_SZ	fd3e:4f5a:5b81::1
ActiveDnsProbeHost	REG_SZ	dns.msftncsi.com
ActiveDnsProbeHostV6	REG_SZ	dns.msftncsi.com
ActiveWebProbeContent	REG_SZ	Microsoft Connect Test
ActiveWebProbeContentV6	REG_SZ	Microsoft Connect Test
ActiveWebProbeHost	REG_SZ	www.msftconnecttest.com
ActiveWebProbeHostV6	REG_SZ	ipv6.msftconnecttest.com
ActiveWebProbePath	REG_SZ	connecttest.txt
ActiveWebProbePathV6	REG_SZ	connecttest.txt
CaptivePortalTimer	REG_DWORD	0x00000000 (0)
CaptivePortalTimerBackOffincrementsInSeconds	REG_DWORD	0x00000005 (5)
CaptivePortalTimerMaxInSeconds	REG_DWORD	0x0000001e (30)
EnableActiveProbing	REG_DWORD	0x00000001 (1)
PassivePollPeriod	REG_DWORD	0x0000000f (15)
StaleThreshold	REG_DWORD	0x0000001e (30)
WebTimeout	REG_DWORD	0x00000023 (35)

Default Values in Windows 10, version 1511, Windows 10, version 1507, Windows 8.1, and Windows 8:

Name	Type	Data
(Default)	REG_SZ	(value not set)
ActiveDnsProbeContent	REG_SZ	131.107.255.255
ActiveDnsProbeContentV6	REG_SZ	fd3e:4f5a:5b81::1
ActiveDnsProbeHost	REG_SZ	dns.msftncsi.com
ActiveDnsProbeHostV6	REG_SZ	dns.msftncsi.com
ActiveWebProbeContent	REG_SZ	Microsoft NCSI
ActiveWebProbeContentV6	REG_SZ	Microsoft NCSI
ActiveWebProbeHost	REG_SZ	www.msftncsi.com
ActiveWebProbeHostV6	REG_SZ	ipv6.msftncsi.com
ActiveWebProbePath	REG_SZ	ncsi.txt
ActiveWebProbePathV6	REG_SZ	ncsi.txt
EnableActiveProbing	REG_DWORD	0x00000001 (1)
PassivePollPeriod	REG_DWORD	0x0000000f (15)
StaleThreshold	REG_DWORD	0x0000001e (30)
WebTimeout	REG_DWORD	0x00000023 (35)

Note: Windows 7 and earlier operating systems do not incorporate this NCSI feature.

From Windows 10 version 1607 onwards, web probe (HTTP) requests are directed to Microsoft Connect Test. The expected server response is “HTTP 200 OK,” with the response body containing “Microsoft Connect Test.” This change reflects an evolution in the probe mechanism and target endpoint used by NCSI.

5. Simple Test for Connectivity¶

A quick and effective way to assess network connectivity is to utilize the PowerShell cmdlet Get-NetConnectionProfile. Executing this command provides detailed information about the network profile and connectivity status of each network interface.

Get-NetConnectionProfile

An example of output indicating good internet connectivity is shown below:

Name                     : XYZ
InterfaceAlias           : Ethernet
InterfaceIndex           : 5
NetworkCategory          : Private
DomainAuthenticationKind : None
IPv4Connectivity         : Internet
IPv6Connectivity         : Internet

If the IPv4Connectivity or IPv6Connectivity fields for any network interface display Internet, it signifies that the machine is recognized as having internet access. In such instances, if connectivity issues are being reported, the problem might be intermittent, transient, or unrelated to NCSI’s core functionality. It could point towards application-specific problems or network glitches outside of NCSI’s detection scope.

6. Check Which Probe Is Used to Detect the Internet on the Impacted Machine¶

The type of active probe employed by a machine to determine internet connectivity can vary based on several factors, including network configuration and proxy settings. Furthermore, given that both active and passive probes operate concurrently, a scenario can arise where active probes are failing, yet the network status is still being detected correctly through passive probing mechanisms.

Understanding which probe type is being used and whether both active and passive probes are functioning as expected is critical for accurate diagnosis. Investigating probe selection logic and probe results can reveal discrepancies and potential points of failure in NCSI’s detection process.

7. Check the “MaxActiveProbes” Value¶

The MaxActiveProbes registry value limits the number of active probes that NCSI will send. This value is located at:

HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\MaxActiveProbes

By default, this registry key does not exist or is set to 0. A value of 0 indicates that there is no limit on the number of probes, effectively making the number of probes unlimited. In most standard network environments, the default unlimited probe setting rarely causes issues. However, in highly constrained or unusual network setups, excessively frequent active probes might, in theory, contribute to network congestion or resource utilization. Checking this value can be relevant in very specific and rare troubleshooting scenarios.

8. Check DNS Resolution¶

For DNS probes to function correctly, DNS resolution for the probe endpoint must be successful. To verify DNS resolution, use the nslookup command or the Resolve-DnsName PowerShell cmdlet to query dns.msftncsi.com.

Resolve-DnsName dns.msftncsi.com

Successful resolution confirms that the machine can correctly translate the DNS hostname into an IP address, which is a prerequisite for DNS probes to proceed. If DNS resolution fails, it indicates a DNS infrastructure problem that needs to be addressed separately, such as incorrect DNS server settings on the client or issues with the DNS server itself.

9. Passive Probe Related Settings¶

Passive probe behavior is influenced by specific registry and Group Policy settings. Examine the registry value MinimumInternetHopCount located at:

HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\MinimumInternetHopCount

This value determines the minimum number of network hops required for passive probing to consider a network connection as internet-capable. A value of 3 is generally suitable for most enterprise network infrastructures. The default value is 8, which might be too restrictive in some scenarios. Adjusting this value might be necessary based on the specific network topology.

Additionally, review the Group Policy Object (GPO) configuration for passive polling:

Group Policy Path: Computer Configuration\Administrative Templates\Network\Network Connectivity Status Indicator\Specify passive polling

Important Note: If this Group Policy setting is not explicitly configured, passive polling is enabled by default. Explicitly disabling it via GPO can affect passive probe functionality and overall NCSI behavior.

Common Issues and Solutions¶

Several common issues can lead to NCSI probe failures. Understanding these issues and their corresponding solutions is essential for efficient troubleshooting.

DNS Probe Failed Due to an Incorrect Probe Server¶

If DNS probes are failing, one potential cause is an incorrect DNS fully qualified domain name (FQDN) configured for active probes in the registry. Verify that the FQDN specified in the registry settings for active DNS probes accurately matches the intended target probe server.

It is generally recommended to avoid modifying the default probe data configuration unless absolutely necessary. While organizations have the option to override these settings to point to privately hosted probe servers, this is an uncommon practice and should be implemented with caution. Incorrectly configured probe server addresses will directly lead to probe failures.

DNS Probe Failed Due to a Timeout¶

DNS probe failures due to timeouts indicate that the system is not receiving a DNS response within the expected timeframe. Investigate the reasons for the lack of DNS response. Possible causes include:

• Undetected Proxy: A proxy server might be in place but not correctly configured or detected by NCSI, leading to DNS resolution attempts failing.
• Incorrect DNS Server IP Address: The client machine might be configured with an incorrect or unreachable DNS server IP address, preventing successful DNS resolution.

Troubleshooting DNS timeouts involves verifying proxy settings, DNS server configurations, and network connectivity to the configured DNS servers.

HTTP Probe Failed Due to an “HTTP 403 Forbidden” Error¶

An “HTTP 403 Forbidden” error during HTTP probes indicates that the probe request is reaching the web server, but the server is denying access. This error typically points to access restrictions imposed by firewalls or gateway devices within the network environment.

Check for any firewall rules or gateway policies that might be blocking HTTP probe requests to the Microsoft Connect Test or Microsoft NCSI servers. Ensure that network security devices are configured to allow traffic to these probe destinations.

DNS Resolution Failed to Send HTTP Probes¶

For HTTP probes to be initiated, DNS resolution for the HTTP probe server hostname (e.g., msftconnecttest.com) must succeed. The configured DNS server must be capable of resolving this query, either directly or by forwarding it to an authoritative DNS server that can provide the resolution.

If DNS resolution for the HTTP probe server fails, HTTP probes cannot be sent. Troubleshooting this issue involves ensuring proper DNS server configuration and network connectivity to DNS servers capable of resolving internet hostnames.

HTTP Direct Probe Fails But Proxy Exists¶

In scenarios where HTTP direct probes are failing despite the presence of a proxy server, it is crucial to verify Web Proxy Auto-Discovery (WPAD) functionality. Ensure that the client machine is successfully receiving a valid DNS response to a WPAD query.

If the configured DNS server cannot resolve WPAD queries, it should be configured to forward these queries to a DNS server that is capable of resolving WPAD. Alternatively, consider these options:

• Manually Configure Proxy Data (via GPO): Instead of relying on WPAD, manually configure proxy settings for clients through Group Policy. This ensures consistent proxy configuration.
• Allow Active Probes Through Upstream Firewall: If proxy auto-discovery is problematic, configure the upstream firewall to explicitly allow active probe traffic to bypass the proxy and reach the internet probe servers directly. This approach might simplify routing for probe traffic.

Data Collection¶

Before reaching out to Microsoft support for assistance with NCSI issues, gathering relevant diagnostic data can significantly expedite the troubleshooting process. Utilize the TroubleShootingScript (TSS) tool to collect necessary logs and system information.

Prerequisites¶

1. Administrator Privileges: TSS must be executed by accounts with administrator privileges on the local system.
2. EULA Acceptance: The End-User License Agreement (EULA) must be accepted upon first execution. Once accepted, TSS will not prompt for EULA acceptance again.
3. PowerShell Execution Policy: It is recommended to set the local machine’s PowerShell execution policy to RemoteSigned to allow TSS scripts to run.

Steps for Data Collection¶

1. Download TSS: Download the TroubleShootingScript tool from https://aka.ms/getTSS and extract the downloaded archive to the C:\tss folder.
2. Open Elevated PowerShell: Open an elevated PowerShell command prompt (Run as administrator) and navigate to the C:\tss folder using the cd C:\tss command.

3. Start Traces: Initiate the data collection process by running the following PowerShell cmdlet:

   .\TSS.ps1 -Start -Scenario NET_NCSI
   

   
   4. Accept Prompts: Accept the EULA and Problem Steps Recorder (PSR) confirmation prompts that appear during TSS startup.
   5. Reproduce Issue: Reproduce the NCSI issue you are experiencing before proceeding to the next step. This ensures that the logs capture the relevant events during the problem occurrence.
   6. Finish Log Collection: After reproducing the issue, enter Y in the PowerShell prompt to finalize the log collection process.

Once completed, the collected traces and diagnostic data will be stored in a zip file located in the C:\MS_DATA folder. This zip file can then be provided to Microsoft support for further analysis.

Frequently Asked Questions¶

Q1. When are active probes sent?¶

Active probes are triggered by specific events that indicate a potential change in network state. NCSI actively monitors and registers to receive notifications for events that suggest the network status might need to be refreshed. These events can include network adapter state changes, IP address changes, or changes in network connectivity status reported by other system components. When such an event occurs, NCSI initiates active probes to re-evaluate the network connection status.

Q2. How does NCSI know whether to use an HTTP or DNS probe?¶

NCSI’s probe selection logic depends on several factors, primarily the presence of a proxy server and the type of network interface in use.

• No Proxy: When no proxy server is detected in the network configuration, NCSI defaults to using DNS probes for connectivity checks.
• Proxy Detected: If a proxy server is detected, NCSI switches to using HTTP probes. HTTP probes are better suited for proxy environments as they can traverse proxy servers to reach internet endpoints.
• Forced Web Probe: In situations where NCSI suspects a proxy might be present but lacks definitive confirmation, it might initiate a “forced” web probe. This can occur when DNS probes fail, potentially indicating a proxy interception, but proxy auto-discovery has not yet confirmed proxy existence. In these ambiguous cases, NCSI might attempt HTTP probes to further investigate.
• Wi-Fi and IPv6: For Wi-Fi network interfaces and IPv6 connections, NCSI preferentially uses HTTP probes. This is often due to the complexities of proxy configurations and IPv6 network behaviors, where HTTP probes offer more reliable connectivity assessment.

Q3. When and how often does the passive probe run?¶

Passive probes operate under specific conditions and are not continuously active. The passive probe will only run when all of the following conditions are met:

1. Passive Polling Allowed by Group Policy: The Group Policy setting “Specify passive polling” located at Computer Configuration\Administrative Templates\Network\Network Connectivity Status Indicator\Specify passive polling must be enabled or not configured (default is allowed). If explicitly disabled via GPO, passive probes will not run.

   Note: When this Group Policy setting is not configured, passive polling is enabled by default.

2. NCSI Notification Registration: At least one client application or service must be registered to receive NCSI notifications. This indicates that there are applications actively interested in network connectivity status, justifying passive probe activity.

3. User Logged In: A user must be currently logged into the system or have logged in within the past 30 seconds. Passive probing is generally user-contextual and might be less relevant when no user is actively interacting with the system.

4. System Not in Network Quiet Mode: The system must not be operating in network quiet mode. Network quiet mode is a state where network activity is intentionally reduced, and passive probing might be suppressed to minimize network overhead.

5. Network Activity: An IPv4 or IPv6 unicast address must be configured on a network interface, and/or network packets must have been processed on an interface within the past 30 seconds. This condition ensures that there is ongoing network activity to observe and analyze for passive probing. If there is no network traffic, passive probing would have no data to work with.

The frequency of passive probe runs is determined by the PassivePollPeriod registry value (default 15 seconds), which specifies how often passive probes are triggered when all the conditions above are met.

Q4. Why are both active and passive probes needed simultaneously?¶

Active and passive probes serve complementary roles in determining network connectivity, and their simultaneous operation enhances the robustness and accuracy of NCSI’s network status assessment. They both aim to achieve the same ultimate goal—identifying the type of network connectivity—but they employ fundamentally different methods.

• Complementary Methods: Active probes provide explicit, on-demand verification of connectivity by initiating network requests. Passive probes, on the other hand, offer a more continuous, background monitoring of network status by analyzing existing traffic. These two approaches provide different perspectives on network connectivity.
• Handling Intermittent Conditions: Network conditions can be intermittent and fluctuating. Sometimes, transient network issues might temporarily prevent active probes from functioning correctly, leading to false negatives in connectivity detection. Passive probes, by continuously monitoring network traffic, can often maintain accurate network status awareness even during brief periods of active probe disruption.
• Redundancy and Reliability: The combination of active and passive probes introduces redundancy into the network status detection process. If one probe type encounters issues or limitations due to specific network conditions, the other type might still be able to provide accurate information. This redundancy improves the overall reliability of NCSI’s network status determination.

In essence, active and passive probes work in tandem to provide a more comprehensive, resilient, and accurate assessment of network connectivity, catering to a wider range of network scenarios and conditions.

If you have further questions or require additional clarification, please feel free to leave a comment below. Your feedback is valuable in improving this guide.