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