Treat a controller refresh as an identity program, not a hardware swap.

Start by defining exactly which domain controllers are being replaced, which roles they hold, which sites they serve, and what evidence must exist before any old controller can be retired.

Runbook note: Keep at least one known-good legacy controller online in each critical site until replication, DNS, and time hierarchy validation pass on the 2025 nodes.

• Inventory FSMO ownership, Global Catalog placement, DNS hosting, NTP source hierarchy, DHCP helper targets, and every application pinned to a controller hostname or IP.
• Capture current site, subnet, and replication-topology data so the new hardware inherits the right placement instead of creating accidental cross-site referrals.
• Define rollback triggers in plain operational terms: failed logons, broken SRV registration, replication queue growth, or loss of authoritative time.
• Take system-state backups of existing domain controllers and verify recovery operators can access them before promotion work begins.

Command path:

• Get-ADDomainController -Filter * | Select HostName,Site,IsGlobalCatalog,OperationMasterRoles
• netdom query fsmo
• repadmin /replsummary
• dcdiag /e /c /v /f:dcdiag-baseline.txt
• w32tm /query /status

GUI path: Server Manager > Tools > Active Directory Users and Computers, Active Directory Sites and Services, DNS, and Event Viewer to document current ownership and site placement.

Build clean controller candidates before AD DS is introduced.

The new servers should already have fixed addressing, correct time, hardened baseline settings, and management access before the promotion wizard is ever opened.

• Join the servers to the domain as member servers first, patch them fully, and confirm they resolve existing controllers without stale host overrides or incorrect DNS suffix behavior.
• Point preferred DNS temporarily at existing healthy controllers so promotion relies on authoritative directory-backed resolution.
• Validate virtualization settings, firmware, and secure-boot posture now instead of introducing platform change risk during the AD DS step.
• Stage monitoring, backup agents, and endpoint protection exclusions before the first replication cycle so observability exists from day one.

Command path:

• Rename-Computer -NewName HF-DC25-01 -Restart
• Install-WindowsFeature AD-Domain-Services,DNS -IncludeManagementTools
• Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.com -Type SRV
• Test-ComputerSecureChannel -Verbose

GUI path: Server Manager > Local Server for hostname, NIC, and time settings, then Server Manager > Add roles and features to install AD DS and DNS binaries.

Add the new controllers one at a time and prove they behave like peers.

Promotion is only the midpoint. The real milestone is when the new server advertises correctly, participates in replication, hosts DNS cleanly, and survives forced validation from more than one site.

• Promote one new controller first, let replication converge, and validate SYSVOL, NETLOGON, SRV records, and event logs before introducing the second node.
• Confirm the new controllers register as Global Catalogs where required and that branch clients are still selecting the expected local site.
• Run health checks after each promotion and correct warnings before continuing so the environment never accumulates silent debt across multiple new nodes.
• Delay FSMO transfer until at least one full replication and authentication test cycle completes on the refreshed hardware.

Command path:

• Install-ADDSDomainController -DomainName corp.example.com -InstallDns -NoGlobalCatalog:$false
• repadmin /syncall /AdeP
• Get-Service Netlogon,DFSR,DNS
• dcdiag /test:Advertising /test:DNS /test:SysVolCheck /test:NetLogons

GUI path: Server Manager > Notifications > Promote this server to a domain controller, then DNS Manager and Active Directory Sites and Services to verify registration and placement.

Transfer ownership in a sequence that keeps rollback simple.

Once the new controllers are stable, move role ownership, authoritative DNS usage, and time-service responsibility in a controlled order so each dependency change is independently testable.

• Transfer RID, PDC Emulator, Infrastructure Master, Domain Naming Master, and Schema Master only after confirming the new controllers are replication partners and not just promoted members.
• Update DHCP options, static server NIC settings, forwarders, and monitoring targets so production workloads begin consuming the new DNS path intentionally.
• Move the authoritative time hierarchy only after the new PDC Emulator is stable and clients have shown normal skew behavior from multiple sites.
• Keep legacy controllers online but quiet while clients naturally age into the new path and operational telemetry confirms steady state.

Command path:

• Move-ADDirectoryServerOperationMasterRole -Identity HF-DC25-01 -OperationMasterRole 0,1,2,3,4
• Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.10.11,10.10.10.12
• w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com,0x8" /reliable:yes /update
• w32tm /resync /rediscover

GUI path: AD Users and Computers > Domain > Operations Masters, AD Domains and Trusts > Operations Master, and Active Directory Schema snap-in for FSMO transfers.

Retire the legacy hardware only after evidence shows it is no longer authoritative.

Demotion and cleanup should be the final administrative step, not the shortcut used to discover whether the new estate actually works.

• Demote one legacy controller at a time so any hidden dependency is isolated quickly and does not remove every rollback path at once.
• Verify old host records, NS records, delegation data, and site objects disappear or are intentionally cleaned up before the hardware leaves the network.
• Run metadata cleanup only when forced demotion or stale server objects require it; do not use cleanup to hide live replication problems.
• Remove obsolete backup jobs, alert targets, RMM objects, and admin documentation that still reference the retired hardware.

Command path:

• Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -RemoveApplicationPartitions
• Get-ADDomainController -Filter * | Select HostName,Site
• repadmin /showrepl * /csv
• ntdsutil "metadata cleanup" "connections" "connect to server HF-DC25-01" quit quit

GUI path: Server Manager > AD DS > More > Demote this domain controller, then Active Directory Sites and Services and DNS Manager for post-demotion cleanup.

Close the project with tests that mirror real operator use.

A controller refresh is complete only when authentication, policy, DNS, replication, backup, and recovery tests all succeed from the new hardware path without relying on the retired estate.

• Test interactive sign-in, service logons, GPO application, password change, and LDAP lookups from more than one site and subnet.
• Confirm backups complete against the new controllers and that at least one restore rehearsal exists in the runbook evidence set.
• Review Directory Service, DFS Replication, DNS Server, and Time-Service logs for recurring warnings that were introduced by the refresh.
• Publish the final controller inventory, role ownership map, and rollback-close statement to the operations team.

Command path:

• gpupdate /force
• nltest /dsgetdc:corp.example.com
• repadmin /replsummary
• dcdiag /e /test:DNS /test:Advertising /test:Services

GUI path: Event Viewer, Group Policy Management, Active Directory Administrative Center, and Windows Server Backup for final operator signoff.