What are the FSMO roles and how do I move them?

By Vitalii Shumylo · 3 October 2026 · 8 min read

The FSMO roles, which Microsoft now calls operations master roles, are five jobs in Active Directory that only one domain controller may do at a time: two per forest (schema master and domain naming master) and three per domain (RID master, PDC emulator and infrastructure master). You find them with netdom query fsmo, and move them with Move-ADDirectoryServerOperationMasterRole - a normal transfer while both DCs are online, or a seizure with -Force when the old holder is gone for good.

This article covers what each role does, where they should live, how to find them, how to transfer them, and when to seize them; by the end, you'll have moved two roles to DC2 and know what not to do after a seizure.

The five roles and their scope

AD replication is multi-master: almost any change can be made on any DC. But a handful of jobs would break if two DCs did them at once, so each one has a single owner.

The one that matters most day to day is the PDC emulator. The PDC emulator of the forest root domain is the time source for the whole forest, and Kerberos refuses sign-ins once clocks are more than five minutes apart.

Where the roles should live

Knowing what they do leads straight to where to put them. In a small, single-domain forest I leave all five on one well-connected DC and move them together - it keeps the picture simple when something fails.

In larger forests, the usual pattern is to keep the PDC emulator and RID master together on a reliable DC, and the schema and domain naming masters together in the forest root domain. The infrastructure master shouldn't sit on a global catalog unless every DC in the domain is a GC. Once the AD Recycle Bin is on, that role has no real work left, but it still has to belong to a live DC.

Pause and think: the DC holding the RID master has been switched off for a weekend. Can the help desk still create users on Monday morning?

Almost certainly yes. Every DC already holds its own pool of RIDs, so new users keep working until a DC uses up its pool. That's why a dead RID master can go unnoticed for a while - and why "it still works" isn't proof the roles are healthy.

Find the current role holders

Before you move anything, you need to know where everything is now. One command shows all five.

This lists the holder of every role, and works on any DC or machine with the AD tools:

netdom query fsmo

Expect five lines - Schema master, Domain naming master, PDC, RID pool manager, Infrastructure master - each followed by a DC name such as DC1.corp.learnitlessons.com, then The command completed successfully.

If you'd rather have objects you can use in a script, this reads the forest-wide pair and the domain-wide three:

Get-ADForest | Format-List SchemaMaster, DomainNamingMaster
Get-ADDomain | Format-List PDCEmulator, RIDMaster, InfrastructureMaster

In the GUI the roles are split across three consoles: Active Directory Users and Computers for the three domain roles, Active Directory Domains and Trusts for the domain naming master, and the Active Directory Schema snap-in for the schema master. I'd use the PowerShell lines; they're quicker than opening all three.

Transfer roles while both DCs are online

So now you know the holders. A transfer is the planned move: maintenance on DC1, retiring an old server, or rebalancing. Both DCs are up, the old holder hands over its latest state, and nothing is lost.

This moves the PDC emulator and RID master to DC2. -Identity is the DC that will receive the roles, which catches people out:

Move-ADDirectoryServerOperationMasterRole -Identity 'DC2' -OperationMasterRole PDCEmulator, RIDMaster
netdom query fsmo

Answer A (Yes to All) at the confirmation prompt. netdom should now show DC2 against PDC and RID pool manager, and DC1 against the other three.

The role can also be given by number - 0 PDC emulator, 1 RID master, 2 infrastructure master, 3 schema master, 4 domain naming master. This puts both back on DC1:

Move-ADDirectoryServerOperationMasterRole -Identity 'DC1' -OperationMasterRole 0, 1

One step people forget: the time configuration doesn't travel with the role. If you move the forest root PDC emulator, point the new holder at an external time source and set the old one back to the domain hierarchy:

# on the new PDC emulator
w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:manual /reliable:yes /update
# on the old one
w32tm /config /syncfromflags:domhier /reliable:no /update

w32tm /query /status on the new holder should then show the external source after the next sync.

Seize roles when the holder is gone for good

A transfer needs the old holder to answer. When its hardware has died and it won't be restored, you seize instead - and that's a different decision, not a faster transfer.

This seizes all five roles on DC2 while DC1 is down for good:

Move-ADDirectoryServerOperationMasterRole -Identity 'DC2' `
    -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force
netdom query fsmo

Give it a minute or two to finish. When it does, netdom lists DC2 for all five. Seizing the RID master also makes the new holder skip ahead in the RID range - Microsoft documents a jump of 30,000 for this cmdlet - so no SID is ever handed out twice. That's also why you seize the RID master only when the old holder really isn't coming back.

Then comes the rule I never bend: a DC you seized roles from must never come back online as it was. Remove its metadata - in Users and Computers, delete its object under Domain Controllers and tick the box saying it's permanently offline - check that it's gone from Sites and Services and DNS, and if the hardware is repaired, wipe it and promote it as a new DC.

If DC1 is only down for a two-hour reboot, do neither. Wait.

Common mistake: trying to seize in the GUI

What it looks like: in Users and Computers, Operations Masters > Change fails with an error saying the transfer can't be done because the current role holder can't be contacted, and the role stays where it was.

Why it happens: the consoles can only transfer. A transfer needs the old holder to answer, and a dead DC never will.

The fix: seize from PowerShell with -Force, or with ntdsutil (roles, connections, connect to server DC2, q, then seize pdc and so on). Then clean up the old DC's metadata as above and confirm with netdom query fsmo.

FAQ

Does a read-only domain controller hold FSMO roles?

No. An RODC can't hold any operations master role, so there's never anything to transfer from or seize on one.

Will users notice if the PDC emulator is down?

Often sooner than with any other role: a user who has just changed a password can be refused by a DC that hasn't received the change yet, lockouts behave oddly, and clocks start to drift. It's the first role I'd move to a healthy DC.

Is "FSMO" still the right name?

Microsoft's documentation now says "operations master roles, formerly known as FSMO roles", but the tools (netdom query fsmo) and most admins still say FSMO.

Should I seize the roles while the old DC is just rebooting?

No. Seize only when the old holder won't return. A short outage costs you nothing; a seizure followed by the old DC coming back can.

Go deeper

The course covers what operations masters are, transferring and seizing roles, and a FSMO roles demonstration, with knowledge checks after each. It sits inside a much wider AD and Windows Server path - deploying DCs from Server Manager, Server Core, media and cloning, DC deployment and FSMO management, and NTDSUTIL with DSRM password management.