FSMO Role Transfer Failed: A Read-First Owner, Replication, Permission, and Seize-or-Wait Triage

Helpdesk: "DC01 died Saturday night (the vendor says the replacement board won't arrive before Thursday). Since then nobody can create new user accounts on one of the remaining DCs, and a password reset took ages to show up. Someone tried to move the roles to DC02 in Active Directory Users and Computers and got 'The current FSMO holder could not be contacted.' A forum post says to seize all five roles with ntdsutil right now, then just power DC01 back on when the board comes. Can we do that?"

Not that way. "FSMO role transfer failed" usually isn't a broken role. A transfer is a conversation between the current holder and the new one, so it fails whenever the current holder is offline, unreachable, not yet replicated since it last started, or recorded as a server that no longer exists; a seizure skips that conversation, which is why it's a one-way decision about the old DC, not a stronger retry. Microsoft's guidance is blunt about both halves: "Role seizure should be performed only as a last resort", and "Do not allow a former operations master role holder whose role has been seized to return to an online domain controller." Seizing all five roles and then powering DC01 back on is the one combination that page warns about. Microsoft also notes that "FSMO roles assigned to domain controllers that are offline or in an error state only have to be transferred or seized if role-dependent operations are being done", so the first question is which operations are actually failing. Work through it as a chain: which roles, and what's failing because of them → who owns each role, according to more than one DC? → is the current holder online and replicating? → is the target DC the right one? → does your account have the rights for this role? → transfer, wait, or seize? → transfer it properly → seize it properly, only if Step 6 says so → clean up the old DC and the owners that still point at it → prove every DC agrees. netdom query fsmo, Get-ADDomain, Get-ADForest, Get-ADObject on the role objects, dcdiag /test:KnowsOfRoleHolders, repadmin /replsummary, Get-ADReplicationPartnerMetadata, Get-ADDomainController, and whoami /groups are the sources for that chain. Seize every role "to be safe" and you may burn RID space, leave a stale owner in a DNS application partition, and create a duplicate role holder the day the old hardware comes back.

If the role holder can't be reached because replication itself fails with RPC errors, Active Directory Replication Error 1722 covers that side first. If the new PDC emulator now has to become the forest's time source, Windows Time Not Syncing With Domain Controller covers the time chain. This post covers "an operations master (FSMO) role won't transfer, or you're deciding whether to seize it: 'The requested FSMO operation failed. The current FSMO holder could not be contacted.', 0x20AF or 0x20AE from ntdsutil or PowerShell, 'Access is denied' when you try, a role owner that shows a deleted DC, a demotion that can't determine role ownership, or a role holder that died and isn't coming back, and you need a read-first path before you run seize or -Force."

TL;DR

• Transfer needs the old holder; seize doesn't, and that's the risk. Microsoft: "We recommend that you only seize all roles when the previous role holder isn't returning to the domain." (Step 6).
• Read the owners from more than one DC. dcdiag's KnowsOfRoleHolders test "doesn't check all DCs knowledge for consistency", so compare netdom query fsmo and the fSMORoleOwner values from each DC (Step 2).
• A holder that just restarted isn't a holder yet. "The DC waits until it receives inbound replication for its naming context" before acting on a role, and so does a new holder after a transfer (Steps 3 and 10).
• Connect ntdsutil to the new holder, not the dead one. In Microsoft's procedure, the server you connect to "is the name of the DC that you want to assign the Operation Master role to." (Steps 7 and 8).
• Seizing the RID master costs RIDs. "The Move-ADDirectoryServerOperationMasterRole cmdlet increases the next Rid pool by 30,000 from what it finds in Active Directory." (Step 8).
• After a seizure, the old DC never comes back as it was. Clean up its metadata, and rebuild it from scratch if you want it as a DC again (Step 9).

---

Where in the chain did it break?

Step	What should be true	Typical symptom when it breaks
1. Symptom captured	Which roles, which operations fail because of them, which DC you ran the move from and as whom, the full error, and whether the old holder is coming back	"FSMO is broken" with no role, no error text, and no decision about the old DC
2. Owners read	Every DC names the same owner for each role, and every owner is a live, writable DC	Owners differ between DCs; an owner with a deleted (DEL) name; an owner nobody recognizes
3. Holder reachable	The current holder is online, answering, and has replicated inbound since it last started	0x20AF "The current FSMO holder could not be contacted."; replication failures on the holder or the target
4. Target right	The new holder is in the same domain, writable, healthy, up to date, and fits the global catalog rule for the infrastructure master	Transfer to an RODC; a target that's itself failing replication; infrastructure master on a GC in a domain that still needs it
5. Rights	The account is in the group each role needs, in an elevated session	"Access is denied"; a terminating permission error from PowerShell
6. Decision	Transfer when the holder is up, wait when nothing needs the role yet, seize only when the holder isn't returning	All five roles seized for a DC that's back in two days
7. Transfer	The role moves with the holder's cooperation, from the right tool, to the right DC	Transfer run against the dead DC; FQDN passed straight to -Identity
8. Seize	The role is seized on the right DC after replication has caught up, and the RID warning is understood	"Search failed to find any Domain Controllers"; RID pool jump nobody expected
9. Cleanup	The old DC's metadata is gone, no role owner (including DNS application partitions) points at it, and time follows the new PDC	Demotion or adprep fails later; the old DC returns and claims roles; time drifts
10. Proof	Every DC reports the new owner and the role-dependent operation works	netdom agrees on one DC and not another; account creation still fails

