Microsoft gave us DirectAccess in Windows Server 2008 R2 as a way for remote users to have an “always on” secure connection to your internal Active Directory domain. In this post I describe Microsoft's remote access technology and give an overview of the new features of DirectAccess in Windows Server 2012.
Latest posts by Timothy Warner (see all)

Traditional virtual private network (VPN) connections are generally a pain both for network administrators as well as users. For instance, we admins have to deal with the following pain points (among others):

  • Remote user unwillingness to use their VPN connections
  • Support tickets based on VPN-related user error
  • Balancing firewall rules, protocols, port numbers, and encryption methodologies on the VPN concentrator side and the client side
  • Connectivity issues arising from IPv4/IPv6 mixed networks, network address translation (NAT) devices, etc.

With DirectAccess, the packet encapsulation, data encryption, and user/computer authentication happens as soon as the TCP/IP protocol stack initializes on the client, even before user logon.

The problem with the original release of DirectAccess, though, was its restrictive requirements generally represented too large a hurdle for many Windows systems administrators to overcome. For example, DirectAccess in Windows Server 2008 R2 required (at least) the following for your environment:

  • Public key infrastructure (PKI) with your infrastructure servers and all client devices requiring digital certificates
  • The internal network must be running IPv6
  • To support IPv6 to IPv4 translation inside your corporate LAN, you had to purchase a license for Microsoft Forefront Unified Access Gateway (UAG)
  • The DA server must have two NICs with two consecutive public IP addresses

Those were some daunting requirements, right? The great news for those of us who need to support remote users but who are not VPN experts is that Microsoft did away with most of those restrictions in the Windows Server 2012 release of DirectAccess.

DirectAccess feature improvements

Let’s begin by providing you with a laundry list of feature improvements that Microsoft made to DirectAccess in Windows Server 2012:

  • Rich client monitoring: You can view connected DA clients from the server
  • Client troubleshooting: You can use DA client PowerShell cmdlets or the Netsh command to troubleshoot DA client configuration settings
  • Unified management wizard: A “simple” setup option hides most of the underlying complexity of DirectAccess (encryption protocols, certificates, IPv6-to-IPv4 translation, and so forth)
  • DA server can use a single IP address, and can even be placed behind a NAT
  • Server Core support

Technically, DirectAccess works by building an IPv6-based, IPsec-encrypted tunnel between the DA client and a DA server endpoint. Multiple protocols come into play in building this tunnel; the specific one(s) that the server and client negotiate depend upon a number of factors, such as the presence or absence of a NAT and any configured firewall rules.

Here’s a smattering of information concerning the DirectAccess remote access protocols:

  • IP-HTTPS: This is a good choice because the secure tunneling occurs over TCP 443, which is never blocked by firewalls
  • 6to4: We can successfully encapsulate IPv6 packets inside of IPv4 packets when the client and server are directly connected to the Internet (no NAT)
  • Teredo: This IPv6-to-IPv4 encapsulation method works great when a NAT is involved in the connection
  • DNS64, NAT64: These protocols, run on the DA server, allow the client to communicate with IPv4-based internal server resources

Server Setup Basics

To get DirectAccess up and running by using the simple wizard, follow these steps:

  1. Install the Remote Access server role on your DA server and install the DirectAccess and VPN (RAS) role services.
  2. After installation, fire up the Remote Access console.
  3. Run the Getting Started Wizard. This is the simple wizard that abstracts most of the setup complexity from you. Don’t worry, though—you will have the chance to modify your configuration later if you need to.
  4. After the wizard completes, navigate to the Operations Status page in the Direct Access console and periodically refresh the view until all DA components are listed in a Working state. This interface is shown in the following screenshot.

Operations Status page in the Remote Access console

Operations Status page in the Remote Access console

That’s literally all there is to basic DirectAccess setup in Windows Server 2012! Now, the downside to the simple setup is that the wizard abstracts the complexity from you and minimizes your initial choices. For instance, you may need to return to your DirectAccess server setup to perform the following tasks:

  • Switch from a self-signed DA server certificate to a genuine one
  • Modify the GPO scope for client devices and/or servers

To do this, simply open your Remote Access console and click the desired DA server from the list. You’ll get a live graphic (shown in the following screenshot) that you can click to modify settings for remote clients, remote access servers, infrastructure (back-end) servers, and application (user resource) servers.

Modifying our DirectAccess configuration

Modifying our DirectAccess configuration

The client experience

First off, be aware that DirectAccess is supported only by Windows 8 Enterprise Edition or Windows 7 Enterprise or Ulitimate Edition. To that point, the certificate-less Kerberos proxy works only with Windows 8 clients. That is, you’ll need to deploy a PKI if any of your DA clients run Windows 7.

As far as the user experience of DirectAccess, there is no VPN clients to start. Actually, there is no action required of them at all—all protocol negotiations take place under the hood.

In Windows 8, we can open the Charms bar and click our network connection to see if were are connected via DirectAccess or another network connection type.

Windows 8 client notification that DirectAccess is active

Windows 8 client notification that DirectAccess is active

Finally, we can use either the old-school Netsh name show effectivepolicy command or the new-school Get-DAClientExperienceConfiguration PowerShell 3 cmdlet to view client DirectAccess configuration.

Troubleshooting DirectAccess client settings via PowerShell 3

Troubleshooting DirectAccess client settings via PowerShell 3

Note that we have rich reporting of client connection data on our DA server via the management console as well.


In my opinion, Microsoft did a fantastic job at making DirectAccess easier to implement and use in Windows Server 2012 and Windows 8. I’ll leave you with some hand-picked resources that you can use as a basis for further study:


Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account