My Legacy Blogs
With the impending release of Windows Server 2012 we will have our third iteration of the Microsoft DirectAccess solution. Life began with the DirectAccess feature coming to Windows in the first release of Windows Server 2008 R2 a few years ago now; it was then supercharged using Forefront UAG to offer a truly more achievable solution which was much easier to implement for many organisations given the improvements offered by the Forefront UAG platform. Now with the release of Windows Server 2012, we have the third generation of the solution which is fully featured and delivered as part of the native operating system. Given the impending third generation release, I thought it might be useful to prepare a DirectAccess comparison table to compare the different technology versions available, as shown below:
Windows Server 2008 R2 DA
Forefront UAG 2010 SP1 DA
Windows Server 2012 DA
Simplified DirectAccess management for small and medium organisations
Automated DirectAccess server configuration
Mandatory PKI deployment as a DirectAccess prerequisite
Built-in NAT64 and DNS64 support for accessing IPv4-only resources
Support for a DirectAccess server with a single network card
Support for a DirectAccess server behind a NAT device
Requires at least one Windows Server 2008/R2 Domain Controller
Requires at least one Windows Server 2008/R2 DNS Server
Load balancing support
Server fault tolerance
Support for multiple AD domains
Support for OTP (token based authentication)
IP-HTTPS interoperability and performance improvements
Manage-out only support
Support for Server Core
Support for Windows 7 clients
Support for Windows 8 clients
Windows PowerShell support
User and server health monitoring
Accounting and reporting
Notes and small print:
Items in red represent significant improvement or changes.
1PKI is still mandatory for force tunnelling, Network Access Protection (NAP) integration or two-factor authentication deployment scenarios. A PKI-based solution is therefore still required for some enterprise-class deployments, dependent on the required features.
2Hyper-V failover cluster is required.
4IP-HTTPS is supported, but there is a performance overhead due to combined/double SSL and IPsec encryption. IP-HTTPS in Windows Server 2012 now support null SSL encryption and additional optimisations but requires Windows 8 clients.
5Complicated setup due to IPv6 requirements.
6Global Server Load Balancer (GSLB) is required.
7Automatic DirectAccess entry-point detection or user selected entry-point requires Windows 8 clients.
8Technically works, but the supportability status is currently unknown (full support provided in UAG SP3).
10Command line via PowerShell only.
As highlighted above, Windows Server 2012 offers the most feature-rich platform when compared to previous versions and can be considered as a superset of the functionality provided by the Forefront UAG SP1 offering. Many of the enhancements included in Windows Server 2012 DirectAccess are based upon direct feedback from customers and changes to facilitate easier adoption and deployment of the technology within both smaller organisations and enterprise environments alike. I am planning on creating two upcoming blog posts which will highlight the changes and benefits in Windows Server 2012 DirectAccess from the perspective of the smaller organisation and then also for the enterprise space. Given the improvements and changes, I think DirectAccess will be even more popular than ever…what do you think?
Thanks for the blog post. I'm sure Direct Access will become much more popular. We have several customers for whom we have already implemented it on W2012 or at least have it planned.
good stuff - the better VPN
Great comparison table, thanks! Is there anything like this for 2012 vs 2012 R2? Also for the null encryption support for IP-HTTPS, is this done out of the box, or is some configuration required?
@itismeap - 2012/R2 are functionally the same. Null encryption is only available for Win8/8.1 clients and is enabled by default. Win7 clients will continue to double encrypt :( Null encryption is a default part of 2012 and doesn't need to be explicitly enabled
I am configuring the direct access on windows server 2012 r2. I am using the PKI and generated the certificate but at the time of configuring it shows Remote Procedure Failed error and configuration is rolled back. Can you please help us.
Tip for anybody implementing Windows 2012 Direct Access in a cluster (ours was with F5 load balancers and two DA servers in cluster) but this should apply to even NLB deployments -
Some context –
Each DA server in the cluster handles a unique IPv6 prefix for clients, this is basically to eliminate the need for tracking client sessions across cluster members for session persistence. For example one of our servers DA1 would handle fd00:a082:7:1000::/59
and DA2 would handle fd00:a082:7:1001::/59.
When doing failover testing between servers, the client address would appropriately be re-assigned from the right prefix based on the server it failed over to. However, when connecting through DA2, clients would not be able to communicate with corporate network.
Further digging around revealed IPSec tunnels on the client won’t even come up via DA2.
After verifying all the components, I noticed that the tunnel endpoints, configured in the automatically created client GPO, belong to DA1 allocated address prefix. The tunnel endpoints were fd00:a082:7:1000::1 and fd00:a082:7:1000::2. If you look at the client
prefix assigned by DA1 these fall in to the same range. But with DA2 assigned client prefix fd00:a082:7:1001::/59, the tunnel endpoint address is not part of the local subnet. This resulted in the client not being able to initiate IPSec tunnels because it
doesn’t know how to reach the endpoint.
I don’t know if this was overlooked by Microsoft/not properly tested or what, and there are no resources out there explaining this behavior that’s why I decided to save others from the headache.
Now that we know the issue, there are multiple ways to tackle this. And no, advertising the prefix from DA2 did not work. So, I just threw in a quick and dirty fix –
Add a computer startup script via GPO, to add routes for tunnel endpoints with a gateway of DA2 link-local address facing clients (IP-HTTPS interface link-local address of DA2), add a metric of 10 just as a precaution so you don’t interfere with DA1 –
route -p add fd00:a082:7:1000::1/128 fe80::e048:79ef:7946:61e0 metric 10
route -p add fd00:a082:7:1000::2/128 fe80::e048:79ef:7946:61e0 metric 10
With these changes, when the client moves to DA2, above added routes take effect and the client will initiate IPSec tunnels properly. The behavior with DA1 stays the same. In the script, you might want to delete the routes first so you don’t keep adding on
top of the same ones, every time the computer restarts.