Enriched Remote Access experience in Windows Server 2012

Article written by Aydin Aslaner, a Premier Field Engineer based in Dubai (UAE). He is a Networking/Security PFE who focuses on Remote Access technologies and IPv6.

With this series of blog posts I will try to provide you an overview of some key highlights in Windows Server 2012, from an administrator and end-user perspective. In this post, I would like to talk about the DirectAccess feature in Windows Server 2012, which has been greatly enhanced since the previous version in Windows 7 and Windows Server 2008 R2.


Windows Server 2008 R2 introduced DirectAccess, a new remote access feature that allows connectivity to corporate network resources without the need for traditional Virtual Private Network (VPN) connections.

DirectAccess implements IPv6 and IPsec to provide secure connectivity between Windows 7 clients and a Windows 2008 R2 DirectAccess server (or Unified Access Gateway Server - UAG). The idea is to have a seamless remote user experience with a great opportunity for the Administrators to manage those clients wherever and whenever regardless of how they connect to the internet.

UAG 2010 added the following value to the built-in Windows Server DirectAccess:

  • Array management
  • Network Load Balancing support
  • Integrated health assessment for endpoints with NAP
  • Support for non IPv6 hosts on the internal network with NAT64/DNS64

Since the Internet and our Intranets are far away from being "native IPv6 capable”, DirectAccess includes IPv6 transition technologies. Teredo, 6to4 and IP-HTTPS for external and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for internal connectivity. In addition to those above, Unified Access Gateway Server 2010 provides NAT64 and DNS64 Support to overcome IPv6 limitations in internal networks.

Windows Server 2012 not only provides all those features from UAG Server but also adds a lot of more key highlights to the remote access experience to the next level.

What’s new in Windows Server 2012 DirectAccess? 

Highlighted below are a few of the capabilities that come with Windows Server 2012 DirectAccess.

Removal of PKI deployment as a prerequisite for DirectAccess

DirectAccess 2012 does not need PKI deployment

This functionality is achieved by implementing an HTTPS based Kerberos proxy. Client authentication requests are sent to a Key Distribution Center (KDC) Proxy Server service running on the DirectAccess server. The Kerberos proxy then sends Kerberos requests to Domain Controllers on behalf of the client.

Simplified DirectAccess management

You can now deploy DirectAccess using a new Getting Started Wizard, which presents a greatly simplified configuration experience by providing an automated setup in a few simple steps:

Simplified DirectAccess setup and management

Support for DirectAccess server behind a NAT device

When you run the “Getting Started Wizard” above it checks for the status of network interfaces on the server to determine if the DirectAccess server is located behind a NAT device. If yes, only IP over HTTPS (IP-HTTPS) will be deployed.

Support for multiple domains

Windows Server 2012 DirectAccess provides integrated multiple domain support to allow remote client access to enterprise resources located in different domains.

Support for OTP (token based authentication)

Windows Server 2012 DirectAccess supports two-factor authentication with Smart Cards or OTP token based solutions:

Two-factor authentication support in DirectAccess 2012

Multisite support

Windows Server 2012 DirectAccess supports deployment of multiple DirectAccess entry points across geographic locations. And Windows 8 clients allow users to connect from the internet and access resources within the corporate network in an efficient manner regardless of their physical location. This feature automatically connects clients to the closest DirectAccess server, and supports failover from one entry point to another.

The configuration options below illustrate this feature:

Multisite support

Multisite support

Offline Provisioning of DirectAccess Clients

Prior to Windows Server 2012 , if a DirectAccess enabled remote client would lose its Operating System and would have to reinstall, the only (reasonable) way to get back DirectAccess without coming to the office would be to join the machine via VPN to the Domain after OS Installation. This would require a couple of Manual steps at the end-user side which adds complexity.

With Windows Server 2012, if a remote user's laptop is lost or destroyed, the administrator can send a provisioning package via email to automate the configuration of a replacement computer. This functionality is supplied by the Offline Domain Join (Djoin.exe) utility.

There are a lot of more new features which we cannot cover in one blog post but I will try covering those in in greater detail in later blog posts, including:

  • DirectAccess and RRAS coexistence
  • Built-in NAT64 and DNS64 support for accessing IPv4-only resources
  • Simplified network security policy
  • Load balancing support
  • Network Access Protection (NAP) integration
  • Automated support for force tunneling
  • IP-HTTPS interoperability and performance improvements
  • Manage-out support
  • Support for Server Core
  • Windows PowerShell support
  • User and server status monitoring
  • Accounting and reporting


DirectAccess in Windows Server 2012 takes the Remote Access experience to where no one has gone before. It provides seamless, secure and flexible remote connectivity, with almost no limits. I have been a DirectAccess user for over 4 years and I would never want to go back to old “VPN” days.

Thank you for reading! Please do leave your questions, feedback and comments below!

Comments (5)

  1. Anonymous says:

    Nice write up, you made it easy to grasp well !

  2. Nice blog. Waiting for the next one.

  3. Richard P1 says:

    I'm trying to find a 'simple' way to limit the users that can connect as not all staff need or should have this ability, but still allow all machines to connect as all laptops should be 'phoning home' as needed. An suggestions?

  4. Ravi says:

    Is it possible to change the https port used, say from 443 to 8443 or so and NAT the traffic? this could be either:

    firewall:8443 -> DA server:443  OR

    firewall:8443 -> DA server:8443

  5. Anonymous says:

    The following blog applies to DirectAccess on Windows Server 2012 or Windows Server 2012 R2 and shows

Skip to main content