Last Update: Sep 04, 2024 | Published: Dec 16, 2016
This guide will show you how to deploy an Azure virtual machine as a domain controller (DC).
There are many reasons why you would extend your existing domain into the cloud, including:
To extend an existing domain you will need:
Afterwards, you will use AD Sites and Services to create:
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.
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).
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]
AD admins know now that things can vary. If your first DC in Azure is joining an on-premises domain, then you will:
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).
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.
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.