Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.

Global Settings

There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.

Parallel Deployments

To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.

Common Use Cases

QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.

Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.

Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.

Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.

Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.

Requirements

To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:

Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.

Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.

Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.

Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.

Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.

Supporting Infrastructure

The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.

Migration Process

Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.

Summary

DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.

48 Comments

Steve Burkett

How about when wanting to have some laptops/users with full DirectAccess connectivity to internal resources, but the rest of the deployed laptops as only having DirectAccess to management servers (such as ConfigMgr and AV servers) for reporting and remote management purposes? Should we again be using two DirectAccess instances for that scenario?

Yes, that would be another excellent example of the use of parallel deployments. Full access vs. management only configuration is global in scope, so you’d have to choose one or the other. Having two deployments allows you to tailor those requirements to your specific needs.

Richmond Howie

Thank you for another one of your as ever helpful posts. I do have one question regarding this topic. What are the impacts on the DNS entries created by DA, in particular the AAAA record for directaccess-corpConnectivityHost and the A record for directaccess-WebProbeHost? Will it overwrite the existing entries or have multiple entries for the same name, but then how to limit specific clients to only resolve the entries valid for them?? Apologies for my ignorance with the DNS records, I had a read through your posts on DNS records created and the fact that multi-site will have multi values for the second record, but this is a multi-deployment model which is obviously different.
On a different topic, have you come across issues using ECC certificates for the certificate used to authenticate IP-HTTPS connections?

In a multisite deployment you will have multiple entries. They won’t overwrite each other. As for using ECC certificates for the IP-HTTPS listener, I can’t say that I’ve encountered that scenario as of yet. I haven’t heard of any issues, however. If your experience is different, please let me know!

Anton Brauchli

Hi Richard
How about a Scenario where all Systems, independent where they are coming from, will connect to DA. Also all internal clients.
Initially the plan was to connect all systems to the same DA instance but then we don’t have the ability in SCCM to differ where the clients are coming from. This is important to us because we don’t want to allow SCCM traffic when the clients are connecting from external sites to avoid possible mobile telecom costs.

Perhaps I don’t understand the use case clearly, but I can’t see why having internal clients connect via DirectAccess would be a good idea. I’m not sure there’s a good way to address the SCCM traffic issue over mobile networks either. DirectAccess only detects inside or outside, and if outside will establish a DirectAccess connection. It doesn’t have the capability to distinguish between types of network connections (Ethernet, Wi-Fi, cellular, etc.). I don’t know enough about SCCM to say for sure, but perhaps there’s a detection method that can be used by SCCM to detect the link type?

Steve Burkett

Windows 8 and 10 clients have built-in metered internet connection types for interfaces, and SCCM will honour those and not download using that interface, unless you force to override for a particular deployment (e.g. emergency patches). Windows 7’s not that intelligent though.

Craig

Slightly off topic for the above post but I couldn’t find one specifically talking about multi-site.

I have a single site, single server 2012 R2 DA set up running with only Windows 7 clients at present – no OTP configured either.

I want to start adding three more servers in different geographical locations but at the same time our business will be gradually moving to Windows 10. My question is can I run a multi-site DA deployment with both Win 7 and Win 10 clients concurrently and if so are there any pitfalls? I already understand the limitation of Win 7 clients having to be associated with a single DA entry point but is there anything else?

You most certainly can. The only drawback for Windows 7 clients and multisite is that the lack of automatic site selection and transparent failover, but if you’re willing to accept that limitation there’s nothing else that should stop you from deploying multisite. As and when you begin to roll out Windows 10, those clients will take advantage of those features along with IP-HTTPS performance improvements too. 🙂

Craig

Craig

Again on multisite rather than multi instances; can you add sites on an ad-hoc basis? By that I mean can I add subsequent entry points whenever I choose after enabling multiste or must all entry points be added when running the wizard.

This happens when a computer certificate has been issued to the DirectAccess server. You can choose to keep and use that certificate, or delete the certificate and use a self signed certificate (not recommended). Keep in mind that if you delete the existing machine certificate, you won’t be able to support Windows 7 clients or a variety of other important features that rely on certificate authentication (e.g. load balancing, multisite, etc.).

Damien

Thanks for the reply. The primary DA site cluster consisting of two DA servers both with the NLS on them is using the default self signed cert “DirectAccess-NLS”. This site is working fine. The new secondary site (not part of multisite deployment) is the one I’m having trouble with. I managed to get around this by issuing a new web certificate from my internal CA called NLS. DA is currently working on both sites now but when trying to add a second server to the new setup I got an error relating to the NLS certificate not being valid and I could not proceed. I was seeing the exact symptoms mentioned here: https://support.microsoft.com/en-us/kb/2799664

I ran that PowerShell script which hung and did not return the prompt. I left it for 10 minutes and still nothing so I cancelled it. After rebooting the servers it has been added. Step 3 of the wizard still shows as an invalid certificate but all is working.

