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.


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.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

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.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

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.


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.

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

IPv6 Readiness Update for Windows 7 and Windows Server 2008 R2

Microsoft has made available an update for Windows 7 and Windows Server 2008 R2 to improve the operability and performance for these operating systems when you migrate from IPv4 to IPv6. Specifically the update resolves an issue where clients with a public IPv4 address, which are automatically assigned a 6to4 IPv6 address, may not be able to reach IPv6 hosts. The update includes a feature that allows the client to check and verify end-to-end IPv6 connectivity through the 6to4 relay before adding the IPv6 route to the routing table. This addresses one of the IPv6 “brokenness” issues where clients would try to establish an IPv6 connection to an address that could not be reached through the relay. The update also addresses stability issues when many IPv6 addresses and routes are used, and alters the default behavior of Internet Connection Sharing with 6to4. In addition, when clients are configured to use IPv6 as their default connection but don’t have an IPv6 connection to the Internet, the update enables the use of the Network Connectivity Status Indicator (NCSI) functionality to verify IPv6 Internet connectivity before establishing a connection. If an IPv6 connection to the Internet is not available, the client will use IPv4 instead of IPv6.

You can download the IPv6 readiness update for Windows 7 and Windows Server 2008 R2 here.

Understanding IPv6 Third Edition

Joseph Davies’ latest book Understanding IPv6: Your Essential Guide to IPv6 on Windows Networks is now available. Now in its third edition, this book is an excellent reference for systems administrators and network engineers wanting to learn the fundamentals of IPv6, and specifically how IPv6 is deployed on Microsoft networks. The book explains in detail the inner workings of the IPv6 protocol, including addressing, IPv6 headers, ICMPv6, and neighbor discover. In addition the book also covers IPv6 name resolution, routing, and transition technologies such as ISATAP, 6to4, Teredo, IP-HTTPS, DNS64, and NAT64. New in this addition is a chapter covering DirectAccess in Windows Server 2008 R2 and Windows Server 2012. Get your copy today!

Discussing DirectAccess on Security Talk

Recently I had the pleasure of sitting down with my good friends Yuri Diogenes and Tom Shinder to talk about DirectAccess on their video series “Security Talk – From End to Edge and Beyond“. We discussed the current state of DirectAccess in Windows Server 2008 R2, and then we talked in detail about some of the compelling new features of DirectAccess coming in Windows Server 2012. You can watch the video interview here. Enjoy!

Discussing DirectAccess on Security Talk with Yuri Diogenes and Tom Shinder

Discussing Windows Server 2012 DirectAccess on RunAs Radio

Recently I had the privilege to join Richard Campbell on the popular technology podcast RunAs Radio to discuss Windows Server 2012 DirectAccess. Richard and I talked about the challenges network architects and system engineers face deploying DirectAccess with Windows Server 2008 R2 and how Forefront Unified Access Gateway (UAG) 2010 can resolve some of those issues. We also discussed at length the features and capabilities of the new unified remote access role with Windows Server 2012, including the simplified DirectAccess deployment. You can download the podcast here.

Richard Hicks talks DirectAccess on RunAs Radio

Learning IPv6

IPv6 is one of the main underpinnings of DirectAccess. All communication between the DirectAccess client and the DirectAccess server and corporate network resources takes place using IPv6 only. DNS64 and NAT64, the protocol translators for DNS and NAT, address these concerns by translating native IPv6 traffic to IPv4, allowing the DirectAccess client to communicate with systems on the corporate network that are running only IPv4. This significantly reduces the barrier to entry for the adoption of DirectAccess as a remote access solution, but it doesn’t eliminate the requirement for IPv6 altogether. When DNS64 and NAT64 are leveraged, either as part of UAG DirectAccess or the unified remote access role in Windows Server 2012, it is important to remember that the DirectAccess client still communicates with the DirectAccess server using IPv6. It is for this reason that I strongly recommend and encourage systems and network engineers to start learning IPv6 today! I realize that IPv6 looks a bit scary from the outside. The address space is 128-bit and IPv6 addresses are written in hexadecimal, which can be quite daunting for many, me included. There are some new acronyms to learn as well. However, do you recall a time when you didn’t know IPv4? I certainly do! I remember first learning it and thinking I would never get it. Subnet masks? Dotted decimal notation? CIDR? They were completely foreign concepts. Eventually you learn it, gain experience deploying and troubleshooting it, and soon thereafter it becomes second nature. That is most people’s experience with IPv4, and it will be no different with IPv6. It will just take time to learn this new technology.

So, don’t be overwhelmed by IPv6! It’s not like you have to learn an entire new networking model top to bottom. After all, the bottom line is that it is just layer 3 – IP. Begin reading books on the subject and more importantly start deploying it in a lab environment. Soon you’ll have valuable knowledge and experience with the IPv6 protocol which will make you a more complete engineer. To get started, here are a few resources I’d recommend as you begin your quest for IPv6 knowledge and experience:

