Windows Server 2012 DirectAccess Simplified Deployment Limitations

A lot has been written about the new capabilities of DirectAccess in Windows Server 2012. One of the most talked about features is the new Simplified Deployment model for DirectAccess. In this deployment scenario, once an administrator installs the Remote Access role and supporting features it can be configured with just three mouse clicks. That’s it! Does that sound too good to be true? In some instances, perhaps it is. Although this simplified deployment model is, well, very simple, it does have some limitations. Before we discuss those limitations, let’s examine specifically what the simplified DirectAccess deployment model entails.

After installing the Remote Access role using the Windows Server 2012 server manager or PowerShell, the administrator is prompted to complete post-deployment configuration. After launching the Configure Remote Access Getting Started Wizard you can choose to deploy DirectAccess, VPN, or both. Selecting Deploy DirectAccess only (first click) allows you to choose your network topology configuration (edge, perimeter, single or multiple network adapters) and enter the name or IP address that clients will use to connect to the remote access server (second click). After that, click Finish to save and apply the configuration settings (third click). That’s it! You’ve configured DirectAccess!

So, what does the configuration wizard do? First, it creates the Group Policy Objects (GPOs) to apply all of the DirectAccess-related settings to the DirectAccess server and clients. This includes information for configuring the DirectAccess client’s Windows Firewall with Advanced Security (WFAS) used to establish DirectAccess IPsec tunnels, such as the external IP address or hostname used to reach the DirectAccess gateway, and internal namespace information for use by the Name Resolution Policy Table (NRPT). By default it will configure settings to apply all mobile computers in the Domain Computers security group. The DirectAccess deployment wizard will also configure the DirectAccess server to host the Network Location Server (NLS) to be used by DirectAccess clients to determine corporate network connectivity. It will also generate a self-signed certificate for use by the IP-HTTPS listener, which is used by DirectAccess clients using the IP-HTTPS transition protocol. In addition, DNS64 and NAT64, the protocol translators that are used to enable DirectAccess clients (which communicate using IPv6 exclusively) to communicate with IPv4-only hosts, are configured and enabled on the DirectAccess server.

One of the main advantages to using this simplified deployment model for DirectAccess in Windows Server 2012 are the reduced infrastructure requirements. The simplified deployment model for Windows Server 2012 DirectAccess does not require a Public Key Infrastructure (PKI) and eliminates the need for IPv6 to be deployed on your Intranet. The simplified DirectAccess deployment model also removes the requirement for two consecutive public IPv4 addresses, now allowing the DirectAccess server to be deployed in a perimeter network behind an existing border router or edge firewall performing Network Address Translation (NAT). Deploying the DirectAccess server with a single network interface is also supported in the simplified deployment model.

As I mentioned earlier there are some limitations imposed when implementing Windows Server 2012 DirectAccess using the simplified deployment model. For example, simplified deployment supports only Windows 8 clients. If you need to support Windows 7 clients for DirectAccess on Windows Server 2012, the simplified deployment model won’t work. In addition the simplified deployment model does not provide support for multi-site configurations, forced tunneling, or strong authentication via smartcard, certificate, or One-Time Password (OTP). NAP integration is also not supported in the simplified deployment model. If any of these are requirements for your organization, the simplified deployment model isn’t for you.

By default the DirectAccess Getting Started Wizard will configure DirectAccess using the simplified deployment model. If you need to deploy DirectAccess to support any of the scenarios for which the simplified deployment model doesn’t support, then DO NOT click the Open the Getting Started Wizard link in the Post-deployment Configuration window.

Instead, in the Server Manager select Tools and then Remote Access Management and click the Run the Remote Access Setup Wizard link.

The Remote Access Setup Wizard can then be used to configure DirectAccess with custom settings to meet your specific requirements, such as enabling forced tunneling, configuring strong authentication, defining the use of an internal PKI, extending support to Windows 7 clients, leveraging a dedicated internal web server for the Network Location Server (NLS), or configuring NAP integration.

Microsoft Windows 8 and Windows Server 2012 VPN Compatibility and Interoperability

Implementing client-based remote access or site-to-site VPN with Windows 8 or Windows Server 2012? Then you’ll definitely want to review the latest Windows 8 and Windows Server 2012 Compatibility and Interoperability document. This document outlines the application compatibility of many third-party VPN clients such as Cisco, Citrix, Juniper, Sonicwall and others running on Windows 8 or Windows Server 2012. It also provides compatibility information for third-party remote access VPN clients and supported site-to-site VPN settings when connecting to Windows Server 2012 Remote Access Server (RAS) VPN.

You can download the Windows 8 and Windows Server 2012 VPN Compatibility and Interoperability document here.

Cannot Connect a DirectAccess Client to a Corporate Network in Windows 8 or Windows Server 2012

Microsoft has released a hotfix to address an issue where a DirectAccess client fails to connect to a corporate network using Windows 8 or Windows Server 2012. The issue can occur when you deploy DirectAccess in single tunnel mode with Network Access Protection (NAP) integration enabled. The hotfix to resolve this issue can be downloaded here.

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.

%d bloggers like this: