Thursday, May 9, 2013

Active Directory in Azure – Step by Step

Ever since Windows Azure Infrastructure Services were announced in preview I keep hearing questions "How to run Active Directory in Azure VM? And then join other computers to it". This article assumes that you already know how install and configure Active Directory Directory Services Role, Promote to Domain Controller, join computers to a Domain, Create and manage Azure Virtual Networks, Create and manage Azure Virtual Machines and add them to Virtual Network.

Disclaimer: Use this solution at your own risk. What I describe here is purely my practical observation and is based on repeatable reproduction. Things might change in the future.

The foundation pillar for my setup is the following (totally mine!) statement: The first Virtual Machine you create into an empty Virtual Network in Windows Azure will get the 4th IP Address in the sub-net range. That means, that if your sub-net address space is, the very first VM to boot into that network will get IP Address The given VM will always get this IP Address across intentional reboots, accidental restarts, system healing (hardware failure and VM re-instantiating) etc., as long as there is no other VM booting while that first one is down.

First, lets create the virtual network. Given the knowledge from my foundation pillar, I will create a virtual network with two separate addressing spaces! One addressing space would be This will be the addressing space for my Active Directory and Domain Controller. Second one will be Here I will add my client machines.

Next is one of the the most important parts – assign DNS server for my Virtual Network. I will set the IP Address of my DNS server to! This is because I know (assume) the following:

  • The very first machine in a sub-network will always get the 4th IP address from the allocated pool;
  • I will place only my AD/DC/DNS server in my AD Designated network;

Now divide the network into address spaces as described and define the subnets. I use the following network configuration which you can import directly (however please note that you must have already created the AffinityGroup referred in the network configuration! Otherwise network creation will fail):

<DnsServer name="NS" IPAddress="" />
<VirtualNetworkSite name="My-AD-VNet" AffinityGroup="[Use Existing Affinity Group Name]">
<Subnet name="ADDC">
<Subnet name="Clients">

Now create new VM from gallery – picking up your favorite OS Image. Assign it to sub-net ADDC. Wait to be provisioned. RDP to it. Add AD Directory Services server role. Configure AD. Add DNS server role (this will be required by the AD Role). Ignore the warning that DNS server requires fixed IP Address. Do not change network card settings! Configure everything, restart when asked. Promote computer to Domain Controller. VoilĂ ! Now I have a fully operations AD DS + DC.

Let's add some clients to it. Create a new VM from gallery. When prompted, add it to the Clients sub-net. When everything is ready and provisioned, log-in to the VM (RDP). Change the system settings – Join a domain. Enter your configured domain name. Enter domain administrator account when prompted. Restart when prompted. VoilĂ ! Now my new VM is joined to my domain.

Why it works? Because I have:

  • Defined DNS address for my Virtual Network to have IP Address of

  • Created dedicated Address Space for my AD/DC which is

  • Placed my AD/DC designated VM in its dedicated address space

  • Created dedicated Address Space for client VMs, which does not overlap with AD/DC designated Address Space

  • I put client VMs only in designated Address Space (sub-net) and never put them in the sub-net of AD/DC

Of course you will get same result if with a single Address Space and two sub-nets. Being careful how you configure the DNS for the Virtual Network and which sub-net you put your AD and your Client VMs in.

This scenario is validated, replayed, reproduced tens of times, and is being used in production environments in Windows Azure. However – use it at your own risk.


Imperfect IT said...

Great stuff Anton! Is the reason you create another address range for the client machines that you don't want to risk a client machine grabbing the DC address? Much appreciated.

Anton Staykov said...

One of the reasons for new address space is to avoid client machines grabbing the in case DC is temporary down. The other is security isolation - much easier to maintain security and firewall rules when I have separate address spaces, rather then just a subnet within same address space.

Kalyan Krishna said...

Hi Anton, Great timing and very good stuff. As of now I am doing exactly the same thing and after a few tries (and a few attempts at creating AD VMs) I had realized that needs to be set up as the preferred DNS server in the VNet config before any compute resources is assigned to my VNet.
While everything else works fine, one problem I see is that DNS always fails to resolve any domains that belong to MS Azure properties, like *, *, * and such. Have you faced a similar issues yourself? Any hints on what might be wrong?

FlyingDutchman said...

Thanks for this article Anton. I'm running into an issue where I can't create the Domain Controller VM within a virtual network as you describe because of the following :
Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region.

Furthermore - could you have multiple DCs for high availability?

FlyingDutchman said...

Please rescind my last comment, the issue I was running into had nothing to do with your article!

If I can, I would still like to ask you about high availability: is it possible to install a second domain controller?

Anton Staykov said...

As for creating multiple DC for high availability - there is no technical issue to stop from deploying more than one DC. I would just put both in their own designated sub-nets. To be absolute sure about both IP addresses.

As for unable to resolve MSFT (Microsoft) propriety domains - this is known issue which happens under certain circumstances and hopefully there will be a fix soon for it. The workaround is to use FQDN when navigating to such site. Please note that FQDN includes a trailing dot at the end of the domain name (i.e. and not just )!