Windows Vista Phones Home

OK. Perhaps not "phone home" in the sense that these people think, but it does in fact do it, at least on a minor scale.

A Windows Vista "feature" called Network Connectivity Status Indicator (NCSI) goes and fetches a file hosted on a Microsoft web server (a farm of servers, no doubt, once a widespread adoption is realized). It's a simple HTTP GET.

In fact, you can see for yourself. Fire up wireshark (or similar) while watching the traffic of a vista client. You'll notice a DNS query for www.msftncsi.com (Microsoft Network Connectivity Status Indicator) and you'll see the GET request for a file named ncsi.txt. Basically, if a client can fetch that file, Vista thinks the network interface has Internet access. Sounds simple, right? And of course, in true Microsoft style, disabling the feature will have negative effects on every application that calls the API that exposes whether or not that file could be fetched (think timeouts and bad coding habits).

What's interesting is the basic traffic analysis that can be performed just by watching clients fetch that file. In that HTTP GET request, the Vista client will pass the user agent string, not to mention it will initiate the TCP session from a randomly chosen high port. And of course, there's the source IP Address (which is likely behind a NAT in an enterprise). Without a degree of certainty, but with a degree of at least entertainment, one could see, say, how many Windows Vista installs existed behind a specific public IP Address. That might be interesting. Especially to somebody having a vested interest in, say, licensing compliance.

But that's not the biggest or most obvious problem. It's not necessarily the most preferred method of checking Internet "connectedness" for an enterprise. And since turning it off supposedly has negative effects (do your own Googling for that), there has to be a better way to configure this service.

And in fact there is ... Here is one option and some implementation choices: configure the service to connect to a different URL, perhaps one controlled by the enterprise in question, or perhaps just to another service. For complete irony, I'm choosing in this example to use the service of an organization that we all know (wink) to do no evil: Google.

Obviously there are going to be a few requirements about the URL you choose:
1) It has to small and lightweight, for performance reasons. You don't want 5000 machines checking for the existing of, say, an ISO CD image file every time the network interface's state changes.
2) It has to be mostly static, otherwise if the URL goes away then your clients (and apps) will think "the Internet needs rebooting".
3) It has to be a URL that is accessible from both inside of an Enterprise Network and outside at the local Starbucks. Remember, if you're an enterprise that authenticates every HTTP object request, this particular feature will run in the "LOCAL SYSTEM" security context inside of Windows, meaning that unless you grant "Domain Computers" or "Vista Computers" (the latter being a group you'd have to create) in your Active Directory forest to have Internet access, this process will fail. Yes ... it checks the NCSI even when a user has yet to log on.

Note that instead of a "ncsi.txt" file (a surprisingly small 34 bytes), I have chosen the ubiquitous "favicon.ico" URL, because it's static, it's prevalent, and because Google (a highly available service world wide) makes use of it, too, although it's a couple orders of magnitude higher at 1002 bytes (but it's ripe for caching). So, the astute readers will notice it meets the above three requirements.

Also note that the NCSI config requires a DNS server name and IP address. I'm choosing OpenDNS, since I've been so impressed with them recently (especially, in this case, their use of Anycast). It should work well for you as well.


Registry tweak.
A quick tweak to the registry is easy if it's just a handful of machines.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet]"EnableActiveProbing"=dword:00000001
"ActiveWebProbeHost"="www.google.com"
"ActiveWebProbePath"="favicon.ico"
"ActiveWebProbeContent"="OpenDNS"
"ActiveDnsProbeHost"="resolver1.opendns.com"
"ActiveDnsProbeContent"="208.67.222.222"

Group Policy ADM template.
A custom GPO that you can configure inside the Group Policy object editor to point to a URL of your own choosing. Oh, and you'll want to go through the View > Filtering options and uncheck the last box, as shown below, so that you can actually see the ADM template's setting options.



CLASS MACHINE
CATEGORY "Custom NCSI"
KEYNAME "SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet"

POLICY "EnableActiveProbing"
VALUENAME "EnableActiveProbing"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY

POLICY "ActiveWebProbeHost"
PART "ActiveWebProbeHost" EDITTEXT
DEFAULT "www.google.com"
VALUENAME "ActiveWebProbeHost"
END PART
END POLICY

POLICY "ActiveWebProbePath"
PART "ActiveWebProbePath" EDITTEXT
VALUENAME "ActiveWebProbePath"
DEFAULT "favicon.ico"
END PART
END POLICY

POLICY "ActiveWebProbeContent"
PART "ActiveWebProbeContent" EDITTEXT
VALUENAME "ActiveWebProbeContent"
DEFAULT "OpenDNS"
END PART
END POLICY

POLICY "ActiveDnsProbeHost"
PART "ActiveDnsProbeHost" EDITTEXT
VALUENAME "ActiveDnsProbeHost"
DEFAULT "resolver1.opendns.com"
END PART
END POLICY

POLICY "ActiveDnsProbeContent"
PART "ActiveDnsProbeContent" EDITTEXT
VALUENAME "ActiveDnsProbeContent"
DEFAULT "208.67.222.222"
END PART
END POLICY

END CATEGORY



...
And of course, all of this is free for your use but without support or warranty of any kind. I am posting it here because I could not find these answers when I went looking for them.