A domain controller has failed and is not coming back, and it held one or more FSMO roles. Until those roles are moved to a healthy DC, parts of your domain operate in a degraded state — and depending on which role is missing, that degradation ranges from "harmless for a week" to "users can't change passwords starting now".

This guide explains what each FSMO role does, how to identify which DC holds what, and how to seize a role from a permanently-dead DC using ntdsutil — including the rule that the original DC must never come back online afterwards. Written for IT administrators and infrastructure engineers responsible for Windows AD environments.

If your domain is degraded right now and you need this resolved cleanly, call 01923 372471 — senior engineer answers directly.

The five FSMO roles, briefly

Active Directory has five Flexible Single Master Operations (FSMO) roles, distributed across DCs in the forest. Each role is a single point of authority for a specific domain or forest function:

RoleScopeWhat it doesTolerates outage of
Schema MasterForestAuthoritative for AD schema changesDays — only relevant during schema extensions (new Exchange version, AD-integrated apps)
Domain Naming MasterForestAuthoritative for adding/removing domains in the forestDays — only relevant during domain-level changes
PDC EmulatorPer domainTime authority for the domain; password chain master; trust referrals; group policy authorityHours. Password changes, account lockouts, time sync, GPO operations all degrade quickly
RID MasterPer domainIssues RID pools to other DCs for SID generationDays, until existing RID pools on other DCs run out
Infrastructure MasterPer domainCross-domain object reference updatesDays, only relevant in multi-domain forests

In a single-domain forest (the vast majority of UK SMBs), all five roles often sit on the same DC — which is convenient for management but turns that DC's failure into a multi-role seizure problem.

Step 1: Identify who holds what

# All five FSMO roles in one shot:
netdom query fsmo

Output looks like:

Schema master              dc01.corp.local
Domain naming master       dc01.corp.local
PDC                        dc01.corp.local
RID pool manager           dc01.corp.local
Infrastructure master      dc01.corp.local

Or for a more verbose look:

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

Save this output now, before you have an incident. Add it to your runbooks.

Step 2: Decide — transfer or seize?

Two operations move a role; they are not interchangeable.

Transfer

Used when the source DC is alive and reachable. The role is handed over cleanly, both DCs agree the move happened, and the source DC continues to operate as a regular DC. Reversible by another transfer back.

Seize

Used when the source DC is dead, unrecoverable, or unable to communicate. The destination DC declares ownership; the source DC is never told. The seized-from DC must never come back online afterwards. Bringing it back causes USN rollback, lingering objects, and a forest that develops inconsistent data over time — sometimes silently, sometimes catastrophically.

If the dead DC has any chance of recovery, transfer is preferable. If it definitely is not coming back (hardware destroyed, fire, theft, irreparable corruption), seize.

Step 3: When to seize each role — by urgency

In a real failure, you may not have time or quorum to seize all five at once. Prioritise:

PDC Emulator — within hours

The PDC handles:

A missing PDC starts causing user-visible problems within the day. Seize first if missing.

RID Master — within a day or two

The RID Master issues pools of 500 RIDs to each DC. Each DC consumes its pool as new objects (users, computers, groups) are created. When the pool is half-exhausted, the DC asks the RID Master for another. If the RID Master is gone, eventually a DC runs out of its current pool and can no longer create new objects. Time to exhaustion depends on how busy the domain is — typically days to weeks, but verifiable.

Check current RID pool status:

dcdiag /test:ridmanager /v

Infrastructure Master, Domain Naming Master, Schema Master — when convenient

In a single-domain forest, the Infrastructure Master is largely irrelevant (it manages cross-domain references, of which there are none). Schema Master and Domain Naming Master matter only when you're making forest-level changes — extending the schema for Exchange, adding a child domain, etc.

That said, leave them on a dead DC indefinitely and you'll forget. Seize them within days; just not at 2am on the day of the outage.

Step 4: Seizing FSMO roles via ntdsutil

ntdsutil is the canonical tool. Run it from the DC you want to receive the seized roles.

ntdsutil
roles
connections
connect to server <target-dc>
quit

You're now in the FSMO seize prompt, connected to the destination DC. From here:

seize PDC
seize RID master
seize infrastructure master
seize naming master
seize schema master

Each seize command first attempts a transfer. If the source DC responds, the operation completes as a transfer. If it doesn't (because it's dead), ntdsutil falls through to seizure. Either way, the role ends up on the destination.

When done:

quit
quit

Verify:

netdom query fsmo

All five roles should now show the destination DC.

Step 5: Modern PowerShell alternative

Move-ADDirectoryServerOperationMasterRole is the PowerShell-native equivalent. Functionally similar, with a -Force flag to escalate transfer to seizure.

# Identify roles by integer:
# 0 = PDCEmulator
# 1 = RIDMaster
# 2 = InfrastructureMaster
# 3 = SchemaMaster
# 4 = DomainNamingMaster