---

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Fact	Why it matters
Which roles	Schema master and domain naming master are forest-wide; PDC emulator, RID master, and infrastructure master are per domain. A move of the forest roles needs different groups and is checked against the forest root (Step 5)
What's failing because of them	Creating users, groups, or computers on a DC whose RID pool runs out (RID master); password changes, lockouts, Group Policy edits, or time (PDC emulator); adding or removing a domain or application partition (domain naming master); schema updates (schema master); cross-domain group member names or adprep /rodcprep (infrastructure master). If nothing is failing, you may have time (Step 6)
Current holder and its state	Is it powered off, unreachable, booting, restored from backup, force-demoted, or reinstalled? Is it coming back, and when? This is the seize decision (Step 6)
Target DC	Name, domain, site, global catalog or not, writable or read-only (Step 4)
Tool, place, and account	Active Directory Users and Computers, Domains and Trusts, the Schema snap-in, ntdsutil, or Move-ADDirectoryServerOperationMasterRole; run on which computer, as which account, elevated or not (Steps 5 and 7)
Full error text	The whole ntdsutil or PowerShell output, including the hex code (0x20AF, 0x20AE) and any "proceeding with seizure" line (Steps 3 and 8)
Since when, and what changed	Hardware failure, a forced demotion, a restore, a new DC that reused an old DC's name or IP address, a DNS change, a site or firewall change

Then branch on what you see:

