I recently ran into an issue with my homelab that took several months to figure out. Ok, I didn’t troubleshoot non-stop, but nonetheless it took me several months to figure out what was going on and come to a solution. This blog post is written to step through the issue and hopefully help other people in the future (and maybe find another solution).
Here’s the scenario. I have a single server running Windows Server 2016 and Hyper-V. On this server I have several virtual machines set up in my test lab: a single DC, some Skype 2015 Standard and Enterprise Editions servers, a single Exchange 2016, an Office Online Server, and a Windows 7 & 10 clients. I have all these servers running on an Internal Network virtual switch, meaning the servers can all communicate with each other but not with the rest of my home network. I do this in the hopes of increasing network performance for the VMs and not flooding my home network with extraneous network traffic. When configuring static IP addresses for the VMs in this scenario, you configure an IP address and subnet mask, but there’s no need to configure a default gateway as the virtual machines can automatically route and communicate their network traffic.
In this scenario, when viewing the network connection status in Network and Sharing Center, it will most likely say “No Internet Access”, which makes perfect sense. The OS recognizes it is on a network but can’t communicate with the Internet. This is how it appears on the Windows 2012 R2 & 2016 servers:
However, if you look at a Windows 10 PC, it says “No Network Access”, which I interpret to mean that the OS doesn’t recognize it is connected to a network and definitely can’t talk to the Internet. Example:
The trouble with this configuration began when I created a Windows 10 VM to act as a client in my test network with Skype for Business 2016 installed. When I tried to sign into the Skype client, it would just hang at the sign-in window like this:
It would never time-out, it would never display an error, it simply sat there. I gathered the UCCAPILOGs from the client machine, but they did not have any SIP activity to view any errors. I gathered logs from the Skype server using CLSLOGGER, but not indication of the client or user attempting to sign in. I attempted a manual configuration of the client to log directly into the server but no such luck.
The UCCAPILOG did have one error that I latched onto: HRESULT API Failed: 80004005 = hr. ParsePidVidMi:
Searching for that error led me to this support article where the poster was having similar issues where a single computer would not allow anyone to log into it. Their solution was a registry permission change, but that was not sufficient in my case. However, this led me down learning more about Windows 10 Network Connection Status Indicator (NCSI). NCSI is a part of the Network Location Awareness (NlaSvc) service, and its primary purpose is to detect Internet connectivity status. It is also responsible for detecting corporate network connectivity status when using something like DirectAccess. This is done through the client service trying to access the URL http://www.msftncsi.com and trying to download a file named ncsi.txt through an HTTP get request.
I suspected this was causing my issue. For some reason, Windows 10 was unable to connect to this URL (due to the internal virtual network on my Hyper-V server) and was determining that there was no network connectivity rather than no Internet access. I found two articles, one from Microsoft and one from another blog showing some possible ways to disable this network connectivity check or even a way to host your own NCSI server to take the place of Microsoft’s hosted one. Neither of these worked for me, but I’m not entirely convinced I did not set something up correctly. Articles for reference:
In the end, the only solution I was able to find is to disable the Network List Service. This service is responsible for identifying the networks the computer has connected to and to notify application when the properties of the network changes. When this service is stopped and disabled, I am able to successfully sign into the Skype for Business client on a Windows 10 system. My theory is that the Skype for Business client is somehow looking at this network status and determining that it cannot sign in because the networking service has determined there is no network connectivity. However, the flaw here is that the client does not report back any errors about network connectivity not being present; it only hangs and never gives an indication of a problem (except, you know, never signing in).