A domain controller migration from different server versions looks like an infrastructure project. On the surface: decommission old hardware, promote new hardware, transfer roles, raise the functional level. But buried in that process are a dozen security decisions that most teams make by inertia and tribal knowledge rather than by design. This post documents how I approached a simulated multi-DC promotion as a deliberate hardening exercise — and the lessons that came out of a process that got complicated before it got clean.
The Environment
- →
Server-1(206.127.235.50) — Windows Server, primary DC, all five FSMO roles, pre-2016 forest/domain functional level - →
Server-2(206.127.235.60) — Windows Server, promoted as secondary DC - →
Server-3(206.127.235.70) — Windows Server, third DC - →Single site, single subnet, hub-and-spoke DFSR topology with Server-1 as hub
FRS-to-DFSR: A Mandatory Security Prerequisite, Not an Afterthought
Modern Windows Server does not support the File Replication Service (FRS). If your domain is still using FRS for SYSVOL replication — which is the case for any domain that predates 2012 without having been explicitly migrated — you cannot promote a modern DC until you complete the FRS-to-DFSR migration.
This is also a security issue independent of the version upgrade. FRS is a legacy protocol with known limitations and no active development. DFSR provides more reliable replication, better event logging, and a healthier foundation for the SYSVOL you're about to trust with your Group Policy objects.
The migration is a four-state process. You must complete each state and verify before advancing — do not skip verification steps:
- 01Start — FRS still replicating SYSVOL. Verify:
dfsrmig /getmigrationstateshows state 0. - 02Prepared — DFSR replicating a copy in parallel with FRS. Verify state 1 across all DCs before proceeding.
- 03Redirected — SYSVOL served from DFSR copy. FRS copy still exists as fallback. Verify state 2.
- 04Eliminated — FRS copy removed. DFSR is sole replication mechanism. Verify state 3, then confirm no FRS service activity in Event Viewer.
Hub-and-Spoke Topology: The Rule That Saves You From Yourself
This is the single most important operational rule I documented during this migration, learned the expensive way: all new DCs must replicate from Server-1 (the hub), never from another secondary DC.
When Server-3 was first promoted, a previous troubleshooting session had pointed it at Server-2 as the replication source instead of the hub. The result was a cascade of DFSR connection object problems, WMI provider failures, and an RPC error loop that consumed significant time before the correct fix was identified: restore from snapshot, clean metadata, re-promote pointing at Server-1.
Why does this matter for security? DFSR replication topology integrity is what ensures Group Policy and logon scripts replicate consistently to all DCs. An inconsistent SYSVOL is an environment where GPO application becomes unreliable — and GPOs are frequently where security controls live.
The DHCP DNS Scope: A Subtle Assist
During post-promotion validation, we identified a DNS configuration issue with direct security implications: 8.8.8.8 was present in the DHCP scope as a fallback DNS server. On the surface, this seems harmless — it's just a fallback if the internal DNS is slow. In practice:
- !Clients that resolve via 8.8.8.8 miss internal DNS records — domain join failures were observed during this period
- !An attacker who compromises a client can observe its DNS queries to 8.8.8.8 to understand your internal domain naming conventions
- !DNS-based security controls (internal sinkholes, split-horizon DNS, blocked resolution of known-bad domains) are bypassed for clients that fall through to the external resolver
Remediation: remove 8.8.8.8 from the DHCP scope entirely. Add all three DC IPs (0.12, 0.27, 0.54) as DNS servers. Your DCs should be the authoritative resolver for all clients — no external fallback.
Auditing Hardcoded Credentials Before FSMO Transfer
Before decommissioning Server-1, every appliance and service that has a hardcoded reference to its IP or hostname must be updated. "What has hardcoded credentials pointing at my oldest, most-trusted domain controller?" is a question you want answered before the migration, not after.
Least Privilege: Separating Admin from Daily-Use Accounts
The migration process requires domain admin privileges at multiple points. This is the moment to make a structural decision that many environments defer indefinitely: your daily-use account should not be a domain admin.
The pattern I operate with:
- →Daily-use account: standard user, no elevated privileges, used for email, browsing, and general work
- →Admin account: separate account, domain admin, used only for specific administrative tasks, never for general browsing or email
- →Service accounts: scoped to the minimum permissions required for the specific service, not shared across services, audited quarterly
The cost of this separation is a small amount of daily friction. The benefit is that a compromised daily-use account — via phishing, credential stuffing, or browser exploit — does not immediately hand an attacker domain admin.
Maintenance Windows as a Security Control
Every service-impacting change in this migration was scheduled for after-hours. This is treated as an operational best practice, but it's also a security control: changes made under time pressure, during business hours, with people watching and asking questions, tend to be rushed. Rushed changes skip verification steps. Skipped verification steps leave environments in ambiguous states that are harder to reason about under incident conditions.
The discipline of "this goes in after hours with a snapshot and a rollback plan" is not just caution — it's the difference between an environment you understand and one where you're not sure exactly what state things are in. That uncertainty is exploitable.
GUI vs PowerShell: Choosing the Right Tool for Reliability
There's a culture in sysadmin work that prizes PowerShell over GUI wizards. For many tasks, that's correct — scripts are auditable, repeatable, and source-controllable. But for DC promotion specifically, the Server Manager wizard is the right tool. It runs the same underlying code as PowerShell, generates cleaner diagnostic output on failure, and — critically — does not leave you in a partially-configured state if something goes wrong mid-run the way a failed PowerShell script can.
The failed Server-3 promotion attempt in this project happened via a PowerShell-heavy manual troubleshooting session that created connection objects, edited registry keys, and modified DFSR settings — none of which cleaned up correctly. The successful promotion happened by restoring from snapshot and running the GUI wizard. Reduce variability by choosing the tool that fails cleanly.