FSMO roles are on a domain controller that is gone
One or more of the five single-master roles is held by a controller that no longer exists, so the operations that depend on it fail.
What you see
Password changes fail, new objects cannot be created, schema changes are refused, or a domain join fails. The error rarely mentions FSMO at all.
What is actually wrong
A domain controller was decommissioned without transferring its roles, or has failed. The directory still records it as the owner.
Codes and articles
Fixes (2)
Bring it back and transfer the roles properly
The holder can be brought back online. A transfer is always preferable to a seizure.
Find out where each role currently sits.
netdom query fsmoGet-ADForest | Format-List SchemaMaster,DomainNamingMasterGet-ADDomain | Format-List PDCEmulator,RIDMaster,InfrastructureMaster
Bring the holder online and confirm replication is healthy before transferring.
repadmin /replsummarydcdiag /s:DC01 /v | Select-String -Pattern 'failed|passed test' | Select-Object -First 40
Transfer the roles to the intended controller.
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMasterA transfer is a negotiated handover: both controllers agree and the old holder stops claiming the role. A seizure is unilateral and leaves the old holder believing it is still the owner, which is why it must never be brought back onto the network afterwards.
Verify and let replication settle.
netdom query fsmorepadmin /syncall /AdeP
netdom query fsmo; dcdiag /test:knowsofroleholders /v | Select-String 'passed|failed'Seize the roles and clean up the dead controller
The holder is gone for good. Read the warning in the first step before proceeding.
Be certain the old controller will never be powered on again on this network. If it is, the domain will have two controllers claiming the same role, which causes damage that is far harder to unpick than the original fault.
This is the one irreversible decision in the whole procedure. Wipe the old machine, or keep it permanently isolated — do not leave it powered off in a rack where somebody might helpfully start it.
Seize the roles.
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster -ForceRemove the dead controller's metadata from the directory. Without this it remains as a replication partner that everything keeps trying to reach.
ntdsutilmetadata cleanupconnectionsconnect to server DC02quitselect operation targetlist domains
The modern equivalent is a single cmdlet, which is safer and does the same work.
Get-ADDomainController -Filter { Name -eq 'DC01' } | Remove-ADDomainController -ForceRemovalOfLastDomainControllerInDomain:$false -Confirm:$falseRemove-ADObject -Identity 'CN=DC01,OU=Domain Controllers,DC=example,DC=local' -Recursive -Confirm:$false
Clean up the DNS records the dead controller left behind.
Get-DnsServerResourceRecord -ZoneName example.local -RRType A | Where-Object HostName -eq 'DC01'Get-DnsServerZone | Where-Object ZoneName -like '_msdcs*' | Format-Table ZoneName
Check the sites and services topology no longer references it.
repadmin /replsummaryrepadmin /showrepl * /csv | ConvertFrom-Csv | Format-Table 'Source DSA','Destination DSA','Number of Failures'
dcdiag /v | Select-String 'failed'repadmin /replsummary
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.