How to Transfer or Seize FSMO Roles in Active Directory

Active Directory is built around multi-master replication — any domain controller can accept a change and replicate it out. That works beautifully for most operations, but a handful of jobs would break if two DCs tried to do them at the same time. Those jobs are handed to a single DC through what Microsoft calls Flexible Single Master Operations, or FSMO roles.

Most of the time you never think about them. They sit quietly on whichever DC happened to hold them, and the domain runs fine. The moment they matter is when you’re decommissioning a DC, recovering from a dead one, or troubleshooting why password changes suddenly stopped working.

This guide covers all five roles, how to move them cleanly when both DCs are up (transfer), and how to force the move when the holder is gone for good (seize) — plus the one rule that, if you break it, will ruin your weekend.

The five FSMO roles and what they do#

There are five roles, split across two scopes. Two are forest-wide (one per forest) and three are domain-wide (one set per domain). In a single-domain forest you have all five on one or two DCs; in a multi-domain forest you’ll have the two forest roles once and the three domain roles repeated in each domain.

A couple of these deserve extra attention because they’re the ones you’ll feel if they go missing.

The PDC Emulator is the busiest. It’s the root of the domain’s time hierarchy, it’s where recent password changes are checked before an account is rejected, and it’s the DC the Group Policy editor connects to by default. Lose it and users start getting failed logons after password resets, time drifts, and admins trip over GPO edit conflicts.

The RID Master is quieter but important over time. Every DC gets a pool of RIDs to build new security principals. If the RID Master is down long enough for a DC to exhaust its pool, that DC can’t create new users, groups, or computers until it gets a fresh block.

First, find out who holds the roles#

Before you move anything, confirm where the roles currently live. From any domain-joined machine with the AD tools:

netdom query fsmo

Or in PowerShell, which splits forest and domain roles cleanly:

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

Write down the results. If you’re recovering from a failure, this tells you exactly which roles are orphaned and need to move.

Transfer vs seize: pick the right one#

This is the decision that matters most, so be clear about it before you touch anything.

A transfer is a graceful, agreed handoff. Both the current holder and the target DC are online and talking to each other. The role moves cleanly, replication stays consistent, and nothing is lost. This is what you use for planned work: rebalancing roles, or moving them off a DC you’re about to retire.

A seize is a forced takeover. You use it only when the current role holder is permanently dead — failed hardware, a corrupted OS, a DC that will never boot again — and you can’t wait for it to come back. Seizing tells the target DC to assume the role unilaterally, without the old holder’s agreement.

flowchart TD
A["FSMO role needs to move"] --> B{"Is the current<br/>holder online<br/>and healthy?"}
B -->|Yes| C["TRANSFER<br/>graceful handoff"]
B -->|"No, but it can be fixed"| D["Fix it, then transfer"]
B -->|"No, gone for good"| E["SEIZE<br/>forced takeover"]
E --> F["Never reconnect<br/>the old DC"]

How to transfer FSMO roles (the graceful way)#

You have two clean options: PowerShell or the GUI. PowerShell is faster and scriptable, so it’s the one most admins reach for now.

Transfer with PowerShell#

Move-ADDirectoryServerOperationMasterRole handles transfers. Point it at the target DC (the one that should receive the roles) and list the roles you want to move:

# Move all five roles to DC02
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC02" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster

You can also use the role index numbers (0 = PDCEmulator, 1 = RIDMaster, 2 = InfrastructureMaster, 3 = SchemaMaster, 4 = DomainNamingMaster) if you prefer:

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole 0,1,2,3,4

It’ll prompt for confirmation per role. When it returns without error, run netdom query fsmo again to confirm the move stuck.

Transfer with the GUI#

If you’d rather click through it, the roles are split across three consoles:

• Active Directory Users and Computers → right-click the domain → Operations Masters covers RID, PDC, and Infrastructure.
• Active Directory Domains and Trusts → right-click the root → Operations Master for the Domain Naming Master.
• Active Directory Schema snap-in (you may need to register it with regsvr32 schmmgmt.dll) for the Schema Master.

In each console you first point the snap-in at the DC you want to receive the role, then click Change. It’s the same operation as PowerShell, just slower.

How to seize FSMO roles (after a DC has died)#

When the role holder is truly gone, you seize. The classic tool is ntdsutil, and PowerShell can do it too with the same Move- cmdlet plus a -Force flag.

Before you seize anything, be honest about the state of the dead DC. Seizing assumes it will never come back.

Seize with PowerShell#

The same cmdlet seizes when you add -Force and the current holder is unreachable:

# Seize all roles onto DC02 because the old holder (DC01) is dead
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC02" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster `
  -Force

PowerShell will attempt a graceful transfer first and only seize if the holder can’t be reached, which is exactly the behavior you want.

Seize with ntdsutil#

ntdsutil is the traditional method and still works on every supported server version. Run it elevated on the DC that should take the roles:

ntdsutil
  roles
  connections
    connect to server DC02
    quit
  seize schema master
  seize naming master
  seize RID master
  seize PDC
  seize infrastructure master
  quit
quit

For each seize command, ntdsutil first tries a graceful transfer, then falls back to a forced seizure if the old holder is unreachable. Confirm each prompt. When you’re done, verify with netdom query fsmo.

After a seizure, there’s cleanup to do. The dead DC’s metadata is still in the directory and has to be removed before you can reuse its name or fully trust your topology.

The metadata cleanup and DNS scrubbing steps are the same ones you’d run when retiring any DC. We cover them in detail in how to decommission an old domain controller safely, which is worth reading alongside this if you’re cleaning up after a failure.

Where should the roles live?#

There’s no single correct layout, but a few sensible defaults hold up well:

• In a single-domain forest, keeping all five roles on one healthy, well-resourced DC is perfectly fine and easy to reason about. Just make sure you have a second DC ready to take over.
• Keep the PDC Emulator on a reliable, well-connected DC, ideally in your primary site, since it carries time and authentication load.
• In multi-domain forests, mind the Infrastructure Master / Global Catalog rule from earlier.
• Document where the roles are. The worst time to figure out your FSMO layout is in the middle of an outage.

Wrapping up#

FSMO roles aren’t complicated once you separate the two scenarios. For planned work — rebalancing or retiring a DC — you transfer, both DCs agree, and nothing is at risk. For a dead role holder that’s never coming back, you seize, then you clean up the metadata and you keep that old DC off the network forever.

If you remember one thing, make it that last point: a seized DC that comes back online is the fastest way to turn a recoverable failure into a directory mess. Default to transfer, seize only when you must, and document where your roles live before you ever need to move them.