Richard,
I just viewed some of your videos on DirectAccess on PluralSight. Great information!
We currently have 110 folks distributed across six locations with our main site in Austin, Tx. I’ve setup Windows 2012 R2 data center running as DC, DNS and SCCM 2012 R2 at each location. SCCM 2012 R2 runs IIIS to support PXE boot for OS deployments.
Can I run Apache (to support NLS without breaking SCCM), NLS and DirectAccess on these six servers? (All locations are connected via private VPN from ISP.)
Thanks,
Carlton.

Running DirectAccess on a domain controller isn’t expressly unsupported, but it certainly isn’t recommended. You’ve also got quite a few workloads running on the server already, so I’m not sure what the experience is going to be like. DirectAccess is CPU intensive and adding it to your existing server may result in degraded performance for all services.

You can run Apache for the NLS, but it is also possible to set up a separate web site on the IIS server without disrupting anything else. Just make sure you use a unique host name to access the NLS web site, not the name of the server. 🙂

Richard,
I have all Windows 7 Pro and Enterprise clients running. But we have a small number of clients that work from home 50% or more so I could easily upgrade them to Win7 Enterprise or Win10 Enterprise. Ideally I would like to setup DirectAccess and NLS at our Austin site with NLS redudancy at our El Paso office (El Paso is connected via private VPN to all locations including Austin.)
What setup would you suggest? We’re a non-profit, but we get Microsoft licensing at a huge discount.
Thanks for your help on this,
Carlton.

High availability for the NLS will help prevent potential connectivity disruptions for DirectAccess clients on the corporate network. If you get to Windows 10, I’d strongly encourage you to implement DirectAccess multisite for geographic redundancy as well. 🙂

Yes, that’s correct. Switching from single site to multisite DirectAccess will result in the IPv6 addresses used for IPsec tunnel endpoints changing. When this happens, clients are immediately disconnected and won’t get the updated information until they update group policy, which obviously can only happen when they are connected to the LAN again (either directly or via some other VPN technology).

Hi Richard, is direct access able to provide multiple policies based on access level required , for ex i need some users to connect for patching only , and other users be able to access the other corporate resources . or am still need a separate & multiple deployment for each access level

In the article is says “Note: It is not possible to change the names of DirectAccess GPOs after initial configuration is complete. The only way to change GPO names after DirectAccess has been configured the first time is to remove the configuration completely and start over.”

However I’ve found if you just rename the GPO using Group Policy Management Console, the updated GPO name is reflected in the Remote Access Administration console. It must query the GPO GUID and not the name.

Edward

Hi Richard! From searching the internet for tips and tricks for DirectAccess you seem to have the most experience by far. These posts are extremely helpful. My question is about two single DA deployments in parallel, within the same domain, each running 2012 R2…When publishing the secondary DA configuration, there seems to be no way around the newly renamed GPO’s to be linked at the root domain level. However it seems that security filtering does not do its job properly and the GPO applies to laptops within the organization that shouldn’t receive the configuration, therefore causing issues internally until it is manually addressed. I contacted Microsoft and they mentioned that renaming the group policies of “Direct Access Clients (or Servers)” puts it in an unsupported configuration, and they can only suggest using a different domain. What are your thoughts on this? They couldn’t answer my question of why we have the ability to change the GPO names if it makes it ‘unsupported’. Keep in mind this is all through the DirectAccess Management Console, so we’re not changing directly. I’m trying to stand up a second deployment for the exact reason you mention in this post, so I do not disturb production, however when publishing it causes weirdness with GPO’s that are applied that shouldn’t be.

As for security filtering not working, it sounds like you might have enabled the option to apply DirectAccess settings to all mobile computers. That is definitely not recommended. Check your configuration and disable that option if it is enabled. Also, make sure you are using unique security groups for each DirectAccess deployment, and that DirectAccess clients are members of only one of those groups at a time. If they belong to both it won’t work.

Edward

Noted, thank you sir. I did check both items you had mentioned — Apply to all mobile computers is not selected, and we are in fact using unique security groups. For what its worth i got an update from Microsoft, and they are stating that the issue is because both single server deployments are in the same site/domain, which could be causing the problem. Based on your information here it looks like that shouldn’t be an issue?

It seems that they are grasping at straws at the moment, but at least wanted to mention. They are escalating, and i pointed them in the direction of this article showing that a Microsoft MVP in this area of expertise has some information that may be of use to them. I hope they help me get this sorted out! In the meantime, do you see any issue with it being a same site deployment as the current production possible be an issue? -Edward

I am not aware of any issues with deploying multiple instances of DirectAccess in the same domain and AD site. That doesn’t mean there isn’t something I’ve not yet encountered, however. If you are unable to get satisfactory resolution with Microsoft, drop me a note directly and I’d be happy to provide some assistance and guidance for you.

This is a known issue. When deploying multiple DirectAccess servers on the same subnet in a multisite configuration, you must also disable duplicate address detection by issuing the following command in an elevated PowerShell command window on each DirectAccess server.

Cory

I have an existing DA server that I had been running on Hyper-V. I migrated the server to VMWare and the NIC changed. When I try to go back into step 2 to change the nic to the new one, I get an error message stating that ipv6 is not configured on the new nic when it has been.

From what I’ve read, the DA configurator sets the ipv6 info at initial install time and that I would have to delete my config and start over again. Or I could install a 2nd server and move everyone over to that one.

My question is twofold:
1. is there a way to change a nic easily in DA without wiping out the config that is currently set?
2. if I create a new server, is there a way to migrate those users to the new server without a direct link to the LAN? all of the stations affected are mobile users, and they are scattered throughout the country. There is only one homebase and no real satellite office with a more direct connection to the LAN. I’d rather not have to ship replacement machines to all of my remote users if I could prevent it.

I think it might be possible to hack the DirectAccess server GPO to reflect the change of network adapter. I’ve never done it myself, but if you look at the new value of InstanceID when you run Get-NetAdapter and update that detail in the GPO it might work. You could easily add another server to the cluster and you wouldn’t have to update any settings at all. If you created a new DirectAccess deployment you’d have to get clients connected to the LAN to update the settings.

Mark

Thanks for providing such reliable guidance for DA configuration and best practices. Your videos and website are gold (esp your newest DA 2016 video on Pluralsight)! We recently expanded our DA configuration to multisite and now have a single server in each of two datacenters. Everything is working but I found that the DA Server GPO is filtered to apply only to the original/first server. Is that the correct outcome for a multisite installation (no clusters, no load-balancing)?

Hi Mark! Thanks for the kind words. Much appreciated! As for your DirectAccess configuration, there should be a unique GPO for each entry point, filtered to the server or servers that belong to that entry point. If everything is working correctly, there has to be another GPO in your Active Directory somewhere. 🙂

Vinnie

Hi Richard, I have 2 single DA servers in the organisation. I got 2 directaccess-WebProbeHost in DNS. All network is IPv4. I got 1 ectaccess-corpConnectivityHost 127.0.0.1. Do i need to have 2 directaccess-corpConnectivityHost AAAA IPv6? When i ping directaccess-corpConnectivityHost from 2 diferent client i got 2 diferent IPv6 responds. Thank you.

If you have two separate DirectAccess deployments, then you should have one entry for directaccess-corpConnectivityHost that resolves to the IPv4 address 127.0.0.1 and two entries that each resolve to the IPv6 address beginning with your NAT64 IPv6 prefix for each deployment and ending with ::7f00:1. For the record though, DirectAccess seems to work without issue even if these DNS entries are not present (at least with 6to4 and Teredo disabled anyway).

Hi Richard
109/5000
I’m working on how to properly deploy DA. Your website and books have provided me with great help. Thank you very much. Now that I have a problem, we plan to use a single NIC and put it in the topology behind the NAT device. Now that the load balance has been implemented using the NLB, if i want to deploy multiple sites, whether a single NIC is allowed？
Looking forward to your reply.

Yes, you can deploy DirectAccess in a multisite configuration using a single NIC. In fact, you can even mix and match if you like. One entry point could have single NIC DirectAccess servers and another point could be multihomed. You just need to make sure that all DirectAccess servers in the same entry point are configured identically (single or multi-NIC).

Vas

I am currently running a parallel Direct Access 2016 environment with an external load balancer. This environment has been setup exactly the same way as the working prod environment.

I have come across a couple of issues which I am not sure if they are related to each other.

1. The client computer trying to connect to the new environment is coming up with an error “Action needed – Windows Firewall must be turned on” This error does not appear when connecting to live environment

2. On the client machine the NRPT table becomes corrupt when moving the computer object from the old DA environment to the new one. I have had a look at the registry and found two sets of IPV6 addresses (old DA server and new Da server) in the DNSPolicyConfig entry

Unusual. The only thing I can suggest is that you make certain that your DirectAccess client belongs only to a single DirectAccess security group at a time. If your client is included in both groups (old and new) you’ll have all sorts of problems.

Vas

Thanks for your response. Thought I post the my findings in case someone else comes across similar problems. It appears that the issue was GPO related. Both the old and new ” Direct Access Client Settings” GPO’s was applying to the client machine causing all sorts of problems. I had to block GPO inheritance on the OU the new GPO was linked to then force a GPO update. I then checked that the new GPO was the only one applying and confirmed that everything started to work. A pretty simple mistake but I overlooked the way that the old GPO was applying to the rest of the environment.