Move-ADDirectoryServerOperationMasterRole -Identity "<destination-dc>" `
    -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity "<destination-dc>" `
    -OperationMasterRole SchemaMaster, DomainNamingMaster -Force

The -Force flag is the seize escalation. Without -Force, the cmdlet attempts only a transfer and fails if the source DC is unreachable. With -Force, it falls through to seize.

PowerShell or ntdsutil — both work. For experienced administrators in a hurry, ntdsutil's explicit prompts are reassuring. For scripting and automation, PowerShell is cleaner.

Step 6: Post-seizure cleanup — critical

This is the step that gets skipped at 2am and causes problems for years afterwards.

Run metadata cleanup for the dead DC

The DC's records still exist in AD — DC object, NTDS Settings, replication links, FRS/DFSR membership, DNS records. Until you remove them, replication will continually attempt to contact the dead DC, fail, and log errors.

The simplest way: in Active Directory Users and Computers, navigate to the Domain Controllers OU, right-click the dead DC, choose Delete. AD detects the DC is unreachable and offers to remove its metadata. Confirm.

The thorough way:

ntdsutil
metadata cleanup
connect to server <healthy-dc>
quit
select operation target
list domains
select domain <number>
list sites
select site <number>
list servers in site
select server <dead-dc-number>
quit
remove selected server
quit
quit

Clean DNS

In the AD-integrated DNS zone:

# Show all SRV records pointing at the dead DC (substitute name):
Get-DnsServerResourceRecord -ZoneName "_msdcs.<domain.local>" |
    Where-Object { $_.RecordData.DomainName -like "*<dead-dc>*" }

AD Sites and Services

Open AD Sites and Services, navigate to the appropriate site, expand Servers, find the dead DC, and delete it. This removes the DC's connection objects to other DCs, which in turn fixes a cluster of "replication will retry forever" errors.

Check FRS/DFSR membership

If your SYSVOL still uses FRS (legacy — should have been migrated to DFSR by 2008), or DFSR replication shows the dead DC as a member:

dfsrdiag pollad
dfsrdiag replicationstate

Remove the dead DC's membership in DFSR for the SYSVOL replication group.

Step 7: Verify the new role holders

# Roles correctly placed:
netdom query fsmo

# All DCs healthy:
dcdiag /e /v

# Replication healthy:
repadmin /replsummary
repadmin /showrepl

# DNS clean:
Resolve-DnsName -Type SRV "_ldap._tcp.<domain.local>"
# - Output should show only living DCs.

# RID Master pool issuing correctly (especially after RID Master seizure):
dcdiag /test:ridmanager /v

All clean? Document:

What NOT to do

After the dust settles — preventing the next one

When to call us

Call us if:

Engineerdirect.co.uk handles AD environments daily and has resolved seizure scenarios across single-DC SMBs through to multi-domain forests. On-site response across London and the South East within 2 hours.

Call 01923 372471 — senior engineer answers directly.

FAQ

Can I seize a role from a DC that's only temporarily offline? You can, but you shouldn't unless the DC will be permanently retired. Once seized, returning the original DC to the network risks USN rollback. If the DC is only briefly offline, wait — or transfer the role first (which requires the source to be reachable).

What happens if I seize a role and then bring the original DC back online? USN rollback. The original DC has its own copy of the directory database with USNs that the rest of the forest hasn't seen. When it replicates, peers may receive incorrect data or stop replicating with it. Recovery typically requires force-demoting the misbehaving DC, metadata cleanup, and rebuilding it from scratch.

Should I always seize all five roles to the same DC? In a small environment with two or three DCs, splitting roles across DCs reduces the impact of any single DC failure. In larger environments, follow Microsoft's general guidance: PDC and RID together; Infrastructure on a different DC than a Global Catalog (only relevant in multi-domain forests); Schema and Domain Naming wherever convenient.

How quickly do I have to seize the PDC role? Practically, within 4–24 hours. The first symptoms (Kerberos time skew, GPO operations failing, password chain delays) start appearing within hours of PDC loss. Fix it the same day if you can.

Can I just promote a new DC instead of seizing roles? You still need to seize the roles. Promoting a new DC adds a new DC; it doesn't transfer the dead DC's roles automatically. After the new DC is healthy, transfer or seize the relevant roles to it (or to an existing healthy DC).

Does seizing a role break replication? Seizure itself doesn't break replication on healthy DCs. The reason you're seizing — that one DC has died — is what's "breaking" replication, in the sense that one of the DCs is unavailable. After seizure and metadata cleanup, replication between the remaining healthy DCs continues normally.

Seizing FSMO roles cleanly is unforgiving work — if you'd rather not risk it, our emergency Active Directory recovery can do it with you.

Part of a series of disaster-recovery references. If your domain is degraded right now: 01923 372471.

References

Authoritative Microsoft documentation behind this guide:

Dealing with this right now?

Don't read guides when your systems are down. Call and get a senior engineer on the phone directly.

📞 01923 372471