Update: Microsoft is no longer supporting DirectAccess in Azure. More details here.
Recently I wrote an article for CloudComputingAdmin.com about how to configure a basic test lab in Microsoft Azure using Windows Server 2012 R2. After I completed the article, I decided to investigate whether DirectAccess could be configured successfully in Azure. To begin, I looked through the list of unsupported roles and, unfortunately, DirectAccess is on the list. However, just because it isn’t supported doesn’t mean it won’t work, so I proceeded to set up a Windows Server 2012 R2 DirectAccess server to see what would happen. Based on my experience, I can tell you that it does indeed work. However, I quickly learned why it is not supported. There are a number of things unique to the Azure hosting environment that prevent DirectAccess from working without interruption. Although these challenges might prevent you from using DirectAccess in a production environment in Azure, it is certainly viable for short-term testing and evaluation of DirectAccess in Windows Server 2012 R2. Be advised that not all DirectAccess deployment scenarios can be configured in Azure. For example, it is not possible to configure DirectAccess in a public-facing edge configuration. In fact, Azure virtual machines can have only a single NIC, which limits the deployment model to NAT/DMZ configuration. In addition, broadcast and multicast traffic are not supported in a conventional way in Azure, preventing load-balanced clusters and manage out functionality using ISATAP from working correctly.
Configuring the DirectAccess Server in Azure
Note: The DirectAccess server must be joined to a domain, so the assumption is that you’ve configured at least one domain controller somewhere. It can be located in Azure itself, or on-premises with site-to-site VPN established between the on-premises network and the Azure virtual network. Guidance for deploying a Windows Server 2012 R2 domain controller in Azure can be found here. Guidance for configuring site-to-site VPN to Azure using Windows Server 2012 R2 can be found here.
To begin, provision a Windows Server 2012 R2 virtual machine in Microsoft Azure, and be sure to assign a static IP address to the VM using PowerShell as described here. Once the VM is provisioned and available, join it to your domain, install your certificates, and then install the DirectAccess-VPN role. When you first open the Remote Access management console you’ll receive the following errors:
The server does not comply with some DirectAccess prerequisites.
Resolve all issues before proceeding with DirectAccess deployment.
Warning : One or more network adapters should be configured with a static
IP address. Obtain a static address and assign it to the adapter.
Error: The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is
accepting requests. Consult the logs and documentation for the
WS-Management service running on the destination, most commonly IIS or
WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service:
As long as you’ve configured the VM with a static IP address in Azure you can disregard the warning about static IP address assignment. Static IP address assignment in Azure works effectively like a dynamic IP address reservation which will not change, and is sufficient for our purposes here. To resolve the second error, open an elevated command prompt and enter the following command:
Click on Check prerequisites again and you’ll find that the warning about static IP address assignment still persists, but you can now click Next to proceed with configuring DirectAccess.
In the Azure management portal, note the Public Virtual IP (VIP) address assigned to the VM. Configure public DNS with the hostname you entered when configuring DirectAccess (which is used by clients to connect to the DirectAccess server) to resolve to this IP address.
To configure external access to the VM for DirectAccess clients click Endpoints and click Add. Select the option to Add a standalone endpoint and then select HTTPS and TCP. Accept the defaults of 443 for both the public and private ports.
Provisioning DirectAccess Clients
At this point you should now be able to provision DirectAccess clients. If you’ve configured your DirectAccess lab entirely in Azure, you’ll need to use the offline domain join tool to provision clients. Once you’ve successfully provisioned DirectAccess clients, they should be able to establish connectivity through the DirectAccess server.
Azure DirectAccess Issues
Turning off the DirectAccess virtual machine is when the problems begin. Specifically, stopping the virtual machine and deallocating it, which happens when you choose to shut down the VM via the Azure management portal, tends to break things. However, stopping the DirectAccess server from within the virtual machine itself (using Stop-Computer, shutdown.exe, or the GUI) does not cause any problems, and the DirectAccess server can remain shut down (but not deallocated) for an extended period of time without issue.
When you restart a VM that was previously stopped and deallocated, you may find that the Remote Access management console fails to connect, returning the following error message:
Configuration Load Error
A connection cannot be established to server . Check that the server
is available, the Remote Access role is installed, and that you have
permissions to access the server.
Running winrm quickconfig again restores access to the management console. You’ll notice, however, that DirectAccess is not functioning in spite of the fact that the management console states it is. You’ll also find that there are a number of services in an unknown state.
This happens because the after the VM is restarted after being deallocated, it receives a new virtual NIC. When the system starts, the DirectAccess configuration is not bound to this network interface. To resolve this issue, go to the DirectAccess and VPN Configuration in the management console and click Edit in the Remote Access Server configuration and choose Network Adapters. You’ll see that the adapter connected to the internal or perimeter network is blank. From the drop-down menu, select the network interface and choose Next,Finish, and then apply the configuration once again.
Changes to Public DNS
When the DirectAccess server is deallocated, the public IPv4 address assigned to it is released. If the VM is deallocated for an extended period of time, you will not get your originally assigned public IP address again and a new one is assigned upon restart. You’ll need to update your public DNS record to reflect this change of IP address. It is possible to reserve a public IP address using PowerShell. However, it does require that you reserve the public IP address prior to creating the virtual machine. In addition, you’ll need to create the virtual machine using PowerShell to leverage the reserved public address. As of this writing, reserving public IP addresses is not available through the Azure portal GUI. For more information about reserving public IP addresses in Azure, click here.
Although it is technically possible to configure DirectAccess on Windows Server 2012 R2 hosted in the Microsoft Azure public cloud, it is formally unsupported and there are a number of factors that make its use potentially problematic. It might be possible that future changes could make this better, but for now it does work in some scenarios if you accept the workarounds. Proceed at your own risk!