NCSI Change Notification

greyhodge Unlikely. There is too much reliance on Internet detection for it to be disabled. Adding the option to make it always connected would likely cause more issues than it would fix.

The last two articles in the post are good guides for netadmins to configure their environment for the NCSI active probe. We have also made significant improvements, especially in Windows 11, to make the NCSI active probe far more robust. Especially in environments with Internet proxies, the most common cause of active probe failures.

It would be nice if you actually published a full document on how to fix it when it breaks. In my experience the NCSI is a bane on my existence - non-Microsoft apps are happily using the internet and nearly all Microsoft apps and third party apps that rely on it are all saying "Sorry you have no internet" as far as I am concerned NCSI = Internet Roadblock. I fell requiring a reboot when adjusting settings for it is just plain crazy. 

> It would be nice if you actually published a full document on how to fix it when it breaks

Start with these articles
https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview

https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-troubleshooting-guide

"Faking" NCSI causes more problems than it solves.  When applications like Outlook and Teams, and numerous third parties believe there is internet connectivity when there really isn't, they will try their network operations and make the user wait for timeout.  This is not a good user experience.  

Of course not having internet isn't a good user experience either, but NCSI can't do anything about blocked firewall ports, proxies that don't properly whitelist the well-known msftconnecttest URI, captive portals that don't properly redirect or allow through NCSI probes after authentication.

I can add a rule to our firewall to allow access to www.msftconnecttest.com, it will look up that hostname and use the resulting IP addresses for the security policy, it repeats this process every 20 minutes unless the TTL is shorter in which case it will re-look up the DNS entry when the TTL expires. 

If I look up the DNS entry manually for www.msftconnecttest.com I get this:

www.msftconnecttest.com is an alias for ncsi-geo.trafficmanager.net.
ncsi-geo.trafficmanager.net is an alias for www.msftncsi.com.edgesuite.net.
www.msftncsi.com.edgesuite.net is an alias for a1961.g2.akamai.net.
a1961.g2.akamai.net has address 104.86.182.51
a1961.g2.akamai.net has address 104.86.182.58

If I immediately look that up again I get this:

www.msftconnecttest.com is an alias for ncsi-geo.trafficmanager.net.
ncsi-geo.trafficmanager.net is an alias for www.msftncsi.com.edgesuite.net.
www.msftncsi.com.edgesuite.net is an alias for a1961.g2.akamai.net.
a1961.g2.akamai.net has address 104.86.182.43
a1961.g2.akamai.net has address 104.86.182.82

If my firewall gets the the results from the first set and my clients get the result from the second set they will be blocked from reaching the msftconnect.com page.  If I were running some esoteric firewall I could imagine you wouldn't care, but I don't think I'm the only one running a Juniper firewall.

Will there ever be a way to either disable this or force it to always report that internet is detected? Office apps won't try to talk to the net if this service has incorrectly detected no internet, and frankly it serves no beneficial purpose. All netadmins do is try to figure out how to keep this service from causing problems.

> Adding the option to make it always connected would likely cause more issues than it would fix.

Unlikely.

> The last two articles in the post are good guides for netadmins to configure their environment for the NCSI active probe.

Yes, with large sections on the many ways it can fail and how to try to work around it. MS is well aware that netadmins frequently just crate DNS entries and shove a copy of the text file on a webserver simply so that NCSI won't have false reports of no internet.

I didn't expect any change, but maybe eventually MS will listen to the people who have to work with these things.

NCSI fails when nothing is wrong frequently, that's why real-world netadmins hate it. It does NOT serve any useful purpose. I've never once discovered a problem thanks to NCSI, only false failure modes.

netnerd98053, great question!

This is a secondary reason why we use HTTP, and not HTTPS, for the NCSI active probe. This allows URL filtering devices to see and parse the plain text HTTP header, and that removes reliance on DNS/IP address matching. 

From Junos OS support:

https://www.juniper.net/documentation/us/en/software/junos/interfaces-adaptive-services/topics/topic-map/url-filtering.html#id-url-filtering-overview__d203e165

HTTPS makes things trickier, but URL filtering with CDN services is nothing new. Major vendors typically have excellent accuracy with this scenario, too. But that topic is outside the scope of this discussion, and outside my area of expertise.

One of my clients has an airgapped network. One of the newer PCs on this network has started falsely claiming there's an internet connection. This has coincided with unexpected delays in certain programs. These two facts seem connected.

I know this is an edge case. Presumably we have a passive probe here seeing a network packet with a > 8 hop count. The planned "fix" will be add the DWORD value, MinimumInternetHopCount under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet registry key and set it to 20 (or more).