Cloud Computing

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.


Sponsored Content

Passwords Haven’t Disappeared Yet

123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?


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.

Creating new domain controllers in an Azure availability set [Image Credit: Aidan Finn]
Creating new domain controllers in an Azure availability set [Image Credit: Aidan Finn]
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).

Add a data disk to the Azure domain controller [Image Credit: Aidan Finn]
Add a data disk to the Azure domain controller [Image Credit: Aidan Finn]
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.

The disks of a virtual DC in Azure [Image Credit: Aidan Finn]
The disks of a virtual DC in Azure [Image Credit: Aidan Finn]
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.

Configuring a static IP address for the Azure domain controller [Image Credit: Aidan Finn]
Configuring a static IP address for the Azure domain controller [Image Credit: Aidan Finn]
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:).

Change the AD DS paths to use an Azure data disk [Image Credit: Aidan Finn]
Change the AD DS paths to use an Azure data disk [Image Credit: Aidan Finn]
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.

Ignore the warning about a DHCP configuration in the Azure machine’s guest OS [Image Credit: Aidan Finn]
Ignore the warning about a DHCP configuration in the Azure machine’s guest OS [Image Credit: Aidan Finn]
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).

My simple Azure-based domain’s topology [Image Credit: Aidan Finn]
My simple Azure-based domain’s topology [Image Credit: Aidan Finn]

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.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (2)

2 responses to “Deploy Domain Controllers as Azure Virtual Machines”

  1. <p>Make sure I'm understanding correctly: I've built a VM in azure, created the VPN, joined it to my local domain, promoted it to DC, now I want to remove the IP of my on-premise DC/DNS server, from the Virtual Network DNS settings?? In effect the Virtual Network would only have the Azure VM DC as DNS?</p><p><br></p><p>Would leaving the local DNS on my Vnet config, result in FRS, DFS and group policy replication issues?</p>

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
13 Email Threat Types to Know About Right Now

As email threats evolve and multiply, keeping track of them all—and staying protected against the many different types—becomes a complex challenge. Today, that requires more than just the traditional email gateway solution that used to be good enough.

In this eBook you will learn:

  • What are the most common and challenging email attacks for organizations?
  • How to defend against sophisticated email threats, such as spoofing, social engineering, and fraud
  • How to protect employees at the inbox level with the right technologies and security-awareness training
  • How to use a multilayered protection strategy to reduce susceptibility to email attacks and better defend your business and employees

Sponsored by: