Deploy Domain Controllers as Azure Virtual Machines

This guide will show you how to deploy an Azure virtual machine as a domain controller (DC).

Extending Your Domain

There are many reasons why you would extend your existing domain into the cloud, including:

• Single sign-on: Enable hybrid applications to work within a single Active Directory (AD) forest.
• Disaster recovery: Have your domain already running when failing over application/data workloads to the cloud.
• ADFS: Federate your forest to Azure AD using machines in the cloud, eliminating Internet connectivity at the office as a single point of failure for SaaS apps.

 

 
To extend an existing domain you will need:

• Site-to-site networking: You must have either VPN or ExpressRoute connectivity (with routing configured) from your on-premises network (including the VLANs with active DCs) to your Azure virtual network (VNet) that will host your new in-Azure DCs.
• Temporarily edit the DNS settings of the VNet: The new in-Azure DCs will need to find your existing domain, which requires DNS. Edit the settings of the VNet and temporarily use the IP addresses of some on-premises DCs as the DNS servers of your VNet – you will need to undo this after the successful promotion of your in-Azure DCs.

Afterwards, you will use AD Sites and Services to create:

• An AD site for your AD deployment in that VNet or Azure region.
• Subnet definitions for the VNets that will contain domain members.
• Associate the subnets with your AD site.
• Create one or more site links to mimic your replication paths (site-to-site network connections) from the on-premises domain controllers.

Specify Your Domain Controller Virtual Machines

For all but the Fortune 1000s, DCs are usually lightweight machines that do nothing other than DNS, authentication, and authorization. For this reason, I go with the cheapest option for virtual machines in Azure, the Basic A-series. The 300 IOPS for a data disk limit doesn’t impact AD performance, and the lack of load balancer support (NAT rules for RDP and load balancing rules) doesn’t hurt either because domain controllers shouldn’t be visible on the Internet.
The sizing of the machines depends on the memory requirements. In my small deployments, I’ve opted for a Basic A2 (to run Azure AD Connect for small labs or businesses) and a Basic A1 as the alternative machine; memory requirements for Azure AD Connect depend on the number of users being replicated to Azure AD.
Larger businesses should use empirical data on resource utilization of their DCs to size Azure virtual machines. Maybe an F-Series, or a Dv2-Series would suit, or in extreme scenarios, maybe they’ll need “S” machines that support Premium Storage (SSD) accounts for data disks.

Building the Domain Controller

There are a couple of things to consider when deploying a new Azure virtual machine that will be a DC. You should deploy at least 2 DCs. To keep your domain highly available, during localized faults or planned maintenance, create the machines in an availability set. Note that Azure Resource Manager (ARM) currently won’t allow you to add a virtual machine to an availability set after creating the machine.

You must store all AD Directory Services (DS) files on a non-caching data disk to be supported and to avoid USN rollbacks. Once the machine is created, open the settings of the machine in the Azure Portal, browse to Disks, and click Attach New.

Give the disk a name that is informative, size the disk, and make sure that host caching is disabled (to avoid problems and to be supported).
Once the machine is deployed, log into it and launch Disk Management. Bring the new data disk online and format the new disk with an NTFS volume.
Note that Standard Storage (HDD) accounts only charge you for data stored within the virtual hard disk, not for the size of the disk. Azure Backup does charge an instance fee based on the total size of disks, but going from 137GB (the OS disk) to 237GB (with a 100GB data disk) won’t increase this fee (the price band is 50-500GB).

Static IP Address

A DC must have a static IP address. Do not edit the IP configuration of the virtual machine in the guest OS. Bad things will happen and careers will be shortened. Ignore any errors you’ll see later about DHCP configurations; your virtual machine will have a static IP address, but using the method that is supported in Azure.
Using the Azure Portal, identify the NIC of your DC and edit its settings. Browse to IP Configurations. Click the IP Configuration; here you’ll see the Azure-assigned IP configuration of this NIC. Change the assignment from Dynamic to Static. You can reuse the already assigned IP address or you can enter a new (unused) one that is valid for the subnet. Not the IP address for later.

Configuring a static IP address for the Azure domain controller [Image Credit: Aidan Finn]

Virtual Network DNS

AD admins know now that things can vary. If your first DC in Azure is joining an on-premises domain, then you will:

1. Temporarily configure the VNet to use the IP addresses of 1 or more on-premises DCs as DNS server.
2. Perform the first DC promotion.
3. Reset the VNet DNS settings to use the in-Azure DCs as DNS servers.

In this lab, I’m building a new/isolated domain, so I will simply edit the DNS settings of the VNet to use the new static IP address of my DC virtual machine.
Open the settings of the virtual network and browse to DNS Servers. Change the option from Default (Azure-Provided) to Custom, and enter the IP address(es) of the machine(s) that will be your DCs.

This option, along with the default gateway of the subnet and the static IP address of the machine’s NIC, will form the static IP configuration of your DC(s).

Promote the Domain Controller

Log into your DC, add the Active Directory Domain Services (AD DS) role, and start the DC promotion. Continue as normal until you get to the Paths screen; this is where you will instruct the AD DS configuration wizard to store the AD files on the data disk (F: in this case) instead of the %systemroot% (normally C:).

Complete the wizard. You will see a warning in the Prerequisites Check screen, and probably later in the event logs about the DC having a DHCP configuration – remember that the guest OS must be left with a DHCP configuration, and you have configured a static IP configuration in the Azure fabric.
You can complete the wizard to get your DC functional.
If you are extending your on-premises domain, remember to change the DNS settings of your VNet after verifying in Event Viewer that the DC is fully active after a first complete sync of the AD databases and SYSVOL.

Active Directory Sites and Services

The final step in the build process is to ensure that the Active Directory topology is modified or up-to-date. New subnets (the network address of your virtual network) should be added to AD in Active Directory Sites and Services. Sites should be created and the subnets should be added to those sites. And new IP inter-site transports should be added to take control of replication paths and intervals between any on-premises sites and your in-Azure site(s).

As usual, make sure that you test AD and SysVol replication between and inside of sites, verify that DNS is running, and that the AD replication logs are clear.