none
"No Internet Access" indicator, but internet access works RRS feed

  • Pertanyaan

  • We've got a few machines at a couple different clients that have the windows networking systray exclamation mark indicating limited network connectivity.  The supposed error is "no internet access", though the internet works fine in every case.  It is a very visible issue generating a lot of complaints, and the clients have a tendency to associate it with all kinds of other unrelated problems.

    To clarify:

    • Not all machines have the icon
    • Problem machines all have the same basic setup as non-problem machines
    • Some problem machines are win8, some win7
    • They don't share common hardware specs

    I have tried several things, including:  reset ip stack, give manual ip settings to network adapter, disable ipv6, disable/re-enable adapter, all without success.

    I don't know where to go to troubleshoot this.  Is there a log with this info?  Is the network connectivity check process well documented somewhere?

    Selasa, 23 September 2014 16.33

Semua Balasan

  • You may refer to event viewer and look for events related to network , DNS or DHCP and you may right click on the icon and run Network Troubleshooter.
    Selasa, 23 September 2014 17.11
  • Check Your DNS settings on the Clients make sure they can ping all your servers, if they are domain computers there should be no WAN Dns servers, also try to ping www.microsoft.com.
    Selasa, 23 September 2014 17.12
  • Hi hra_acbc,

    What is your current situation?

    Have you tried the solution as Cyber_Defend_Team and Darren Blanchard mentioned?

    Best regards,

    Fangzhou CHEN


    Fangzhou CHEN
    TechNet Community Support

    Kamis, 25 September 2014 12.08
    Moderator
  • Previously, I had tried setting manual DNS settings on the clients, and checking ping.  I haven't been able to find any lack of connectivity on the trouble machines.

    I'm on-site today, and just scanned through the system logs on one trouble machine.  Lots of "DNS Client Events" warnings with Event ID 8016 "The system failed to register host (A or AAAA) resource records (RRs) for network adapter with settings: ......"

    I have to admit I don't immediately understand this error.

    EDIT:  Forgot to mention, Network Troubleshooter doesn't see anything wrong.

    • Diedit oleh hra_acbc Kamis, 25 September 2014 14.27
    Kamis, 25 September 2014 13.56
  • Hi hra_acbc,

    Do you have a domain environment? Are there any DNS servers in the domain?

    If yes, please check the DNS server and see if there are event ID 11163 logged.
    For more information, please refer to the following links.
    http://technet.microsoft.com/en-us/library/cc735771(WS.10).aspx
    http://technet.microsoft.com/en-us/library/1583e419-88a6-4062-8807-d9eea99e3b42


    Best regards,
    Fangzhou CHEN


    Fangzhou CHEN
    TechNet Community Support


    Selasa, 30 September 2014 10.40
    Moderator
  • None of these events in DNS-Server-Service on the server.  No events logged for the last week or so.  The original issue is constant - I feel pretty sure it would have triggered an event within the last week.
    Selasa, 07 Oktober 2014 19.21
  • It is a domain environment with a DNS server running on Server 2012 Standard.  Also a hardware firewall filtering internet traffic.  *.msftncsi.com is added as a firewall exception.
    Selasa, 07 Oktober 2014 20.35
  • What type of firewall do you use? Does this need some form of authentication?

    Is this issue permanent for the affected machines or intermittent? Do the affected machines have something common in their ip-adress, which discerns them from the other machines and are they on LAN or WLAN?

    Also an output of ipconfig -all of the affected machines could help.


    Wolfgang

    Selasa, 07 Oktober 2014 20.53
  • The issue occurs on ethernet and wireless.  I haven't been able to tell what the problem machines have in common.  The issue is basically permanent.  Sometimes an IP stack reset will "cure" the problem temporarily, but it returns.

    Here's an ipconfig /all from one of the trouble machines:

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : XXXXXXX
       Primary Dns Suffix  . . . . . . . : klc.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : klc.local

    Wireless LAN adapter Wireless Network Connection 2:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter
       Physical Address. . . . . . . . . : 24-77-03-9E-xx-x1
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Wireless LAN adapter Wireless Network Connection:

       Connection-specific DNS Suffix  . : klc.local
       Description . . . . . . . . . . . : Intel(R) Centrino(R) Ultimate-N 6300 AGN
       Physical Address. . . . . . . . . : 24-77-03-9E-xx-x2
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::edb8:5d03:14cc:3f8d%13(Preferred) 
       IPv4 Address. . . . . . . . . . . : 10.100.30.105(Preferred) 
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Tuesday, October 07, 2014 10:35:54 AM
       Lease Expires . . . . . . . . . . : Wednesday, October 08, 2014 12:08:32 AM
       Default Gateway . . . . . . . . . : 10.100.30.1
       DHCP Server . . . . . . . . . . . : 10.100.20.100
       DHCPv6 IAID . . . . . . . . . . . : 237270787
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-CA-29-8A-D0-67-E5-54-28-5C
       DNS Servers . . . . . . . . . . . : 10.100.20.100
       Primary WINS Server . . . . . . . : 10.100.20.100
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter Local Area Connection:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : klc.local
       Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
       Physical Address. . . . . . . . . : D0-67-E5-54-xx-xx
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Rabu, 08 Oktober 2014 00.35
  • You have a quite complex network setup. Can you also post the output of route print on the problematic machine.

    For real troubleshooting you need a graphical map of your logical network and the configuration of all routers on this network. As a first start I would do a traceroute from a problematic machine to an internet host and the same from a working machine in the same subnet to the same internet host and compare the output. Then I'd check all internal routers shown on the traceroute for their configuration.

    This task can be quite time consuming depending on the structure of your network.


    Wolfgang

    Rabu, 08 Oktober 2014 13.46
  • Here's an ipconfig /all from one of the trouble machines:



    Ethernet adapter Local Area Connection:

       Media State . . . . . . . . . . . : Media disconnected

    Instead of an  ipconfig /all  see if just  ipconfig  clarifies what is being sensed.

    Also, I would try to use the appropriate netsh commands to clarify what is being sensed.  For example, with this case do some digging under  netsh  wlan

    However, I think the Networking troubleshooters are generally deficient. E.g. one time I accidentally found a fix that is probably related to what you need by using the troubleshooter associated with IE's Cannot connect page.  So my suggestion would be don't rely on just the obvious troubleshooter to try to find your fix. In my case I saw several unexpected errors related to Wi-Fi connections (the only ones I have) after a major update and had to go through several iterations of these haphazard "repair" procedures to finally get things working normally again.

    Good luck



    Robert Aldwinckle
    ---

    Rabu, 08 Oktober 2014 22.35
  • In the end, we simply had to make this problem go away.  It was affecting Office 365 in unacceptable ways.  The solution for the time being was to completely remove the proxy service from the organization's hardware firewall.  It did the trick, but is unacceptable as a long term solution.  Considering the proxy didn't have a detrimental effect on any of the individual NCSI functions when tested manually, it doesn't make sense. 

    It's my opinion that the NCSI functionality is not optimized to work with the range of network setups in use today.  Perhaps there is a good reason for the non-connectivity reporting on this network, but it seems to me that if there's no measurable lack of functionality, it shouldn't be reported as such.

    Selasa, 14 Oktober 2014 16.13
  • If you have a proxy, which probably requires authentication, it is pretty understandable, that the correct network state  cannot be detected by the standard procedures.

    There are so many different proxy servers with a multitude of configurable options, that MS cannot foresee all possible working solutions in its simple network test. If all things work as desired and you are annoyed by the false values on the icon, just turn off the icon.

    And I do not understand how that does affect Office 365.


    Wolfgang

    Kamis, 16 Oktober 2014 12.08
  • The most major problem is that Office 365 assumes no internet connectivity on the basis of NCSI and refuses to do things like authenticate licensing when it's time to do so.  It is a real problem reported by others, not just me.

    If a browser (even Microsoft's own IE) accesses the internet without any issues whatsoever, but NCSI reports "no internet access," then NCSI is clearly not an accurate measure of connectivity.

    If Microsoft is going to hang the functionality of their software upon the report given by NCSI, the documentation of this "feature" needs to be exhaustive.  Network admins need to clearly understand its requirements.  As it is, the documentation is limited to, essentially: 1) Perform DNS query.  2) Download msftncsi text file.

    Both of these functions can be performed manually with no errors.  I spent well over an hour on the phone with 4 different MS techs and nobody had answers about the NCSI service.

    There are accounts across the internet - quite a few otherwise intelligent people have, like myself, have found that NCSI is broken on their network, and with no solid information to go off of, the solution they have to turn to is to disable proxy on their firewall.  It's a shame, and it results in reduced security on the network, and contributes to the perceived security problems of Windows in general.

    I have no doubt that there is a way to properly configure this network, but MS has provided no clear requirements.  I have poured many hours into troubleshooting and trying to placate an overly sensitive OS feature.  We use simple switch/router setups and major brand firewalls with mostly out-of-box configurations.

    Kamis, 16 Oktober 2014 14.16
  • I had the same problem and found a solution by accident.  The link

    https://technet.microsoft.com/en-us/library/cc766017.aspx

    takes you to a discussion of how the NCSI indicator works.  It suggests you can turn off active probing by setting a registry parameter that is normally on (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\EnableActiveProbing)

    I checked that parameter and found that it was actually already off.  So I turned it on and rebooted.  The problem went away.

    • Disarankan sebagai Jawaban oleh miqrogroove Sabtu, 25 Januari 2020 08.36
    Senin, 26 Januari 2015 17.18
  • Flipping the EnableActiveProbing from 1 to 0 solved this problem for me in Windows 2012.
    Sabtu, 25 Januari 2020 08.41