Error 8610: FSMO role ownership cannot be verified until the partition replicates

Fix it now

Error 8610 is ERROR_DS_ROLE_NOT_VERIFIED, and Microsoft is specific about why: the FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner. That makes replication the fault, not the role. Repair replication and transfer normally; seize only when the owner is permanently gone.

netdom query fsmo
repadmin /replsummary
repadmin /showrepl
w32tm /monitor

1. Read the replication summary first. 8610 is telling you a partition has not replicated with any partner, so the failing partition and its error are the actual problem.
2. Check whether the current owner is alive at all. If it answers and the only fault is replication, do not seize – fix replication and transfer.
3. Transfer with Move-ADDirectoryServerOperationMasterRole -Identity <target> -OperationMasterRole PDCEmulator,RIDMaster, naming the server that should hold the role afterwards.
4. Only when the owner is permanently gone, add -Force, which Microsoft documents as the parameter used for seize operations. Then clean the old owner’s metadata out of the directory and make sure it can never rejoin the network.

Rights differ by role: Enterprise Administrators for the schema master or the domain naming master, Domain Administrators for the PDC emulator, RID master and infrastructure master.

If two controllers now agree on a live holder for every role, you are done. If they do not, the next section explains the difference between a transfer and a seizure and why doing the second on top of a replication fault is the expensive mistake.

Why it happens

Five roles exist. The schema master and the domain naming master are forest-wide and held once each; the RID master, PDC emulator and infrastructure master are held once per domain. Ownership is recorded as an attribute pointing at the NTDS Settings object of the owning controller, and it is that attribute the tools read, write, and here cannot verify.

A transfer is a conversation. The receiving controller contacts the current owner, the two agree, and the change replicates outward from a state both ends recognise. A seizure skips the conversation, writes the attribute locally, and relies on replication to convince everyone else. That is safe when the previous owner will never speak again and dangerous when it will.

8610’s published text names the condition directly: the role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner. So the message is not really about the role at all. It is replication reporting that this controller’s view of the partition carrying the role is not trustworthy enough to act on – which is exactly the state in which a seizure does the most damage.

LDAP 52 often appears alongside it. Microsoft publishes that as LDAP_UNAVAILABLE, 0x34, “The server is unavailable.” That is consistent with a server that has genuinely gone and with one that is merely restarting, has its directory service stopped, or is running in Directory Services Restore Mode. Telling those apart is the whole job before you act, and no error code will do it for you.

Full reference

What each role does, and what is felt first without it

Transfer or seize

The commands, and the rights each one needs

The accepted values for the role parameter are PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster and DomainNamingMaster, and you can give more than one as a comma-separated list. Rights: Enterprise Administrators for the schema master or the domain naming master, Domain Administrators of the domain concerned for the PDC emulator, RID master and infrastructure master.

Seizing from ntdsutil

ntdsutil
roles
connections
connect to server DC02
q
seize rid master
q
q

Microsoft documents seize rid master, seize pdc and seize naming master on that menu. The menu’s own help lists the rest; type a question mark at the roles prompt rather than guessing at command wording.

Once a role has been seized, the previous owner must never be reconnected to the network. It will still believe it holds the role, and it still holds a database copy that can reintroduce objects deleted while it was away. Microsoft’s guidance is to rebuild the machine as a domain controller from scratch rather than restoring it from a backup, and to remove the previous role holder from the domain if you cannot repair it.

Before you seize anything

1. Establish beyond doubt that the current owner is permanently gone, not restarting and not in Directory Services Restore Mode.
2. Take a system state backup of the controller you are seizing onto.
3. Confirm that controller is replicating cleanly with the rest of the estate, because a seizure on a broken replica spreads the disagreement rather than resolving it.
4. Check your group membership for the specific role you are seizing.
5. Plan the metadata cleanup in the same change window. A seized role with the dead server still in the directory is a half-finished job that produces confusing errors for months.

Every code this article covers

Confirm the fix worked

1. netdom query fsmo run from two controllers returns the same live server for every role.
2. The role-holder diagnostic passes on a controller in another site.
3. repadmin /replsummary shows the partition that carries the role replicating successfully with at least one partner, which is the condition 8610 was reporting on.
4. The previous owner, if it was seized from, is off the network and its metadata has been cleaned out.
5. A system state backup of the new holder completes and restores in a test.

Questions people ask about this