1.2 Domain Controllers in Azure IaaS & Virtualized DC Cloning

Domain Controllers in Azure IaaS & Virtualized DC Cloning

1. Azure IaaS Virtual Machine Domain Controller Best Practices

Deploying Active Directory Domain Controllers onto Azure IaaS Virtual Machines introduces distinct architectural constraints governing virtual networking, storage write caching, and high-availability placement.

+-----------------------------------------------------------------------------+
|                  AZURE IAAS VM DOMAIN CONTROLLER ARCHITECTURE               |
|                                                                             |
|   [AZURE VIRTUAL NETWORK (VNet)]                                            |
|   +---------------------------------------------------------------------+   |
|   |  Subnet: 10.10.1.0/24                                               |   |
|   |                                                                     |   |
|   |  +-----------------------------+   +-----------------------------+  |   |
|   |  | VM: AZ-DC01 (Zone 1)        |   | VM: AZ-DC02 (Zone 2)        |  |   |
|   |  | Azure NIC Private IP:       |   | Azure NIC Private IP:       |  |   |
|   |  | Static = 10.10.1.4          |   | Static = 10.10.1.5          |  |   |
|   |  | (OS Adapter = DHCP!)        |   | (OS Adapter = DHCP!)        |  |   |
|   |  |                             |   |                             |  |   |
|   |  | [OS Disk C:] (Cache: R/W)   |   | [OS Disk C:] (Cache: R/W)   |  |   |
|   |  |                             |   |                             |  |   |
|   |  | [Data Disk F:]              |   | [Data Disk F:]              |  |   |
|   |  | - NTDS.dit & Logs           |   | - NTDS.dit & Logs           |  |   |
|   |  | - Host Caching: NONE        |   | - Host Caching: NONE        |  |   |
|   |  +-----------------------------+   +-----------------------------+  |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Critical Azure IaaS Rules for Domain Controllers:

1. IP Addressing Configuration (The VNet Rule):

   • Azure VNet NIC Level: MUST be configured with Static Private IP Allocation in the Azure portal, Azure CLI, or Bicep/ARM template.
   • Guest OS Level: MUST remain set to Obtain an IP address automatically (DHCP).
   • Why? If an administrator manually assigns a static IP within the Windows Server guest network adapter properties, any change in Azure VNet routing or DHCP lease renewal can cause the VM to lose network connectivity, severing communication with Azure fabric management agents.

2. Disk Layout and Host Write Caching (The Integrity Rule):

   • Dedicated Data Disk: AD DS database (NTDS.dit), transaction logs (edb.log), and SYSVOL must reside on an attached data disk (Standard SSD or Premium SSD), NEVER on the OS disk (C:) or the Azure Temporary Disk (D:).
   • Host Caching Policy: Host Caching on the dedicated AD DS data disk MUST be set to None (or ReadOnly).
   • Why? Azure OS disks have Read/Write host caching enabled by default. If a host crash occurs while writes are buffered in hypervisor host memory, uncommitted transactions are lost, causing Extensible Storage Engine (ESE) database corruption and irreversible Update Sequence Number (USN) rollback.
   • Temporary Disk Prohibition: The Azure temporary disk (D:) is volatile and wiped upon VM resizing, host migration, or deallocation. Storing NTDS or SYSVOL on D: causes immediate domain controller failure upon reboot.

3. Resilience & Availability Architecture:

   • Deploy at least two domain controllers per domain in Azure across distinct Availability Zones (e.g., Zone 1 and Zone 2 in regions that support zones) or within an Availability Set (minimum 2 Fault Domains and 2 Update Domains).
   • Configure the Azure Virtual Network DNS server settings to list the private IP addresses of the Azure domain controllers, with fallbacks to on-premises DNS servers across ExpressRoute or Site-to-Site VPN.

---

2. Domain Controller Virtualization & Cloning (dccloneconfig.xml)

Domain Controller Cloning allows rapid deployment of new virtualized domain controllers by copying an existing virtualized DC's virtual hard disk (VHDX), bypassing the traditional promotion process.

