Feed on

With the combination of NAT’ed DirectAccess deployments in Windows Server 2012 and the possibility to deploy Virtual Machines in Azure it is now finally possible to put the DirectAccess node in Azure and still allow your clients to reach corporate resources.

This post is a technical breakdown on the steps you need to do to get your DirectAccess setup up and running in Azure while at the same time bringing up the not so always obvious choices you need to do to get a stable and userfriendly deployment up and running.

There is of course a lot of different steps involved in this, a few things should already have been configured

  1. You must have a valid Azure account where you can create Virtual Machines.
  2. You must have designed your Azure Network Infrastructure.
  3. You must have configured a connection between your Corporate Network and your Azure network.

Note: For detailed instructions on setting up the Network infrastructure in Azure and the connection between CorpNet and AzureNet please read Extending your private cloud to Azure

Step 1 – Create your VM in Azure

  • Create a Windows Server 2012 VM
    Make sure you assign it to your AzureLAN when deploying it. (It is not possible to move VMs as long as the portal is in Preview mode)
    Check the separate post Create VM in Azure – Step by Step for detailed screenshots on creating a VM in Azure.
  • Domain join the machine and make sure it has full connectivity to and from CorpNet.

Step 2 – Go through the DirectAccess prequisites.

  • Reconfigure the VM so that it has a static IP. (Skip this step! Currently not supported and have made the VM unreachable!)
  • Verify that the IP Subnet used in AzureNet is added to a AD Site.
    My suggestion is that you create a new AD Site so you will be able to deploy certain core resources in Azure further down the line.
  • Create a DNS record for IPHTTPS in the external DNS
    (Important: It does not have to be related to your regular domainnames, in my examples I often use da.nrpt.se even though the domain is LAB.local)
  • Aquire (Generate or Buy) a certificate for the IPHTTPS DNS record above and install it in the Computer Store on your DA server
  • Deploy a NLS webserver in CorpNet.
    This is one of the most important steps in a DA deployment! If a client is unable to reach this server it will consider itself to be connected externally and try to activate DA.
    So this server needs to be placed on CorpNet in case of a failure in the connection between AzureNet and CorpNet.
  • If manage-out is needed, setup an alternative ISATAP DNS record and a GPO to deploy it to those clients and servers that need manage-out.
    (For information on how to do it check the post “Limiting ISATAP Services…” by Jason Jones)

Step 3 – Configure Azure specific settings

  • Delete the RDP endpoint
    (You can always recreate it from the webgui if you need it later)
  • Create an endpoint for IPHTTPS that forwards TCP port 443 to the DA VM.
    After the setup you should have something similar to the screenshot below.

Step 4 – Configure DirectAccess on DA01

  • Start by adding the URA role
  • Run the Configuration Wizard to get an initial setup
  • (Optional) Rename GPOs to match the Corporate naming standard
  • Create and use a security group to limit which clients the settings should apply to.
  • Select if you want to use Machine certificate authentication or Kerberos proxying.
    This depends on if you want Windows 8 clients only or a mix of Windows 7 and Windows 8 clients.
    Make this decision NOW and be sure to select the correct alternative so you dpnt have to bring clients into the office again to be able to apply the modified GPOs!
  • Add the DNS suffixes/domains that should be resolved internally to the NRPT list.
  • Design your probes
    The setup will automatically create a webprobe on the DA server but make sure you also add additional probe(s) on CorpNet to help you troubleshoot where the problem lies.
    This way you will be able to see in the DCA/NCA logfile if the problem lies between the client and the DA server or somewhere further into the network (internal routing or the connection between CorpNet and AzureNet)
  • Verify that the DA server has the Windows Firewall enabled when the Domain Profile is enabled!
    (With the fact that your DA server actually is on the corporate network it will actually have the Domain profile active, something that is often missed!)

Step 5 – Test the setup

With all the extra aspects of this deployment scenario I strongly suggest that you include some extra tests early in your PoC. Some of the things I suggest you test is listed below:

  • How will onsite clients react when the NLS goes offline?
  • What happens to DA connected client if the connection between CorpNet and Azure goes down?


Some Azure specific questions..

  • How do I find the external IP in the Azure portal?
    Open the Dashboard for your VM and look at the “quick glanze” section down to the right. There you will see “PUBLIC VIRTUAL IP ADDRESS (VIP)”
  • How do I move the VM to the correct LAN in Azure?
    It is currently not possible to move a deployed VM between networks in Azure, according to various comments and forumposts till feature will be available when the new portal is completed and generally available.
    Sadly, the only workaround available today is to delete the machine and redeploy it on the correct network.

The next steps…

Even though you now should have a relatively simple DA setup online and running in Azure it is always important to look forward..

  • What happens when the Corporate internet connection goes down?
  • What will DirectAccess users require you to have available in Azure?
    Additional domaincontrollers?
  • Should you deploy a Domaincontroller in Azure to speed up AD queries and to make sure that your clients can connect when the connection between AzureNet and CorpNet is down?
  • Is there a requirement for any other systems or functionality to be present in Azure?

3 Responses to “Deploying DirectAccess in Azure”

  1. daniel says:

    Is Static IP… support in Azure?
    If you turn on static ip in azure the gateway stop comunicate outside the LAN

  2. Jonas Blom says:

    Hi daniel,
    You are correct, I did some checking and NO, statically configured IPs are not supported in Azure. Since I’ve recreated various scenarios in my Azure setup since I wrote this post, I reran my setup and ended up with the same issues that you have above. I’ll update to post reflect this…
    (Based on various comments it seems that Azure uses the DHCP information to maintain external connectivity)

  3. [...] interesting, however, because numerous blogs have outlined how they have gotten the functionality working already. And more importantly, perhaps the biggest downer, is that only Windows 8 Enterprise has [...]

Leave a Reply


Get every new post delivered to your Inbox

Join other followers: