A domain controller (DC) is a Windows Server that holds a writable or read-only copy of the Active Directory Domain Services (AD DS) database, authenticates users and computers with Kerberos, and replicates changes with other DCs. Almost everything else in a Windows environment depends on DCs being healthy, so how you deploy them matters. Deployment is a two-step process: first you install the role binaries with Install-WindowsFeature AD-Domain-Services -IncludeManagementTools, then you promote the server, which creates or joins a domain.
Promotion uses one of three PowerShell cmdlets from the ADDSDeployment module. Install-ADDSForest creates a brand-new forest and its first (root) domain; you supply -DomainName, -DomainNetbiosName, forest and domain modes, and a Directory Services Restore Mode (DSRM) password. Install-ADDSDomainController adds another DC to an existing domain, which is how you get redundancy. Install-ADDSDomain creates a new child or tree domain in an existing forest. Each cmdlet has a Test- twin (for example Test-ADDSDomainControllerInstallation) that runs the prerequisite checks without changing anything, and Server Manager's wizard can export the exact PowerShell it would run.
Install from media (IFM) solves a bandwidth problem. A new DC normally pulls the whole database over the network during its first replication. With IFM you run ntdsutil on an existing DC (activate instance ntds, ifm, create sysvol full C:\IFM) to produce a copy of the database and SYSVOL, carry it to the remote site, and promote with -InstallationMediaPath. Only changes made since the media was created then replicate across the WAN. Media from a writable DC can build a writable DC or an RODC; media created as RODC media can only build an RODC. Treat IFM media as highly sensitive, because it contains password hashes.
A read-only domain controller (RODC) is designed for branch offices with weak physical security. It holds a read-only copy of the directory, does not cache passwords by default, and only caches credentials for accounts you allow in its Password Replication Policy (the Allowed and Denied RODC Password Replication Groups). You can delegate local administration of an RODC to a branch technician without making them a Domain Admin. Before you can add the first RODC, the forest must have a writable DC running a supported OS, and historically you needed adprep /rodcprep; modern promotion runs the required preparation automatically.
Running DCs as Azure virtual machines extends your domain into the cloud, but Azure has specific rules. Give the VM a static private IP address on its network interface (NIC) in Azure, not inside the guest OS; the guest keeps using DHCP and Azure always hands it the same address. Point the virtual network's DNS servers at your DCs. Put the AD database (NTDS.dit), logs and SYSVOL on a separate managed data disk with host caching set to None, because the OS disk uses write caching, which can let AD believe data is written when it is not and risk corruption. Spread DCs across availability zones or an availability set, and define an AD site for the Azure subnet.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName corp.contoso.com -InstallDns `
-DatabasePath F:\NTDS -LogPath F:\NTDS -SysvolPath F:\SYSVOL `
-Credential (Get-Credential)Key terms
- DSRM
- Directory Services Restore Mode: a special boot mode for offline AD maintenance, protected by a local password set during promotion.
- IFM
- Install from media: promoting a DC from an ntdsutil-created copy of the database so initial replication does not cross the WAN.
- RODC
- Read-only domain controller: holds a read-only directory copy and caches only passwords allowed by its Password Replication Policy.
- Password Replication Policy
- The allow and deny lists that decide which accounts' credentials an RODC may cache.
- Host caching
- An Azure disk setting (None, ReadOnly, ReadWrite); DC data disks holding NTDS should use None.
A retailer adds a DC at a store with a slow link. The admin runs ntdsutil IFM on a hub DC, ships the encrypted media on a USB drive, and promotes an RODC with -InstallationMediaPath. Only a few megabytes of recent changes replicate, and only the store staff's passwords are cached locally.
Check yourself
Which cmdlet creates the first DC of a new forest, and which adds a DC to an existing domain?
Install-ADDSForest creates a new forest; Install-ADDSDomainController adds a DC to an existing domain.
Why should NTDS.dit on an Azure VM live on a data disk with host caching set to None?
The OS disk uses write-back caching, which can break AD's assumption that writes are durable and risks database corruption; a data disk with caching None avoids that.
What limits which user passwords an RODC stores?
Its Password Replication Policy, managed through the Allowed and Denied RODC Password Replication Groups and per-RODC settings.