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.
ewsch
/ December 5, 2012Hello,
I have a question to that:
Do you know if it is possible to use the Simplified Deployment in an existing environment with PKI (her MS CA) for fast testing the WIN8 and DA Functionality AND after testing then use the Remote Access Setup Wizard to integrate in a custom scenario with the MS CA and further IPv6 setup with unicast local Addresses ?
Regards Ewald
Richard Hicks
/ December 5, 2012No, it is not. The Simplified Deployment model uses self-signed certificates by default. You can change that after the fact, but I’d recommend running the Remote Access Setup Wizard from within the Remote Access Management console and using custom settings.
RichardP
/ December 6, 2012By preference we don’t run Windows firewall on the domain, only when off the domain. This setting applies to clients and servers. Will this prevent Direct Access from working?
Richard Hicks
/ December 6, 2012Yes, it certainly will. DirectAccess in Windows Server 2012 leverages the connection security rules in the Windows Firewall with Advanced Security to create the DirectAccess IPsec tunnels. DirectAccess won’t function without it.
ChrisH
/ December 14, 2012Richard – we also run with Windows firewall turned off when on the domain network and my test install of DirectAccess12 was failing with IPSec errors as a result. I created a new GPO to enable the firewall and added the Directaccess server to it and everything is working fine now.
RichardP
/ December 17, 2012I second that now it’s implemented – provided the DirectAccess server itself can still run it’s own Windows firewall (simple exclusion in our Firewall GPO),and the clients DO run a firewall when NOT on the domain, this all works stunningly well.
The hard bit now is how to limit logon access to certain users only (but I still want all machines connecting for management purposes)
Joe
/ January 16, 2013The only way I could get the remote access server to provide NAT for the internal clients was by removing the configuration, starting RRAS management, and configuring RRAS as I would in Windows 2008. If I started the Remote Access wizard and went beyond the first page my internal clients would lose access, i.e. NAT would stop working. Then I had to remove the Remote Access config, redo RRAS, and reboot the server.
How could this possibly be the intended behavior?
Richard Hicks
/ January 18, 2013To make sure I understand your deployment scenario completely, are you attempting to use a single system to provide outbound NAT to the Internet and DirectAccess remote access?
Joe
/ January 20, 2013yes, I want one remote access server
Richard Hicks
/ January 29, 2013I’m not sure that’s a supported scenario. I’ve certainly never configured a DirectAccess server with NAT for Internet access. When I get somet time I’ll test that in the lab and post the results here.
Joe
/ February 6, 2013the question is, why does the wizard allow me to do something that is unsupported/can’t possibly work? seems like it should tell me to choose one or the other or explain how I “should” be doing things
Richard Hicks
/ February 6, 2013To be clear, I’m not certain that the scenario is unsupported. That’s just conjecture on my part since I haven’t had time to test that configuration myself. That said, I’ve encountered situations where unsupported configurations were indeed configurable using the native tools, without complaint. 🙂
Mr
/ April 14, 2013On Server 2012 Essentials, I used the Remote Access Setup Wizard from within the Remote Access Management console; when it finished things are working (except the SSTP from win 7 so far).
However, every time I open the console now it can’t load my configuration settings and it blames it on a cmdlet. Any ideas on how to get my current configuration to load in the wizard? I can’t even edit the DHCP range for external users from RRAS anymore– it tells me to go to that configuration page.
My main frustration for this is that we’re a small operation and I work remotely (multiple states away). To set up the server, I VPNed into an existing server to configure it, then did a changeover on the router to forward the VPN protocols to the new server. I don’t have the option to blow away the current configuration and try again.
Thanks
Richard Hicks
/ April 24, 2013I don’t have any experience using Windows Server 2012 Essentials. Not sure what the trouble is, but it sounds like some components might be missing. I’m not sure what can be done outside of removing and reinstalling the remote access role. Obviously in your situation being remote that poses a bit of a challenge.
Cory
/ August 15, 2013Richard,
I am trying to plan for a DA project with 2012; however, I have to support several applications thru DA. Is there a list of unsopported applications?
Thanks
Richard Hicks
/ August 19, 2013Hi Cory,
The only documented list of problematic applications I’m aware of is on Jason Jones’ blog here:
http://blog.msedge.org.uk/2010/11/uag-directaccess-application.html
Hope that helps!