Understanding IPv6 – This is an excellent book to read to start learning about IPv6. Joe Davies is an outstanding writer and the third edition of this book is due out this summer. Ed Horley, a preeminent expert in the field of IPv6 and co-chair of the California IPv6 Task Force is serving as the technical reviewer so it is sure to be outstanding.

IPv6 Essentials – Another great book about IPv6 written by Silvia Hagen.

IPv6 test lab guide – Test lab guides are essential for learning new features of the Microsoft operating system and applications. The IPv6 test lab guide provides detailed and prescriptive guidance for deploying IPv6 on a Microsoft network.

Good luck!

Microsoft Windows DirectAccess Overview

I thought that it would be fitting for my first real blog post here on to provide a high level overview of what DirectAccess is all about. DirectAccess is an always-on remote access solution for Microsoft managed systems. DirectAccess is not a protocol; rather it is a collection of technologies used to provide network connectivity to users who are located outside of the corporate office. Some of these technologies include IPsec, IPv6, certificates, and Active Directory and group policy. On the client side, DirectAccess leverages the Windows Firewall with Advanced Security (WFAS) and the Name Resolution Policy Table (NRPT).

DirectAccess is a paradigm shift in remote access technology. Traditional (legacy?) client-based remote access is user-initiated, requiring the user to establish a Virtual Private Network (VPN) connection any time they need access to the corporate network. By contrast, DirectAccess is completely transparent to the user. The corporate network connection is established in the background automatically whenever the user has access to the Internet. Fundamentally, DirectAccess isn’t really a VPN at all. There’s nothing virtual about this network – it is the private network!

DirectAccess is a feature of the Windows Server 2008 R2 operating system. Often I’ll refer to this as native DirectAccess. However, there is a serious limitation that comes with native DirectAccess. Since DirectAccess clients communicate using only IPv6, this requires that any systems on the internal private network that the DirectAccess client communicates with be configured with IPv6. Sadly, very few organizations have IPv6 deployed today. Obviously this is a barrier to entry for many companies. To address this limitation, the Forefront Unified Access Gateway (UAG) 2010 can be deployed as a DirectAccess server. I typically refer to this as UAG DirectAccess. UAG includes protocol translators for DNS and NAT (DNS64 and NAT64) that allow the DirectAccess client to communicate with native IPv4 only networks, eliminating the requirement to deploy IPv6 on your internal network (for now).

So what are the benefits to deploying DirectAccess for remote access? Well, here are a few things to consider:

User experience – Seamless and transparent! Since DirectAccess is an always-on connection it requires no action from the user to establish remote network connectivity. When a user travels outside of the corporate office they can access data and applications from their mobile computer in exactly the same way as they do when they are in the office.

Systems management – Since corporate network connectivity with the DirectAccess client is established any time it has access to the Internet, management agents running on the DirectAccess client will be able to communicate with management servers to receive updates and report compliance. This also means that DirectAccess clients regularly receive group policy updates. In addition, the DirectAccess communication channel is bi-directional, which allows hosts on the corporate network to initiate communication outbound to DirectAccess clients whenever they are connected to the Internet. For example, if a remote user calls the help desk for assistance, the help desk engineer can initiate a remote desktop session to the DirectAccess client to assist the user.

Authentication – The DirectAccess communication channel is fully authenticated and encrypted. Initial remote connectivity is established to infrastructure services such as domain controllers, DNS servers, and systems management servers. When the user presses CTRL-ALT-DELETE to log on to their system they are authenticated against a domain controller and not using cached credentials (as long as they have Internet access prior to logging on). This means password changes can be done using CTRL-ALT-DELETE and password lockouts due to out of sync passwords are virtually a thing of the past.

As wonderful as DirectAccess is, it does have some potential drawbacks and limitations. First, DirectAccess is only for managed Windows clients running Windows 7 Ultimate or Enterprise, or Windows 8 Enterprise. The DirectAccess server and clients must be members of an Active Directory domain. DirectAccess is not supported for non-domain joined systems, non-Microsoft operating systems, or mobile devices of any type. Some applications many not work over a DirectAccess connection due to the requirement for DirectAccess clients to use IPv6. If an application has hard-coded references to IPv4 resources, or if the protocol itself has IPv4 addresses embedded in it, communication over a DirectAccess connection will fail. These scenarios will require the use of another VPN technology such as SSL VPN or traditional network-layer VPN.

Looking ahead, Windows Server 2012 will bring some very exciting changes to DirectAccess and remote access in general. I’ll be writing about those things in more detail soon. Stay tuned!

%d bloggers like this: