Introduction
For a DirectAccess deployment, the Network Location Server (NLS) is an infrastructure component that allows DirectAccess clients to determine if they are inside or outside of the corporate network. If the DirectAccess client can successfully connect to the NLS, it is on the internal network and DirectAccess is not used. If the NLS cannot be contacted, the client is outside of the network and will attempt to establish remote corporate network connectivity using DirectAccess.
High Availability
It is recommended that the NLS be made highly available by deploying at least two servers in a load balanced configuration to avoid potential service disruptions for DirectAccess clients inside the corporate network. While this approach is sufficient for networks that are contained in a single physical location, it does present some challenges for large organizations with internal networks that span multiple physical locations.
NLS Challenges
For DirectAccess, only a single NLS URL can be configured per DirectAccess deployment, as shown here.
If a WAN outage occurs on an internal network that spans multiple physical locations, internal DirectAccess clients in locations other than where the NLS resides will mistakenly believe they are outside of the corporate network. This can lead to degraded performance and potential loss of connectivity. NLS reliability can still be improved when the internal network spans multiple physical locations by deploying NLS at each physical location and configuring clients to use a local NLS. This will keep traffic off of the WAN and prevent service disruptions in the event of a WAN outage.
Redundant NLS
There are several strategies that can be used to configure internal DirectAccess clients to use a local NLS, including DNS round robin, a network load balancer, or Active Directory Group Policy. Using DNS or a load balancer requires only a single NLS URL. Using Active Directory Group Policy requires a unique NLS URL per physical location.
DNS
The simplest way to enable DirectAccess clients to use a local NLS is to use DNS round robin and take advantage of subnet prioritization. To do this, create an “A” resource record in DNS that resolves to the IPv4 address for each NLS. On the DNS server, open the DNS Manager, right-click the DNS server and choose Properties. Click the Advanced tab and select the options to Enable round robin and Enable netmask ordering.
This will ensure that name resolution requests for the NLS FQDN will be returned with the nearest NLS. More information about DNS netmask ordering can be found here.
Load Balancer
A Global Server Load Balancing (GSLB) solution can also be employed to route requests to a local NLS. Examples include F5 Global Traffic Manager (GTM) and Kemp Technologies LoadMaster GEO. Prescriptive guidance for configuring the Kemp LoadMaster for this scenario can be found here.
Group Policy
This method involves creating unique NLS URLs per site and overriding the default DirectAccess client configuration using Active Directory Group Policy. Separate Group Policy Objects (GPOs) are created and linked to Active Directory Sites to assign a local NLS to internal DirectAccess clients. To accomplish this, create a new GPO for each location where NLS will reside. Edit the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator. Double-click Specify domain location determination URL, choose Enabled, and then enter the URL that corresponds to the NLS for that location.
In the Remote Access Management Console, edit the Infrastructure Server Setup (Step 3) and add the FQDN for each NLS. Do not specify a DNS server. This effectively creates a Name Resolution Policy Table (NRPT) exemption so the NLS cannot be reached when the DirectAccess client is connected remotely.
In the Group Policy Management Console right-click on Sites and choose Show Sites.
Select each Active Directory site where NLS will reside.
Link the GPOs for each NLS to the corresponding site, then right-click the linked GPO and choose Enforced.
Note: Do not install the NLS on a domain controller! By design, the NLS is not reachable remotely by DirectAccess clients. This can lead to potential authentication issues and may prevent DirectAccess clients from connecting successfully.
Client Testing
To confirm that a client computer has been configured to use a local NLS, verify the currently associated Active Directory site by issuing the following command on the DirectAccess client computer:
nltest /dsgetsite
Next, confirm the setting of the NLS by issuing the following command:
Get-NCSIPolicyConfiguration
As a reference, here are examples from two DirectAccess clients in two different internal physical locations:
Summary
The limitation of a single Network Location Server (NLS) URL for a DirectAccess deployment presents some challenges for DirectAccess architects seeking to eliminate single points of failure in their design. Using the techniques described in this article, administrators can ensure that DirectAccess clients will always connect to a local NLS, eliminating potential failure points and improving the overall reliability of the solution.
Additional Resources
DirectAccess Network Location Server (NLS) Guidance
Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)
Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)
Configure F5 BIG-IP for DirectAccess Network Location Server (NLS)
xcomiii
/ April 7, 2015Thanks! Never tought of the site GPO trick before.
Thomas Forsmark Soerensen
/ April 9, 2015Hi Richard,
Great article. I never thought about using policies for setting the NLS URL, instead of using local DNS zones on the local DNS servers on the sites.
However, I think you still miss to inform that the CRL list for the NLS certificate should be accessible for the clients, when they check access to the NLS site. If the CRL is not available then the NLS certificate will be seen as invalid and the NLS check will fail.
Please Correct me if I am wrong 😀
Richard Hicks
/ April 9, 2015Hi Thomas,
You are correct. The CRL is indeed critical. However, this article assumes that you’ve configured the NLS correctly in the first place, which includes CRL reachability too. Thanks for pointing that out though! 🙂
ben petz
/ June 27, 2015Interesting Article many thanks for that. From my experience dns netmask ordering doesnt always work well, if the sites have different network structures. i would go with a single GPO within this you configure the NLS for each Site as GPP registry collection and map this via item Level targeting to each AD site. this one gpo will then always detect the current AD site and configure the right NLS on the client and prevents client connections to a different NLS if a user is working sometimes at site A and sometimes at another site.
Richard Hicks
/ July 1, 2015To be honest, I’m not a big fan of relying on netmask ordering myself either. It is included in this article for completeness. Using some of the other alternatives will be much more reliable, for sure. 🙂
Craig
/ August 19, 2015Richard,
I’ve read over the Kemp scenario from your link above, looking at the config for the DirectAccess Server Virtual Service it mentions only 443/IPHTTPS. Am I to assume their product will not work with Teredo or 6to4?
Also, the section on GPOs assumes a one-to-one relationship between an AD Site and a NLS. We have over 60 AD Sites and configuring 60 NLSs would be an admin nightmare. I assume I can instead create, say 5, NLSs with associated GPOs and map multiple Sites to each of the GPOs?
Cheers
Craig
Richard M. Hicks
/ August 24, 2015Hi Craig,
Regarding your first question, it may be possible to configure a load balancer for use with 6to4 and Teredo, but it’s not something I have ever tried. IP-HTTPS is easy to configure and works well, so that is how I’ve always configured load balancing in these scenarios.
As for your second question, yes, clearly creating a unique NLS for each site in your scenario would be unwieldy. You can take the concept of the post and apply it as you see fit in your particular deployment. I’ve also had other readers suggest that using Group Policy Preferences might be a good idea too. I’ve not tried that myself, but it might be worth investigating. 🙂
Craig
/ August 24, 2015Thank you Richard.
Gerald
/ January 29, 2016Hello Richard,
In this “old” post by Tom Shinder (http://blogs.technet.com/b/tomshinder/archive/2010/07/19/what-defines-a-functional-connection-to-a-network-location-server.aspx) I can read that if the NLS is down a DA client won’t try to build the DA tunnels if it can contact a domain controller. Is this (still) true ? Unfortunately for the moment I don’t have a lab environment available to give it a test… Thanks ! Gerald
Richard M. Hicks
/ February 1, 2016Not true. If the NLS does not respond, the NRPT will be enabled without fail. It’s possible you may be conflating this with Teredo behavior. The Teredo protocol will not be used if *any* domain controller can be contacted. Changing Teredo to Enterprise Client type resolves that. 🙂
Craig
/ March 7, 2016Richard,
For the Group Policy solution would it be prudent to also put a security filter on the GPO so only DirectAccess clients apply it?
Richard M. Hicks
/ March 8, 2016Probably wouldn’t be a bad idea, although it wouldn’t negatively affect other non-DirectAccess clients if they got the policy.
Craig
/ March 8, 2016Unless you make a typo with your NLS certificate name like I did 🙂 which then caused all the firewalls on the machines targeted by the policy (including servers) to change to the Public profile. Ouch!
Bob
/ June 27, 2016Hi Richard,
First off, thank you so much for this blog. It’s incredibly invaluable. Now for the question.
Do you have any guidance for changing the NLS URL in production without affecting DA clients on the internal network? Our current deployment utilized the server’s computer certificate and made the NLS match the server name. We want to decouple the URL from the server name so we can deploy additional instances at our other sites.
I’ve generated a new certificate for the URL we want to utilize and was considering adding IIS bindings for the old URL with the old certificate after the change is implemented. Does that seem like it would allow us to change the URL and maintain connectivity for clients that haven’t updated group policy yet?
Richard M. Hicks
/ June 30, 2016There are a variety of different ways to address this. I’ve had success in the past creating a new NLS and then creating a separate temporary GPO that overrides the default DirectAccess client policy settings. After you’ve transitioned to the new URL you can safely remove the temporary GPO.
Thomas
/ August 2, 2016Hi Richard, thanks for a great post. We are looking into the option of assigning NLS name using GPO (we have about 80 sites). One possible challenge that came to mind though was this. Will a computer be able to receive the GPO (containing the address of the NLS) from the Domain Controller before the DirectAccess Client actually know where to Connect. Regards.
Richard M. Hicks
/ August 4, 2016The DirectAccess client attempts to contact the NLS once immediately after a network interface status change. It would already have gotten the policy at least once before this occurs, so I don’t expect you’d have any issues. However, I would at least make sure that the default NLS FQDN (the one defined in the DirectAccess configuration) is reachable to avoid any potential conflicts.
Thorsten Frohberg
/ February 8, 2017Hello Richard, is it normal that after the DA Clients have etablish the DA Connection, they can reach the NLS ?
Richard M. Hicks
/ February 8, 2017No. The NLS should not be reachable over the DirectAccess connection. If it is, there’s definitely a problem with the configuration. It’s also possible that the DirectAccess client has some other network access, either directly or via client-based VPN.
JO
/ June 25, 2018Hello Richad.
First of all thank you for your great post.
Maybe you can help me to confirm my understanding.
My concern is: what if a NLS server fails?
Let’s say I have two sites, Site-A and Site-B
Let’ say I also have two NLS server, one in each site, NLS-A and NLS-B
Let’s say NLS-A suddenly fails.
DNS solution
In short, for the effect of your DNS Server configuration, each resolver will contact the NLS Server of its site.
When NLS-A fails, am I wrong if I think that DNS server will continue to resolve the NLS URL with the NLS-A address, for the site A computers?
This will cause the site A clients to fail, I think
GPO solution
The same way, the clients configured to use NLS-A server via GPO, will continue using NLS-A server and will fail to connect to the network when the NLS-A server fails.
Load Balancer
Sure it will work for all DA clients even when NLS-A fails.
However, a single load balancer will be a new single point of failure.
I’ll need to use a cluster of two or more load balancers.
Am I somewhere wrong?
Is there a way,
Could you please help me to fix with this considerations?
Isn’t possibile, maybe in Windows2016 version, to configure DA clients with a list of more than one NLS server?
Many thanks
Richard M. Hicks
/ July 4, 2018Sorry, there’s no option to configure more than one NLS URL, even in Windows Server 2016. Your only option is to ensure high availability for the NLS using any of the options I outlined in this post, or a combination of them. Ideally you’d have at least two redundant NLS servers in each physical location where DirectAccess clients will reside. Load balancers are your best option, but you’ll have to deploy those in clustered pairs to ensure they aren’t a single point of failure.