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: "winrm quickconfig".
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:
winrm quickconfig
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.
Summary
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!
Peter Selch Dahl
/ August 20, 2014Hi Richard,
Did you try using the Microsoft Azure Internal Load Balancer as an alternative to Microsoft Windows Load Balancer?
http://azure.microsoft.com/blog/2014/05/20/internal-load-balancing/
Richard Hicks
/ August 21, 2014No, but it would probably work…at least within the current support boundaries, which is officially “unsupported”. 😉
Engineering IT
/ September 1, 2014Also IPv6 doesn’t work in Azure, so manage-out will be an issue.
Richard Hicks
/ September 8, 2014Correct. Let’s hope they add support for IPv6 in the near future. 🙂
Markus Quint
/ September 15, 2014Hi Richard,
I am a little bit confused about the Azure DirectAccess configuration:
All machines in Azure:
One DC with DNS, DHCP, AD
One DirectAccess server with IIS, PKI,
What is with the Network Location Server? Do I have to install a seperate server for this, or can I do that over the DirectAccess server?
Can you get me a feedback via email, that would be great.
Thanks
Regards Markus
Richard Hicks
/ September 15, 2014DHCP doesn’t work in Azure, so you can safely eliminate that role from your server. If you’ve got PKI collocated on the DirectAccess server, I’d strongly discourage that. The Network Location Server (NLS) is used by DirectAccess clients for inside/outside detection. You can collocate it on the DirectAccess server, but it is not recommended. In Azure, collocating the NLS on the DirectAccess server brings a unique set of challenges, so it is much easier to create a separate VM for the NLS.
Markus Quint
/ September 15, 2014Hi Richard,
thanks fort he reply.
Do you have a documentation aboute installion NLS on Azure?
Thanks
Regards Markus
Richard Hicks
/ September 19, 2014No, I don’t. Since it’s not supported, I’m sure you won’t find any. 😉 However, NLS is pretty straightforward. It’s just a web server with an SSL certificate. It should also have it’s firewall configured to allow ICMPv4 inbound from the DirectAccess server. That’s it!
Michael
/ December 9, 2015Interested to know if you’ve revisited this with the new ARM portal? Multiple NICs support has been added, yes?
Richard M. Hicks
/ December 11, 2015Oh yes, much has changed in Azure since I wrote this post. Multiple NICs are now supported, and configuring them along with static IP address assignment is much easier now with the new portal. 🙂
Chris
/ April 14, 2016Although I realise DA is still not supported in Azure, I’m trying to configure a DA cluster (I already got it working with a single DA server). The problem I’m having is that you can’t enable clustering if the external NIC of the DA server is DHCP enabled. I also know that changing the ipconfig inside the VM is a bad idea in Azure. Is there any way to disable the check for DHCP on the nic when enabling clustering? Or perhaps I can temporarily fix the IP inside the guest while setting up the cluster and then switch it back to DHCP once the cluster’s built?
Richard M. Hicks
/ April 23, 2016You can certainly try setting a static IP address on the NIC just for the purposes of enabling clustering to see what happens. Also, hope you’re not using NLB. 🙂
Chris
/ April 27, 2016Thanks for the reply, not NLB, no. I did the fixed IP thing and it got past the initial error but then pretty much trashed the Azure VM when the wizard ran (lost all access to it as it flipped the IP addresses around).
On another tack, I’m presuming Windows 7 clients must be ‘homed’ to a specific DA installation because of the DTEs configured in its registry? That is, it won’t connect to a DA system with different DTEs?
If I can’t actually run the clustering wizard on the DA servers in Azure, I’m thinking I can setup 2 separate servers but then fudge one of them so its DTEs are the same as the other server’s. That way, whichever DA server the external LB sends the client to, it’ll be happy.
Or am I barking up the wrong tree?
Thanks
Richard M. Hicks
/ April 27, 2016If you can do that, I don’t see why it wouldn’t work. 🙂