What you see	What it usually means (our reading unless noted)	Start at
0x20AF "The requested FSMO operation failed. The current FSMO holder could not be contacted."	The holder is offline, unreachable from the DC doing the work, or hasn't finished inbound replication since it started	Steps 3 and 6
0x20AE "The role owner attribute could not be read."	The role object's owner value can't be read or resolved on the DC you asked	Step 2
An owner that contains DEL: or 0ADEL	The role points at an NTDS Settings object that has been deleted (Microsoft's reading in its seize and demotion articles)	Steps 2 and 9
"Access is denied"	Wrong group, a non-elevated session, or, during metadata cleanup, objects protected from accidental deletion	Steps 5 and 9
"Transfer of RID FSMO failed, proceeding with seizure" then "Search failed to find any Domain Controllers"	Microsoft's cause: "The fSMORoleOwner attribute of the RID Manager$ object in Active Directory is invalid."	Step 8
A demotion fails with "unable to determine the ownership of floating single-master operation roles"	A DNS application partition's infrastructure master points at a deleted DC	Step 9
Different DCs name different owners	Replication hasn't converged, or a DC is isolated	Steps 2 and 3
The holder is gone for good (dead hardware, reinstalled, force-demoted)	Seizure is the expected path, after replication checks	Steps 6 and 8

---

Step 2: Read who owns each role, from more than one DC (read-only)

Start with the two quick reads (Microsoft says netdom query must run from an elevated command prompt), then repeat them against the target DC and at least one other DC. Each DC answers from its own copy of the directory:

# The role owners as this computer's DC sees them (Microsoft's netdom query fsmo)
netdom query fsmo

# The same question answered by specific DCs (/server is the DC that performs the query)
netdom query /server:DC02 fsmo
netdom query /server:DC03 fsmo

# Domain roles and forest roles, asked of one DC at a time
Get-ADDomain -Server DC02 | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest -Server DC02 | Select-Object SchemaMaster, DomainNamingMaster

dcdiag has a test for this, but read its scope: KnowsOfRoleHolders "returns the DCs knowledge of the five Flexible Single Master Operation (FSMO) roles but doesn't check all DCs knowledge for consistency. Using the /e parameter provides data for comparison." The similarly named FsmoCheck test isn't the same thing; Microsoft's description ends with "This test does not test any of the servers for operations master roles."

REM Every DC in the enterprise reports what it knows about the five roles; compare the answers
dcdiag /test:KnowsOfRoleHolders /e /v

When the friendly names look wrong, read the raw owner. Each role is an fSMORoleOwner value on one object, and Microsoft's own instruction for a partition's infrastructure master is to "query the fSMORoleOwner attribute on the infrastructure object under the naming context root in question." The same read works for every role object:

# Read-only: the raw owner (an NTDS Settings DN) of every role object, as DC02 sees it
$dc   = 'DC02'
$root = Get-ADRootDSE -Server $dc
$dom  = $root.defaultNamingContext
$fr   = $root.rootDomainNamingContext
$objs = @(
    $dom                                          # PDC emulator (domain head)
    "CN=RID Manager`$,CN=System,$dom"             # RID master
    "CN=Infrastructure,$dom"                      # infrastructure master
    "CN=Partitions,$($root.configurationNamingContext)"  # domain naming master
    $root.schemaNamingContext                     # schema master
    "CN=Infrastructure,DC=DomainDnsZones,$dom"    # DNS application partition (domain)
    "CN=Infrastructure,DC=ForestDnsZones,$fr"     # DNS application partition (forest)
)
foreach ($o in $objs) {
    try {
        Get-ADObject -Identity $o -Server $dc -Properties fSMORoleOwner -ErrorAction Stop |
            Select-Object DistinguishedName, fSMORoleOwner
    } catch { "Not found on ${dc}: $o" }
}

Run it with $dc set to each DC you care about. Read the results like this:

Finding	What it means (our reading unless noted)
Every DC names the same live DC for every role	Ownership is consistent; the failure is about reaching or rights (Steps 3 and 5)
DCs disagree about an owner	Replication hasn't converged, or one DC is isolated; don't move anything until Step 3 explains why
An owner value contains DEL: or 0ADEL	The owner's NTDS Settings object was deleted. Microsoft's RID seize article shows "CN=NTDS Settings DEL:" as an invalid value; its demotion article explains that "The fSMORoleOwner attribute contains the string 0ADEL indicating that the role owning DC's NTDS Settings object has been deleted." (Steps 8 and 9)
The DNS application partition owners point at an old DC while the five main roles look fine	The classic leftover after a forced removal; netdom query fsmo doesn't show these (Step 9)
An owner is a DC you've never heard of	Check Get-ADDomainController -Filter * and the Sites and Services Servers container before you assume it's gone
Get-ADObject returns nothing for a DNS partition	That partition may not exist in this domain or forest, or the DC you asked doesn't host it (our reading)

---

Step 3: Is the current holder online and replicating? (read-only)

A transfer only works when the current holder takes part, and a holder only acts as one after it has replicated. Microsoft's transfer-or-seize article: "When a DC that has been acting as a role holder starts to run (for example, after a failure or a shutdown), it doesn't immediately resume behaving as the role holder." The per-role details are in Microsoft's FSMO roles article: the RID master "is active only when the role owner has inbound replicated the domain NC successfully since the Directory Service started", and the schema and domain naming masters have the same rule for their partitions. The PDC emulator is the exception: "There is no inbound replication requirement."

So read replication for the holder and the target before anything else:

REM Forest-wide summary: which DCs are failing inbound or outbound replication, errors first
repadmin /replsummary /errorsonly

REM Inbound replication status, per partition and partner, for the target and for the holder
repadmin /showrepl DC02
repadmin /showrepl DC01

# Read-only: the target's inbound partners for every partition it holds, with the last result
Get-ADReplicationPartnerMetadata -Target DC02 -Partition * |
    Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess,
        LastReplicationResult, ConsecutiveReplicationFailures |
    Format-Table -AutoSize

# Read-only: replication failures recorded for the target and the holder
Get-ADReplicationFailure -Target DC02, DC01

# Is the holder's name resolving and answering at all? (ICMP can be blocked; this is a hint, not proof)
Test-NetConnection -ComputerName DC01

Microsoft's note on the /showrepl output: "If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection." Then look at the events around the failed attempt on the DC that did the work:

# Directory Service events Microsoft's role articles mention (1586 after a PDC seizure, 2091 in a demotion log)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 1586, 2091
    StartTime = (Get-Date).AddDays(-2)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, Message

# RID issuance events (Microsoft: logged in the System log under Directory-Services-SAM)
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 16642, 16643, 16644, 16645, 16655, 16656, 16657
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, Message

Finding	What it means (our reading unless noted)
The holder is up and replicates both ways with the target	Reachability isn't the problem; check the target (Step 4) and rights (Step 5)
The holder restarted recently and its inbound replication for the role's partition has failed since	It won't act as the holder yet, and a transfer can fail with 0x20AF. Fix its replication first (Step 6 "wait")
Error 1722 (RPC server unavailable) between holder and target	A name, port, or firewall problem; Active Directory Replication Error 1722 covers that chain
A target-principal-name error between holder and target	Kerberos reached the wrong DC name or a stale password; The Target Principal Name Is Incorrect covers it
The holder is down or unreachable from every DC	Transfer is impossible until it's back; this is the Step 6 decision
The target itself fails inbound replication	It isn't "the most recent replicated writable copy"; fix it or pick another target (Step 4)
RID events on the DC that can't create accounts	The DC's RID pool ran low and the RID master couldn't supply a new one; that's the role you need first

---

Step 4: Is the target DC the right one? (read-only)

Microsoft's criteria for the new role holder are short: "It resides in the same domain as the previous role holder." and "It has the most recent replicated writable copy of the role partition." Its placement guidance adds: "Place the RID master on the domain PDC in the same domain." and "Place the schema master on the PDC of the forest root domain." The usual answer is a healthy DC in the same site that's a direct replication partner of the old holder. Microsoft's standby-master guidance says to "Ensure that the standby operations masters are direct replication partners of the actual operations masters."

# Read-only: every DC in the domain, its site, and whether it's a GC or read-only
Get-ADDomainController -Filter * |
    Select-Object Name, Site, IsGlobalCatalog, IsReadOnly |
    Sort-Object Site, Name | Format-Table -AutoSize

# Microsoft's single-DC global catalog check (True or False)
(Get-ADDomainController -Filter { Name -Eq 'DC02' }).IsGlobalCatalog

# Is the AD Recycle Bin enabled? (changes whether the infrastructure master matters)
Get-ADOptionalFeature -Identity 'Recycle Bin Feature'

REM Health of the proposed target, verbose
dcdiag /s:DC02 /v

Finding	What it means
The target is a read-only DC	It can't hold a role. Microsoft: "RODCs cannot act as operations master role holders." and the move cmdlet "does not work with a read-only domain controller."
The target is in another domain	Domain roles stay in their own domain; pick a DC in the same domain as the old holder
The target fails dcdiag or replication	Fix it first, or pick a healthier DC; a new holder waits for inbound replication before it acts (Step 10)
Infrastructure master target is a global catalog	Our reading: matters only when some DCs in a multi-domain forest aren't GCs and the Recycle Bin is off. Microsoft: "Don't put the infrastructure master role on the same DC as the global catalog server." but also "The infrastructure master role isn't used anymore once you enable Active Directory Recycle Bin." and "In a forest that contains a single Active Directory domain, there are no phantoms."
The target is a far site behind a slow link	Every DC needs to reach the RID master and PDC; prefer a hub-site DC (Microsoft's placement guidance)

If you need a property that isn't in that list, Microsoft's note on Get-ADDomainController is to pipe one DC to Get-Member and read all of them.

---

Step 5: Does your account have the rights for this role? (read-only)

Microsoft's current article: "The signed-in user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the infrastructure master roles are being transferred." Its older per-role procedures name Schema Admins for the schema master ("Membership in Schema Admins, or equivalent, is the minimum required to complete this procedure."), so for a schema master move, be in both (our reading).

Role	Group Microsoft names	Where the group lives
Schema master	Enterprise Admins (current article); Schema Admins (per-role procedure and seize table)	Forest root domain
Domain naming master	Enterprise Admins	Forest root domain
PDC emulator, RID master, infrastructure master	Domain Admins of that domain	The domain that holds the role

# Read-only: what the current session's token actually contains (look for the groups above)
whoami /groups

# Read-only: who's in the forest-level groups (ask a forest root DC)
Get-ADGroupMember -Identity 'Schema Admins' -Server DC02 | Select-Object Name, SamAccountName
Get-ADGroupMember -Identity 'Enterprise Admins' -Server DC02 | Select-Object Name, SamAccountName

Finding	What it means (our reading unless noted)
The group is missing from whoami /groups but the account is a member	The membership was added after you signed in; sign out and back in so the token has it
The groups are there, but ntdsutil says "Access is denied"	The prompt isn't elevated. Microsoft's procedures start with "Open a Command Prompt as an administrator"
PowerShell stops with a permission error	Microsoft: "If the acting credentials do not have directory-level permission to perform the task, Active Directory module for Windows PowerShell returns a terminating error." Run as the right account, or pass -Credential
Running from a workstation	Fine for PowerShell; for ntdsutil Microsoft says "We recommend that you log on to the DC to which you are assigning Operation Master roles."
"Access is denied" during metadata cleanup, not the move	A different cause: objects protected from accidental deletion (Step 9)

---

Step 6: Transfer, wait, or seize? (decision, no changes yet)

This is the step the forum post skips. Microsoft's rules:

• Transfer when "The current role holder is operational and can be accessed on the network by the new Operation Master owner."
• Seize when "The current role holder is experiencing an operational error that prevents an Operation Master-dependent operation from completing successfully, and you can't transfer the role.", after a forced demotion, or when "The operating system on the computer that originally owned a specific role no longer exists or has been reinstalled."
• Wait when you can: "If the role holder can be made operational before the role is needed, you may delay seizing the role." Except for one role: "The PDC role in each domain should always be online."

How much each role can wait, and how bad a duplicate would be (Microsoft's function list and its replication-island table):

Role	When you need it (Microsoft)	Conflict if two DCs hold it (Microsoft)
PDC emulator	"Must be online and accessible 24 hours a day, seven days a week."	No
RID master	When DCs need a new RID pool, including newly promoted DCs	Yes
Infrastructure master	Cross-domain references; no work in a single-domain forest	No
Domain naming master	"Must be online when domains and application partitions in a forest are added or removed."	Yes
Schema master	"Must be online when schema updates are performed."	Yes

Then decide:

Situation	Decision (our reading of Microsoft's rules)
Holder online, replicating, transfer failed for a reason Steps 3-5 found	Fix that reason and transfer (Step 7)
Holder down, returning soon, nothing failing but the PDC functions	Bring it back if you can. If the PDC can't wait, seizing only the PDC is the lowest-risk seizure in Microsoft's island table, but plan the old DC's return as a rebuild or a cleanup (Step 9), not a power-on
Holder down, returning soon, nothing role-dependent failing	Wait and fix the holder; don't seize
Holder gone: dead hardware, reinstalled, force-demoted	Seize all its roles on the chosen target (Step 8), then clean up (Step 9)
The plan is to restore the old DC from a backup	Don't. Microsoft: "The restoration process rebuilds the DC as a role holder again." Rebuild it from scratch instead
Two parts of the network each have a holder (replication islands)	Microsoft: "Before you reintegrate islands, determine which role holders to keep." Remove the duplicate schema, naming, and RID masters with the cleanup procedures

Before a seizure, Microsoft also asks for patience: "do not perform a role seizure until enough time has passed to complete at least one end-to-end replication cycle across your network." The more of the old holder's last changes reach the target, the less you lose.

---

Step 7: Transfer it properly (a change)

Only when Step 6 says transfer. In PowerShell, -Identity is the DC that gets the roles; Microsoft: "The Identity parameter specifies the directory server that receives the roles." The cmdlet doesn't have to run on either DC: it "can be remotely executed from any domain joined computer where the Active Directory module for Windows PowerShell administration module is installed and available for use."

# Preview, then move the three domain roles to DC02 (Domain Admins of that domain)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -WhatIf
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

# The two forest roles (Enterprise Admins; Schema Admins as well for the schema master)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole SchemaMaster, DomainNamingMaster

# Only have the FQDN? Microsoft's Example 5: resolve it with Get-ADDomainController first
$Server = Get-ADDomainController -Identity "dc02.contoso.com"
Move-ADDirectoryServerOperationMasterRole -Identity $Server -OperationMasterRole PDCEmulator

That last pattern matters: "There is a known issue where the Move-ADDirectoryServerOperationMasterRole cmdlet fails when an FQDN is specified directly as the value of the Identity parameter."

With ntdsutil, run it on the DC that will receive the roles (Microsoft's recommendation), connect to that DC, then transfer. Microsoft's syntax is transfer <role>; type ? at the fsmo maintenance: prompt to see the exact role names your version accepts:

C:\> ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC02
server connections: q
fsmo maintenance: ?
fsmo maintenance: transfer pdc
fsmo maintenance: transfer rid master
fsmo maintenance: transfer infrastructure master
fsmo maintenance: q
ntdsutil: q

The consoles do the same thing, one role at a time, as long as you point them at the target DC first:

Role	Console	Path (Microsoft's procedures)
RID master, PDC emulator, infrastructure master	Active Directory Users and Computers	Right-click Active Directory Users and Computers > Change Active Directory Domain Controller > select DC02 > right-click again > All Tasks > Operations Masters > the RID, PDC, or Infrastructure tab > Change
Domain naming master	Active Directory Domains and Trusts	Right-click Active Directory Domains and Trusts > Change Active Directory Domain Controller > select DC02 > right-click again > Operations Master > Change
Schema master	Active Directory Schema snap-in	Register it first with regsvr32 schmmgmt.dll and add it to an MMC; right-click Active Directory Schema > Change Active Directory Domain Controller > select DC02 > right-click again > Operations Master > Change

Transfer result	What it means (our reading unless noted)
Completed, and netdom query fsmo on DC02 shows DC02	Go to Step 10 to prove it everywhere
0x20AF "The current FSMO holder could not be contacted."	Steps 3 and 6: the holder isn't taking part; don't keep retrying
"Access is denied" or a permission error	Step 5
Fails only with the FQDN in -Identity	Microsoft's known issue; use the Get-ADDomainController pattern above
The console's lower box shows the wrong DC	You didn't change the console's domain controller to the target first

---

Step 8: Seize it properly, only if Step 6 says so (a change)

A seizure is a decision about the old DC, so make it once and write it on the ticket. Microsoft's older procedure explains the risk: "If two domain controllers are performing the same operations master role simultaneously, the severity of the effect from duplicate operations master roles varies, depending on the role that was seized. The effect can range from no visible effect to potential corruption of the Active Directory database."

On the target DC, in an elevated prompt, connect ntdsutil to that DC (Microsoft: "If ServerFQDN does not succeed, use the NetBIOS name of the DC."), then seize. The seize commands are Microsoft's; note the two exceptions: "Exceptions are for the PDC emulator role, whose syntax is seize pdc, and the Domain naming master, whose syntax is seize naming master."

C:\> ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC02.contoso.com
server connections: quit
fsmo maintenance: seize pdc
fsmo maintenance: seize rid master
fsmo maintenance: seize infrastructure master
fsmo maintenance: seize naming master
fsmo maintenance: seize schema master
fsmo maintenance: quit
ntdsutil: quit

Command	Credentials (Microsoft's seize table)
seize naming master	Enterprise Admins
seize schema master	Schema Admins
seize infrastructure master	Domain Admins
seize pdc	Domain Admins
seize rid master	Domain Admins

Seize only the roles the dead DC held (from Step 2), not every role in the forest. Expect ntdsutil to try a transfer first: "When you use Ntdsutil.exe to seize an operations master role, the tool first attempts a transfer from the current role owner." You'll see a transfer error and then the seizure. For the RID master, Microsoft adds that the target "tries to synchronize with a replication partner before accepting this role", and if it can't, "a dialog box appears asking you whether you want to continue with the operation despite this computer not being able to synchronize with a partner. Click Yes."

The PowerShell equivalent is the Step 7 command with -Force. Microsoft: "This operation still attempts graceful transfer first, then seizes if transfer is not possible."

# Seize only the roles the dead DC held (Microsoft's Example 4 form, with this post's role list)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -Force

Know what a RID master seizure costs before you run it. Microsoft: "Rid Master seizures increment the next available RID in the pool when you seize the RID master role." The amount depends on the tool: "The Move-ADDirectoryServerOperationMasterRole cmdlet increases the next Rid pool by 30,000 from what it finds in Active Directory." and with ntdsutil "it increases the next Rid pool by 10,000." Microsoft's conclusion: "So seize the Rid Master only when you're sure that the current Rid Master can't be brought back into service." A domain has "capacity for roughly one billion security principals", so one seizure is affordable; a habit of seizing isn't (our reading). Microsoft's read of the remaining pool:

REM Microsoft's form: the available RID pool for the domain, from the RidManager test
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

Seize result	What it means
The role list at the end shows DC02 for each seized role	Seized. Go to Step 9 before anything else
"Transfer of RID FSMO failed, proceeding with seizure ..." then "Search failed to find any Domain Controllers"	Microsoft's cause: "The fSMORoleOwner attribute of the RID Manager$ object in Active Directory is invalid." Its fix is to set fSMORoleOwner on CN=RID Manager$,CN=System to the new DC's NTDS Settings DN in ADSI Edit, and "Changing the fSMORoleOwner attribute accomplishes the same thing as seizing the role with Ntdsutil." Use it for that error only
"Access is denied"	Step 5: wrong group (Schema Admins for the schema master) or not elevated
You seized the infrastructure master	Microsoft's note: "After you seize the infrastructure master role, you may receive an error later if you need to run Adprep /Rodcprep." Check the DNS application partition owners in Step 9

---

Step 9: Clean up the old DC and every owner that still points at it (a change)

After a seizure, the old DC doesn't get its old life back. Microsoft's options for it: format and reinstall, or forcibly demote it, then remove its metadata from another DC; "After you clean up the metadata, you can repromote the computer to a DC, and transfer a role back to it." Restoring it from a backup is the wrong rebuild: "If you plan to use the repaired computer as a DC, we recommend that you rebuild the computer into a DC from scratch instead of restoring the DC from a backup." When the board in the opener arrives, keep DC01 off the network until it's reinstalled or demoted (our reading).

Metadata cleanup. Microsoft: "Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS)." The GUI way is to delete the DC's computer object from the Domain Controllers OU in Active Directory Users and Computers and select "This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO)". If it still holds roles, that dialog moves them to a DC it picks: "You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure." The command-line way, connected to a replication partner of the removed DC (Microsoft: "This domain controller must be a replication partner of the removed domain controller."):

C:\> ntdsutil
ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server DC02
server connections: quit
metadata cleanup: remove selected server DC01
metadata cleanup: quit
ntdsutil: quit

If cleanup says "Access is denied", Microsoft's note is to "make sure that the computer object and the NTDS Settings object for the domain controller are not protected against accidental deletion." Afterward, Microsoft's check is that the DC is gone from the Domain Controllers OU and that its server object in Sites and Services no longer has an NTDS Settings object.

DNS application partition owners. Rerun the Step 2 read for CN=Infrastructure,DC=DomainDnsZones,... and CN=Infrastructure,DC=ForestDnsZones,.... If either still names a deleted owner, demotions and adprep /rodcprep fail later. Microsoft's resolution: "Use ADSIEDIT.MSC to assign the DN path for the fsMORoleOwner attribute to a live DC that was a direct replication partner of the original FSMO role owner." or run the script in its adprep article, cscript fixfsmo.vbs DC=DomainDnsZones,DC=contoso,DC=com (and again for ForestDnsZones), copied from that article, not retyped.

Time. If the PDC emulator of the forest root moved, the time source moved with it. Microsoft: "The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source." Microsoft's w32tm /config example for a manual peer list, plus its /reliable:YES option ("This setting is only meaningful on domain controllers."), with your own time servers in place of its example names:

REM On the new forest-root PDC emulator (Microsoft's example peer names; use your own)
w32tm /config /manualpeerlist:"ntpserver.contoso.com clock.adatum.com" /syncfromflags:manual /reliable:YES /update

REM On a former PDC that's still a DC (transfer case): follow the domain hierarchy again
w32tm /config /syncfromflags:domhier /update

Windows Time Not Syncing With Domain Controller covers checking that chain afterward. The PDC emulator is also Microsoft's "Default target domain controller for Group Policy updates.", so Group Policy edits now land on the new holder; if they don't show up on clients, Group Policy Not Applying covers that path. Microsoft's placement article also notes that NTDS Replication event 1586 occurs when "the PDC FSMO role for a particular domain has been seized.", so expect it after a PDC seizure.

---

Step 10: Prove every DC agrees (read-only)

A new holder doesn't start work the moment the command returns. Microsoft: "After a role transfer or seizure, the new role holder doesn't act immediately." It waits for a successful inbound replication cycle of the role's partition, and "To have full effect, the change must replicate to all domain controllers in the domain for a domain-level role and to all domain controllers in the forest for a forest-level role."

# Every DC's answer, not just the one you're signed in to
Get-ADDomainController -Filter * | ForEach-Object {
    $n = $_.Name
    $d = Get-ADDomain -Server $n
    $f = Get-ADForest -Server $n
    [pscustomobject]@{
        AskedDC = $n
        PDC     = $d.PDCEmulator
        RID     = $d.RIDMaster
        Infra   = $d.InfrastructureMaster
        Schema  = $f.SchemaMaster
        Naming  = $f.DomainNamingMaster
    }
} | Format-Table -AutoSize

REM The same check, the dcdiag way, plus RID master health and replication
dcdiag /test:KnowsOfRoleHolders /e
dcdiag /test:RidManager /v
repadmin /replsummary

Microsoft's ntdsutil view of the connected DC's roles is roles > connections > connect to server DC02 > quit > select operation target > list roles for connected server.

Pass criteria (our reading): every DC names the same live holder for every role, the Step 2 fSMORoleOwner read (including both DNS application partitions) shows no deleted owner, repadmin /replsummary shows no failures, dcdiag /test:RidManager passes, and the operation from the ticket (creating an account on the DC that couldn't, a password reset, a Group Policy edit) works. Then close the ticket with the decision from Step 6 written down.

---

Common false starts

Tempting move	Why it's premature (our reading)
Seize all five roles right away	The dead DC may not hold all five, the RID seizure burns RIDs, and nothing may need the forest roles this week
Power the old DC back on after seizing its roles	Microsoft: "Do not allow a former operations master role holder whose role has been seized to return to an online domain controller." Rebuild it instead
Restore the old DC from backup	Restores it as a role holder again; Microsoft recommends a rebuild from scratch
Connect ntdsutil to the dead DC	The connection is to the DC that will receive the role
Retry the transfer over and over, or reboot the holder	A freshly started holder waits for inbound replication before it acts; fix replication (Step 3)
Trust netdom query fsmo from one DC	It shows that DC's view; compare several DCs and the raw fSMORoleOwner (Step 2)
Use dcdiag /test:FsmoCheck as proof	Microsoft: "This test does not test any of the servers for operations master roles."
Edit fSMORoleOwner in ADSI Edit first	That's a seizure by another route; Microsoft uses it for specific invalid-owner errors, not as a shortcut
Move the infrastructure master onto a GC without checking	Fine in a single-domain forest, with every DC a GC, or with the Recycle Bin on; otherwise it stops working
Add yourself to Schema Admins and leave it	Microsoft: "You should carefully manage and monitor membership in the SA group"; add for the change, remove after
Pass the target's FQDN straight to -Identity	Microsoft's known issue; resolve it with Get-ADDomainController first

---

When a change is justified

Finding	Prefer	Avoid
Holder online, transfer failed on replication	Fix replication, then transfer	Seizing a role from a DC that's working
Holder online, transfer failed on rights	The right group in a fresh, elevated session, then transfer	Permanent extra Schema Admins or Enterprise Admins members
Holder down for days, PDC functions failing	Bring the holder back; if you can't, seize the PDC alone and plan the old DC's rebuild	Seizing all five and powering the old DC on later
Holder dead or reinstalled	Seize the roles it held on a healthy, up-to-date DC in the same domain and site	Seizing to an RODC, a far site, or a DC that fails replication
RID master gone	Seize once, with the cost understood	Repeated RID seizures "to be safe"
Old DC still listed after a seizure	Metadata cleanup from a replication partner	Leaving its NTDS Settings object in place
DNS application partition owner points at a deleted DC	Microsoft's ADSI Edit or script fix for that partition	Ignoring it until the next demotion fails
Forest-root PDC moved	Configure the new PDC's external time source	Leaving the old time configuration on a DC that isn't the PDC
Old hardware repaired	Reinstall, promote fresh, and transfer roles back if you want	Restoring the old DC from backup

---

FAQ

What's the difference between transferring and seizing FSMO roles?
A transfer moves a role with the current holder's cooperation, so nothing is lost; Microsoft recommends it when "The current role holder is operational and can be accessed on the network by the new Operation Master owner." A seizure assigns the role without the old holder, so it's for a holder that isn't coming back, and that old DC must not return as it was (Steps 6-8).

Why does FSMO role transfer fail with "The current FSMO holder could not be contacted"?
The DC doing the work couldn't get the current holder to take part: it's offline, unreachable from that DC, or it restarted and hasn't completed inbound replication for the role's partition yet. Read replication for the holder and the target with repadmin /replsummary and repadmin /showrepl before you think about seizing (Steps 3 and 6).

Can I bring the old domain controller back after seizing its roles?
Not as it was. Microsoft: "Do not allow a former operations master role holder whose role has been seized to return to an online domain controller." Reinstall it or force-demote it, clean up its metadata, then promote it fresh if you want it back as a DC (Step 9).

Why does seizing FSMO roles say "Access is denied"?
Usually the account isn't in the group the role needs (Schema Admins for the schema master, Enterprise Admins for the domain naming master, Domain Admins for the domain roles), the membership was added after you signed in, or the prompt isn't elevated. Check whoami /groups in the same window (Step 5). During metadata cleanup, it can also mean the objects are protected from accidental deletion (Step 9).

How do I seize FSMO roles with PowerShell?
Use Move-ADDirectoryServerOperationMasterRole with -Identity set to the DC that receives the roles, -OperationMasterRole listing only the roles the dead DC held, and -Force. It "still attempts graceful transfer first, then seizes if transfer is not possible." For the RID master, it raises the next RID pool by 30,000, three times what ntdsutil does (Step 8).

---

Related posts

• Active Directory Replication Error 1722 (when the role holder can't be reached because replication fails with RPC errors)
• Windows Time Not Syncing With Domain Controller (when the new forest-root PDC emulator has to become the time source)
• The Target Principal Name Is Incorrect (when the holder and the target fail Kerberos between them)
• Group Policy Not Applying (when policy edits stall after the PDC emulator moves)

Free checklist

Seizing all five roles before anyone read who owns them, or whether the old DC is coming back, is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=fsmo-role-transfer-failed

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=fsmo-role-transfer-failed

---

Admin Pack Studio; not affiliated with Microsoft. Steps 1-6 and 10 are read-only checks: netdom query, Get-ADDomain, Get-ADForest, Get-ADRootDSE, Get-ADObject, dcdiag, repadmin /replsummary and /showrepl, Get-ADReplicationPartnerMetadata, Get-ADReplicationFailure, Test-NetConnection, Get-WinEvent, Get-ADDomainController, Get-ADOptionalFeature, whoami /groups, and Get-ADGroupMember. Transferring or seizing roles, editing fSMORoleOwner, metadata cleanup, demoting or rebuilding a DC, changing group membership, and changing the time configuration are deliberate changes. Change one link at a time, prove it from every DC, and check current Microsoft Learn for version-specific behavior.