Rebuilding My Second Domain Controller and Reusing Its IP

Moving a healthy DC VM to another physical host would usually be simpler. Here I deliberately built a new writable DC from a generalized template, updated and promoted it, verified replication, and normally demoted the old DC2. The replacement kept its new name and eventually reused the old IP.

The core switch and functional checks completed on September 21, 2026. The old VM was removed from the domain, powered off, and disconnected, but its disks remained. Reusing an IP does not inherit an FQDN, TLS certificate, or client dependencies.

Define the replacement boundary

Component	Before	After
PVE1	DC1 and old DC2	DC1; old DC2 isolated
PVE2	No production DC	New DC2, VM201
DC1	FSMO, DNS, GC, enterprise CA	Unchanged
Cloud DC3	RODC, DNS, GC	Unchanged
DC2 IPv4	Existing address	Taken over by the new server

DC1 also hosted the enterprise CA. AD replication does not migrate its private key, database, or local configuration. The PVE cluster had no QDevice and no HA resources; separating DCs physically did not prove host-failure recovery.

Examples use corp.example.com, DC1, OLD-DC2, and NEW-DC2, rather than actual environment identifiers.

Check archives and build an independent machine

After copying the old DC and template archives to PVE2, three checks passed:

sha256sum archive.vma.zst
zstd -t archive.vma.zst
zstd -dc archive.vma.zst | vma verify -

Hashes check copy equality, zstd checks compression, and VMA checks archive structure. None substitutes for a restore drill. The template was actually restored and then fully cloned:

# Replace VMIDs, storage, and filenames for the actual environment
qmrestore golden.vma.zst 200 \
  --storage local-lvm --unique 1 --start 0 --ha-managed 0
qm clone 200 201 --name NEW-DC2 --full 1 --storage local-lvm

Before first boot, its network was disconnected. It was in WORKGROUP, had no AD DS/DNS/CA roles, and generated an independent machine identity. A promoted DC’s identity must not be copied to create another DC.

The template lacked a running QGA even though Windows reached its desktop. Installing the agent restored management access. Inherited autologon and sensitive answer files were cleaned up. A conflict-checked temporary IP let the old DC remain online.

Finish preparation before switching traffic

Updates ran through WUA in a SYSTEM scheduled task. Final versions, rescans, and pending-reboot state mattered more than an individual installation code. Before promotion, firewall and IPv6 remained enabled, AD DNS SRV queries worked, and QGA/exporter services and restricted monitoring access were checked.

After domain join and AD DS/DNS installation, a preflight used credentials supplied securely in the session:

Test-ADDSDomainControllerInstallation `
  -DomainName 'corp.example.com' `
  -Credential $cred `
  -SafeModeAdministratorPassword $dsrm `
  -InstallDns `
  -NoGlobalCatalog:$false `
  -ReplicationSourceDC 'DC1.corp.example.com'

This command tests prerequisites; it does not perform promotion. After promotion and reboot, verify writable status, GC, every naming context, SYSVOL, and NETLOGON. Initial topology-incomplete errors cleared after convergence and rechecking.Microsoft DC replacement guidance

Hand over names and dependencies before the IP

authentik used a random three-DC LDAPS pool. The sequence was: save configuration, remove old DC2, verify remaining DCs, obtain the new FQDN certificate, validate trust/name/real binds, update server and worker resolution plus persistent Compose configuration, then recheck after IP takeover and add the new DC.

ldaps://OLD-DC2.corp.example.com
                  ↓
ldaps://NEW-DC2.corp.example.com

A CNAME alone cannot fix certificate names, SPNs, or DC locator records. Trusted-CA connections passed and untrusted connections failed, confirming certificate verification.

The old server held neither FSMO roles nor a CA. It passed normal demotion checks; -Force for confirmation suppression is distinct from -ForceRemoval. When the remote channel lacked a final exit code, dcpromo logs, role state, and post-reboot WORKGROUP membership established completion instead.

Only after demotion, domain removal, shutdown, and network disconnection did the new DC take the IP. Four stale DNS application-partition SRV records were exported and precisely removed. This is an environment-specific procedure, not a universal one-command migration.Microsoft demotion documentation