+-----------------------------------------------------------------------------+
|                     VIRTUALIZED DC CLONING WORKFLOW                         |
|                                                                             |
|   [1. SOURCE DC PREREQUISITES]                                              |
|   - Hypervisor supports VM-GenerationID (Hyper-V / Azure)                   |
|   - PDC Emulator online & running Windows Server 2012+                      |
|   - Source DC added to 'Cloneable Domain Controllers' security group        |
|                                 |                                           |
|                                 v                                           |
|   [2. APPLICATION ALLOWLIST]                                                |
|   - Run: Get-ADDCCloningExcludedApplicationList                             |
|   - Generate: New-ADDCCloneConfigFile / CustomDCCloneAllowList.xml          |
|                                 |                                           |
|                                 v                                           |
|   [3. CLONE CONFIGURATION]                                                  |
|   - Author dccloneconfig.xml in %SystemRoot%\NTDS folder                    |
|   - Specify: CloneComputerName, SiteName, IPAddress, SubnetMask, DNS        |
|                                 |                                           |
|                                 v                                           |
|   [4. VM SNAPSHOT / COPY & BOOT]                                            |
|   - Shut down source VM, copy VHDX, create new VM attached to copy          |
|   - Hypervisor presents new VM-GenID -> NTDS detects dccloneconfig.xml      |
|   - DC initializes new invocation ID, resets SID, joins replication topology|
+-----------------------------------------------------------------------------+

Cloning Prerequisites & Artifacts:

• VM-GenerationID (VM-GenID): The hypervisor (Hyper-V Windows Server 2012+ or Azure IaaS) exposes a 128-bit integer via the ACPI table. When a VM is cloned or restored from a snapshot, the hypervisor changes this ID. Active Directory detects the change and safely resets its local invocation ID and discards its RID pool to prevent USN rollback.
• Cloneable Domain Controllers Security Group: The source DC computer object must be added as a member of this built-in domain security group.
• Application Allowlist Files:
  • DefaultDCCloneAllowList.xml: Located in %SystemRoot%\System32, containing Microsoft-tested services and applications safe for cloning.
  • CustomDCCloneAllowList.xml: Located in %SystemRoot%\NTDS, generated via PowerShell to permit third-party services that pass cloning compatibility checks.
• dccloneconfig.xml Syntax:

<configurations>
  <configuration>
    <IPv4Configuration>
      <IPAddress>10.10.1.6</IPAddress>
      <SubnetMask>255.255.255.0</SubnetMask>
      <DefaultGateway>10.10.1.1</DefaultGateway>
      <DNSClient>10.10.1.4</DNSClient>
      <PreferredWINSServer></PreferredWINSServer>
      <AlternateWINSServer></AlternateWINSServer>
    </IPv4Configuration>
    <Position>Top</Position>
    <SiteName>Azure-EastUS</SiteName>
    <ComputerName>AZ-DC03</ComputerName>
  </configuration>
</configurations>

[!CAUTION] Sysprep Prohibition on Domain Controllers: NEVER run sysprep.exe /generalize on a domain controller. Sysprep is completely unsupported on active DCs and corrupts directory databases and machine security identifiers. DC Cloning via dccloneconfig.xml is the only supported image-copy deployment method.

---

3. Upgrading, Demoting, and Metadata Cleanup

When retiring legacy domain controllers or migrating to newer Windows Server versions, administrators must follow structured decommissioning protocols.

Graceful Demotion with PowerShell

To retire a functional domain controller, execute Uninstall-ADDSDomainController:

# Gracefully demote an additional domain controller
$LocalAdminPassword = ConvertTo-SecureString 'LocalAdminP@ss2026!' -AsPlainText -Force

Uninstall-ADDSDomainController `
    -DemoteOperationMasterRole:$true `
    -RemoveDnsDelegation:$true `
    -LocalAdministratorPassword $LocalAdminPassword `
    -Force:$true

Forceful Demotion & Metadata Cleanup

If a domain controller suffers catastrophic hardware failure and cannot be brought online, it must be forcefully demoted and its directory metadata purged:

1. Run Uninstall-ADDSDomainController -ForceRemoval -LocalAdministratorPassword $pwd on the damaged server (if bootable) to strip local AD DS binaries.
2. On a healthy surviving DC, open Active Directory Users and Computers, locate the failed DC under the Domain Controllers OU, and delete the computer object. In Windows Server 2012 and later, deleting the DC object automatically triggers automated metadata cleanup, removing the nTDSSettings object, replication connection objects, and FRS/DFSR references.
3. Verify cleanup in Active Directory Sites and Services under the relevant site's Servers container, and manually delete orphaned DNS SRV records in the _msdcs.<ForestRoot> zone using DNS Manager.