Microsoft Connection Test (NCSI) and office 365

We’ve probably all seen the “Connected: No Internet” message on Windows systems before now and been happy to ignore it knowing full well that the internet is in fact connected and does in fact work, so why is that message appearing? how do we fix it and stop it interfering with other programs?

First off, Microsoft Windows does an internet connection test (Also referred to as NCSI and Microsoft Connect Test) which reaches out to a microsoft domain and verify’s it is able to connect, if the operating system isn’t able to connect to the site at that time it generates a flag which shows the message stating you have No Internet.

We have seen this issue for a good many years with minimal issues, until we switched our users to Office 365, initially everything was working as expected until we started to get users who simply could not connect to their mailbox using Outlook and installed copies of outlook unable to connect to the licensing server to check their validity. We noted instantly that when switching to a network that shows as Connected the issues went away but would resurface. The issue was mainly present on the LAN and was mitigated if users were on the guest or work wireless networks.

As we are aware Outlook and the rest of the office suite do not perform their own check for connectivity but rather follow the operating systems lead so the root cause of the problem lies with the Microsoft Connect Test process, or so it would seem.

Multiple tests were conducted that showed while the status showed No Internet we could actually connect to and query the DNS for the ncsi websites, so it wasn’t a connection, firewall or proxy issue causing the problems. Remember above however, Wireless was seemingly OK so perhaps it was a NIC issue after all.

Changing certain aspects of the NIC’s and settings would temporarily resolve the issues – changing metrics, modifying the registry for multihomed DNS queres, changing advanced adapter settings, setting Global DNS etc. all had short term effects but as soon as another change was detected the problems would recur and reverting the changes had no effect, it would seem restoring the Connected status by anything we were doing was a complete fluke.

It would seem the fix was overlooked slightly while we were looking into the advanced settings of the NIC itself one option was “ipv4 checksum offload” we had tried this set this as “Tx and Rx Enabled”, “Rx Enabled” and “Tx Enabled” – each time as reported above we had short term success. However, there was a further option we had not tried of “Disabled”, instantly on setting this the connection status was Connected, reverting the setting showed us the old Not Connected status and setting it to Disabled again would once again fix the issue. We have been running this option for 2 weeks now with no further issues seen.

The majority of our systems did require a driver update to enable the option in the GUI and also required the driver update for the Powershell command below to become effective.

Changing the setting from Device Manager

  • Install the newest LAN driver available for your system
  • Open device manager select the LAN connection you have just updated the drivers for
  • Select the Advanced tab
  • Locate and select IPv4 Checksum Offload in the Properties list
  • Set the value to Disabled
  • Select OK
  • The change should happen immediately.

Changing the setting with Powershell

If you have multiple machines to resolve this issue on it may be prudent to employ a Powershell script at logon to set this for you:

  • Install the newest LAN driver available for the systems
  • run the following on each machine either via remote powershell or a script:
  • Disable-NetAdapterChecksumOffload -Name "*" -TcpIPv4
  • The change should happen immediately


  1. If this works, you have just solved a problem that’s been bugging me for years, in the most recent issue, Zoom detects that the NCSI has failed and will not connect, even though the internet connection is fine.

  2. This is really interesting and I plant to try it in our environment. I am curious what hardware you are running and which Win OS version? We are having an issue with O365 over VPN on laptops and mainly use the Wireless NIC, which does not seem to have the the checksumoffload.

    1. Hi. Have you checked the value of your winhttp proxy in command prompt? you can try
      netsh winhttp show proxy
      which will show the current value of the proxy setting, my suggestion is to bypass authentication to the connection test URL’s and set the value to be your unauthenticated gateway:
      netsh winhttp set proxy PROXY

    2. Hello, Did you ever find a solution to this issue? I am having exactly the same issue when connected to VPN on laptops/ Wireless. I am unable to use the ‘checksumoffload’ as the wireless NICs do not have this.


  3. Argh.
    Notebook with this problem but on this wlan adapter there is no “ipv4 checksum offload” property 🙁

  4. Unfortunately I have this on a notebook with a WLAN adapter where it did not have the “ipv4 checksum offload” property.
    I could execute the Powershell command Disable-NetAdapterChecksumOffload -Name “*” -TcpIPv4 though and the first two times this worked perfect, but after a reboot still “no internet access”….

  5. Fixed the error on all 7 Clients that got MS365 last week.
    I had been searching and trying many different approaches and nothing really worked longer than 10 minutes but THIS fixed it.

    You do know that MS365 Support fixed our issue with THIS info here. The Support guy gave that link to me.

    Microsoft themselves seem to be happy that you have found a cure for many who suffer this NCSI failure !

Leave a Reply

Your email address will not be published. Required fields are marked *