Test actual authentication and replication

A low-privilege temporary user was created and later deleted, with cleanup checked across DCs.

Test	Recorded result
Write on new DC2, read on DC1	Passed
Update on DC1, read on new DC2	Passed
Replicate new object to RODC	Passed
Kerberos LDAP, LDAPS 636, encrypted GC 3269 queries	Passed
One deliberately incorrect test password	Rejected
Reset on DC1, verify new password on DC2	Passed
Ordinary-user SYSVOL read	Passed; 8 policy files

Security events included successful 4768/4769 and a failed-password 4625. Harmless temporary text files were created locally on each DC, verified on the peer by SHA-256, then deleted with propagation checked in both directions. An earlier remote-write Access Denied was a test-identity issue; changing the test avoided weakening production ACLs.

A red DFSREvent check needs a timeline

dcdiag /test:DFSREvent examines the preceding 24 hours and still flagged 5014/5002 from old-DC demotion. Later connection-removal events, folder state 4, LastErrorCode=0, and successful live replication established current function.

The conclusion was “current replication works, historical-event check still fails,” not “all dcdiag tests are green.” Logs were not cleared to manufacture success.

Make the IP handoff interruptible

Before handoff, record names, addresses, and certificates for both DCs. After graceful demotion, ensure the old machine cannot reclaim the address through another interface, automatic startup, or DHCP. Disabling one NIC does not establish full IPv4/IPv6 isolation.

Use explicit stop points: accept promotion/replication, remove the old application-pool entry, demote/isolate, confirm address vacancy, assign the new address, update name dependencies, and validate fresh connections. Do not restore the old promoted-DC snapshot online as a generic rollback; directory replication identity is not ordinary file state.

Investigate actual client resolution and connection destinations before clearing caches indiscriminately. Neighbor/DNS caches and pools may retain old state. Certificate names must still match client URIs despite address reuse.

Accept more than open TCP ports

Get-ADDomainController -Filter * |
  Select-Object HostName,IPv4Address,IsGlobalCatalog,IsReadOnly
repadmin /replsummary
repadmin /showrepl
dcdiag /test:Advertising /test:SysVolCheck /test:NetLogons
Get-SmbShare -Name SYSVOL,NETLOGON

Interpret these read-only checks alongside application behavior. Use correct, incorrect, and disabled test-account controls for authentication. Existing SYSVOL/NETLOGON shares do not establish bidirectional content updates: verify and undo a controlled change, recording source, destination, and time.

Layer	Existing evidence	Separate follow-up
Directory replication	Naming-context summaries and directed results	Continued natural replication
TLS/authentication	New-name certificate and real bind	All renewal-dependent paths
SYSVOL	Shares and bidirectional changes	Policy processing and recovery
User login	Directory queries cannot substitute	RDP/MFA/OIDC end-to-end paths
Backup	Archive/compression checks	DC/CA recovery exercises

Preserve the old configuration, backup, demotion record, and retention decision. Disk destruction is a separate uncompleted action. Recheck client behavior, monitoring, and DC events after a running interval rather than relying on one green summary.

Remaining work

The final archive was about 9.44 GB and passed zstd/VMA checks. Monitoring targets were UP and both authentik containers could bind to all DCs. RDP verification stopped at HYBRID/NLA negotiation, without an interactive desktop. An HTTP 200 and LDAP binds did not repeat the full browser MFA/OIDC flow.

Old-disk destruction, an isolated restore of the final backup, host/quorum failure drills, and complete interactive login retests remained open. The weekly backup plan was updated, but future execution needs separate verification.

Keeping a backup is not permission to reconnect an old DC snapshot casually; use supported AD recovery procedures. Ordinary-user authentication, cross-node password validation, and bidirectional live SYSVOL changes remain the most useful acceptance evidence.

Related: PVE cluster creation and authentik Dashboard SSO.

---

The article date is the main KB’s first Git commit date, 2026-09-21 (UTC+8), commit 01d8839. Experiment dates are stated separately. No production systems were accessed or changed while preparing this article.