Small Town Sysadmin
Free CJIS checklist

Field notes

Field note: the domain controller that couldn't take a new partner

The plan was simple, add a new domain controller and retire the old one. An old replication setting nobody had thought about in years stood in the way.

The job looked straightforward. An old domain controller, running Windows Server 2008 R2 on an outdated virtualization host, needed to be modernized. Step one was moving it to a current host, which went smoothly. Step two was the usual plan: build new domain controller VMs on a current version of Windows Server, move the roles over, and retire the old one. No in-place upgrades.

Then I checked how SYSVOL was replicating.

The problem: FRS

SYSVOL is the shared folder that holds Group Policy and logon scripts on every domain controller. Old domains replicated it with FRS (File Replication Service). Microsoft replaced FRS with DFSR (Distributed File System Replication) years ago, and newer versions of Windows Server won’t join as domain controllers while SYSVOL is still on FRS.

This domain had never been migrated. It was still on FRS, which meant no new domain controller could be added until that was fixed.

The plan, in order

  1. Migrate SYSVOL from FRS to DFSR first, using Microsoft’s built-in dfsrmig tool, which moves through the migration in stages and lets you verify each one.
  2. Then add the new domain controllers, transfer the FSMO roles, and confirm replication is healthy.
  3. Then retire the old domain controller and raise the functional level.

What I took away from it

  • Check SYSVOL replication before planning any domain controller upgrade. Running dfsrmig /getglobalstate shows where a domain stands. If the domain was never migrated, that’s step one.
  • Old domains carry old decisions. A setting made fifteen years ago can block today’s project.
  • Build new, move roles, retire old. It’s slower than an in-place upgrade but far safer.

See also: Retiring old domain controllers before Server 2016 support ends.

All articles