The call comes in the way these calls always do: a server is down, it will not boot, and it happens to be the oldest one in the rack. You run netdom query fsmo from the DC that’s still alive and every single line points at the machine that just died. Schema master, domain naming master, PDC, RID pool manager, infrastructure master — all of it on the box now sitting dark in the corner. Then you check the backups and find the honest answer nobody wants to give a client: there isn’t one worth restoring. That moment feels like the end of the domain. It almost never is.

What saves you is the thing Active Directory has been doing quietly for years. Every writable domain controller in the environment holds a replicated copy of the users, groups, computers, Group Policy data, and AD-integrated DNS. The dead server wasn’t holding the directory hostage — it was holding five jobs, and jobs can be reassigned. So you stop trying to resurrect anything, permanently isolate the failed server so it can never rejoin, confirm the survivors are actually healthy first (SYSVOL, NETLOGON, clean replication between them), and then seize the roles onto the healthiest one that remains. The seizure itself is one command and about thirty seconds. The rest of the recovery — deleting the failed DC’s metadata, scrubbing its records out of DNS and its IP out of every DHCP scope, firewall, and printer that still points at it, then re-establishing the time hierarchy under the new PDC — is where the real hours go, and where a recovery that “worked” quietly falls apart weeks later if you skip it.

There is exactly one way to undo all of that: reconnecting the failed DC using its original Windows installation after the roles have been seized. If the hardware gets repaired, wipe it. If it’s a VM, do not restore the old snapshot. Two servers each convinced they hold the same FSMO roles is a far worse problem than the outage you started with. I wrote the whole thing down while it was fresh — every phase, every verification command, the _msdcs glue record repair that trips people up, and the post-recovery checklist — because this is the kind of procedure you want to read calmly at 2 a.m. rather than reconstruct from memory: Active Directory FSMO Recovery Guide, part of my open MSP Microsoft 365 knowledge base on GitHub.