One of the key pieces of a working DirectAccess solution is the Network Location Server or NLS. The purpose of the Network Location Server is to help the computer configured as a DirectAccess client to know that it’s inside the corporate network. When the DirectAccess client is inside the corporate network, you don’t want it to use the DirectAccess tunnels to reach internal resources. Instead you want the DirectAccess client to connect directly to the resources when they’re on the corporate network.
There are actually two primary things that happen when the computer configured as a DirectAccess client enters the internal network:
You can tell that the NRPT has disabled itself by running the netsh namespace show effectivepolicy command. You’ll see the Note: DirectAccess settings would be turned off when computer is inside corporate network, as seen in the figure below.
Conversely, if the DirectAccess client can’t find a domain controller and it can’t connect to the Network Location Server, then it will try to enable the DirectAccess IPsec tunnels and it will enable the Name Resolution Policy Table (NRPT). When the NRPT is enabled, name resolution for requests for intranet resources will be sent over the DirectAccess tunnels (if they can be established) and resolved by the UAG DNS64 DNS proxy.
If the DirectAccess client can’t establish the DirectAccess tunnels to connect to the DNS64 component, then name resolution requests for intranet resources will fail. As you can imagine, not being able to resolve names on the intranet can have some pretty negative consequences, some of which I describe at http://blogs.technet.com/b/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx and http://blogs.technet.com/b/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
Which brings us to a case we encountered a couple of weeks ago. Everything was set up right:
Things looked perfect. However, when the DA clients were returned to the intranet, the NRPT would not turn itself off. This would be consistent with a problem connecting to the NLS, but when we pointed the browser to the NLS, the default web page came up fine.
We did a network trace using NetMon 3.4 and found that the DA client was making repeated connection attempts to the NLS. This was a bit strange, so we dug deeper.
We found out that the web server (a non-IIS server, but that’s no problem, we support any web server for the NLS server) was returning a bad header. This lead WinHTTP to not be able to parse the web page response and conclude that there was a server failure. In contrast, when we connected to the site using the web browser (IE), the bad header was ignored by WinInet (used by IE) and the page was successfully rendered in the browser.
What surprised me about this was that I had the impression that all we needed to do for a successful NLS connection was to successfully establish an SSL connection to the NLS and receive a 200 OK response from the web server. In fact, we need a little more than that – WinHTTP needs to be able to successfully parse the web page response in order to create a successful NLS connection.
I don’t expect this to be an issue for the vast majority of DirectAccess admins, but it might be something to keep in your back pocket if you’re having problems with the NRPT not being disabled when the DirectAccess clients are on the intranet and when you are using non-IIS servers for your NLS server, where you’re more likely going to customize the headers and thus might experience a typo in the process.
One more thing – if you ever have any questions on DirectAccess make sure to head on over to the UAG DirectAccess forum over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Tom Shinder email@example.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Tom, with regard to "The Mystery of the Working Network Location Server that Did Not Work" you did not say what you did to solve the problem. We have this exact behaviour on an IIS server. As per your list:
•Certificates – check
•Network Location Server – check
•DA client and server GPOs deployed – check
•Infrastructure and intranet tunnels established when DA client outside the name – check
•Security Groups for DA clients – check
NLS is accessible via a browser but after ~20 seconds the client fails inside/outside detection and attempts to establish the tunnel
I have a problem with NLS on w2k12 DirectAccess, after running configuration wizard,on the configuration summary window an error occured,it says;
"The network location server certificate exists,but the subject name of the certificate doesn't resolve to the internal IP address of the Remote Access Server"