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.

Note: Self-signed certificates are used when configuring DirectAccess using the Getting Started Wizard. These certificates expire 5 years after the date of installation. To renew these certificates please refer to the article Renew DirectAccess Self-Signed Certificates.