Homelab Build — Part 4 — Domain Controllers

What This Part Covers

Part 1 reserved lab.example.com as the forest name and dc01/dc02 as the domain controller hostnames. Part 3 turned the Servers segment from a row in a table into a real VLAN with a gateway, a DHCP scope, and a firewall rule. Both were preparation. This part is where a domain controller actually exists: dc01 gets promoted first, creating the forest from nothing, and dc02 follows as a second domain controller replicating from the first.

Think of the forest root domain as pouring the foundation of a building. Every part after this one — DNS in Part 5, certificates in Part 7, Group Policy in Part 8 — gets built on top of it. A foundation poured wrong is expensive to fix once walls stand on it; that is exactly why Part 1 spent an entire post on the domain name and addressing scheme before any of this ran.

Why a Second Domain Controller?

A forest with exactly one domain controller works, right up until that one server is unavailable. Every domain-joined machine in the lab — the pfSense box aside — authenticates through Kerberos against a domain controller, resolves names against AD-integrated DNS running on a domain controller, and applies Group Policy from SYSVOL replicated between domain controllers. One DC means all three of those are a single point of failure.

This is also the first part of the series where SYSVOL and the AD database actually replicate between two servers, which makes it the natural place to introduce repadmin and dcdiag — the tools every later troubleshooting post in the Active Directory category assumes are already familiar.

Prerequisites Before Promoting dc01

Both VMs need a static address inside the Servers VLAN’s reserved range before AD DS goes anywhere near them — DHCP addresses are fine for client testing later in this series, but not for domain controllers. dc01 and dc02 both build on a fresh Windows Server 2025 VM on the same Proxmox host from Part 2, attached to the SERVERS VLAN interface pfSense created in Part 3.

# On dc01: assign the static IP and point DNS at pfSense for now —
# this gets replaced with AD-integrated DNS once the forest exists
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.10.10 -PrefixLength 24 -DefaultGateway 10.10.10.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.10.1

# Rename the computer to match Part 1's naming convention, then restart
Rename-Computer -NewName "dc01" -Restart

Creating the Forest — Promoting dc01

With the hostname and static IP set, installing AD DS is a two-step process: add the Windows feature, then run the cmdlet that actually creates the forest. Install-ADDSForest installs and configures the DNS Server service by default, so there is no separate DNS role step here.

# Install the AD DS role and its management tools (dcdiag, ADUC, the ActiveDirectory module)
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# Create the forest root domain — prompts interactively for the DSRM password,
# which is the preferred way to supply it rather than passing plain text
Install-ADDSForest -DomainName "lab.example.com" -DomainNetbiosName "LAB" -InstallDns -DomainMode Win2025 -ForestMode Win2025 -Force

The command reboots the server automatically once installation finishes — leave -NoRebootOnCompletion out, since a domain controller that has finished configuring but hasn’t rebooted does not function correctly as either a member server or a DC.

Verifying dc01

After the reboot, confirm the forest actually exists and dc01 considers itself healthy before touching dc02. These are read-only checks — nothing here changes the domain.

# Confirm dc01 is visible as a domain controller, including global catalog status
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog

# Run the full domain controller health check
dcdiag /v

One detail worth knowing rather than debugging later: with AD-integrated DNS, dc01’s own preferred DNS server address is automatically set to the loopback address 127.0.0.1 once the forest is created, so it always resolves its own zone even if its other IP settings change later.

Adding dc02 as a Second Domain Controller

dc02 starts as a plain workgroup VM — it does not need to be domain-joined first. Install-ADDSDomainController joins the computer to the domain and promotes it in the same operation, provided it can resolve the domain in DNS and has credentials with rights to join it.

# On dc02: assign the static IP, but point DNS at dc01 —
# dc02 has to find the domain in DNS before it can join it
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.10.11 -PrefixLength 24 -DefaultGateway 10.10.10.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.10.10

# Rename to match the naming convention, then restart
Rename-Computer -NewName "dc02" -Restart

# Install the AD DS role — same step as dc01, and required even though dc02 isn't domain-joined yet
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# Join and promote dc02 as an additional domain controller, replicating from dc01
Install-ADDSDomainController -DomainName "lab.example.com" -Credential (Get-Credential -UserName "LAB\Administrator" -Message "Domain Admin credentials for dc02 promotion") -InstallDns -SiteName "Default-First-Site-Name" -Force

-SiteName "Default-First-Site-Name" is explicit here for clarity, but it is also the default: this lab is a single Proxmox host in one location, so both domain controllers land in the same site automatically without needing to touch AD Sites and Services yet. Like dc01, dc02 is a global catalog server by default — nothing here needs -NoGlobalCatalog.

Once dc02 has rebooted and is running its own DNS Server service, update both machines’ DNS client settings so each treats itself as primary and the other as a fallback — this is ordinary operational practice, not something either cmdlet configures automatically:

# On dc01: loopback stays primary, dc02 becomes the fallback
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1,10.10.10.11

# On dc02: its own loopback becomes primary, dc01 becomes the fallback
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1,10.10.10.10

Verifying Replication Between dc01 and dc02

A second domain controller is only useful if it is actually replicating. Run these from either DC once dc02 has rebooted from promotion.

# Show inbound replication status for every partition, from every domain controller
repadmin /showrepl * /csv

# Summarize replication success/failure across the whole forest, sorted by staleness
repadmin /replsummary * /bysrc /bydest /sort:delta

# Run the replication-specific dcdiag test against both DCs
dcdiag /test:Replications /v

# Confirm both domain controllers are now visible, each as its own global catalog
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog

Replication right after a promotion can briefly show a naming context as not yet available while dc02 finishes its initial sync — that is expected and normally clears within a few minutes. A result that stays failed after that is the actual problem, not the initial sync itself.

Ports pfSense Doesn’t Need to Open — Yet

dc01 and dc02 sit on the same SERVERS VLAN, so replication traffic between them never crosses pfSense at all — it stays on the same broadcast domain, and the SERVERS ruleset from Part 3 never evaluates it. That changes the moment a domain controller ends up on a different segment or site, which is worth planning for even though it does not apply yet in this lab.

Domain Controller Promotion Issues

Final Thoughts

Everything before this part was preparation: a plan, a hypervisor, a firewall. This part is where the lab becomes an actual Active Directory environment — a forest that exists, a domain controller that answers Kerberos and LDAP requests, and a second one that means the first can be rebooted without taking the domain down with it.

What’s still missing on purpose: DNS is running with pfSense’s default forwarders and no scavenging configured, and there’s no certificate authority, no Group Policy beyond the defaults, and no file shares. Each of those is a deliberate gap this series fills one part at a time, starting with DNS next.