FSMO Roles in Active Directory: The 5 Roles and What Happens If One Dies

Active Directory replicates almost everything in a multi-master model — create a user on DC2 and a few seconds later that object exists on DC1, DC3, and every other DC in the domain. Five operations cannot be allowed to work that way, because they would race themselves into corruption. Those five are the FSMO roles — Flexible Single Master Operations. Only one DC at a time holds each role, and that DC is the only one allowed to perform that operation.

This post walks through what each of the five roles does, the failure mode you see when the role holder is offline, and the practical rules for placing, transferring, and seizing them.

What FSMO actually means

The flexibility in the name simply refers to the fact that you can move a role from one DC to another — the role is not permanently fused to the DC that first held it. “Single master” is the load-bearing part: at any given moment, exactly one DC in the forest (or domain) is the master for that operation.

There are five roles in total — two are forest-wide, three are domain-wide.

A single-domain forest has five role holders in total. A forest with three domains has the two forest-wide roles plus three copies of each domain-wide role — eleven role holders in all.

Schema Master — the forest blueprint

The Schema Master is the only DC in the forest authorized to modify the AD schema. The schema defines every object class (user, computer, group, contact, …) and every attribute those objects can carry. Modifications are rare — you only touch the schema when installing a product that extends AD (Exchange, Skype for Business, Configuration Manager, certificate services with custom templates) or when running adprep /forestprep ahead of upgrading domain controllers to a newer Windows Server version.

What breaks when it is offline

Day-to-day AD is unaffected — users log in, GPOs apply, replication continues. Schema-extending installers fail mid-run with an error like “Schema update failed” or “The role owner is unavailable.” Domain controller promotion of a newer version may also fail if the schema has not been prepared.

Because changes are so rare, the Schema Master typically lives on a quiet DC in the forest root. You can run for weeks with the role offline and not notice — until upgrade day.

Domain Naming Master — the forest registrar

The Domain Naming Master is the only DC in the forest allowed to add or remove domains, and the only DC allowed to create or remove cross-forest trusts. It guards uniqueness — when you click Add a new domain to an existing forest, the wizard contacts this DC to verify the proposed name does not already exist.

What breaks when it is offline

Existing domains keep functioning normally. New domain creation fails — the wizard reports “Unable to contact the domain naming master.” Cross-forest trusts also cannot be created until the role is restored or seized to another DC.

Like the Schema Master, this is a low-traffic role. Best practice is to keep it on the same DC as the Schema Master in the forest root. Both roles can ride on a modest server because they are used so rarely.

PDC Emulator — the busiest role

The PDC Emulator is the single most important domain-wide role. Despite the legacy-NT name, modern AD assigns it a long list of jobs:

• Authoritative time source. Every other DC in the domain syncs time from the PDC Emulator. Every member server and workstation syncs from its preferred DC, which transitively syncs from the PDC Emulator. The forest-root PDC Emulator is the apex.
• Password change replication. When a user changes their password, the new hash is sent to the PDC Emulator urgently — ahead of normal replication. If a user fails authentication on another DC, that DC re-checks against the PDC Emulator before returning an error, in case it has a stale password.
• Account lockout processing. Lockout state is checked against the PDC Emulator to give a single source of truth.
• GPO authoring default. Group Policy Management Console connects to the PDC Emulator by default for editing GPOs, preventing two admins from editing the same policy on different DCs and racing the SYSVOL.
• Legacy NT compatibility. The historical reason for the name. Still relevant if you have NT-era applications, which is rare in 2026 but not zero.

What breaks when it is offline

Time drift across the domain. Within 5 minutes the symptoms start: Kerberos authentication failures, certificate validation failures, application errors. Password changes do not replicate urgently — users who change their password on one DC and then try to log in via another may be refused. Account lockouts become inconsistent across DCs. The GPMC complains about being unable to contact the PDC Emulator.

The PDC Emulator must live on the most performant, best-connected DC in each domain. If you only have two DCs, the PDC Emulator goes on the one with the lowest-latency network connection to the bulk of users.

RID Master — the SID factory

Every security principal in AD (user, computer, group) has a SID. The SID is the domain SID with a RID (Relative Identifier) appended. RIDs come from a fixed-size 30-bit pool — about a billion of them per domain, exhausted only after literally billions of object creations.

The RID Master is the DC that hands out RID pools to other DCs. Each DC requests a slab of 500 RIDs at a time. When a DC’s pool drops below 50%, it asks the RID Master for the next slab. The RID Master serves the requests, then writes the new high-watermark back to AD.

What breaks when it is offline

Nothing immediate. DCs continue creating users, computers, and groups from the RIDs they already have. When a DC’s pool runs out, that specific DC can no longer create new security principals on its own — new-user creation fails with “the RID Master is unavailable.” The first DC to go silent is whichever was lowest in its pool when the RID Master went offline; the rest follow as their pools deplete.

For a typical AD, you have hours-to-days of warning before any DC actually runs out, which makes this the most tolerant of the five roles in terms of urgency.

Infrastructure Master — the cross-domain glue

The Infrastructure Master tracks references to objects in other domains. The classic case: a user from dom-a.lab.local is a member of a group in dom-b.lab.local. The group object in dom-b stores a phantom-reference (the user’s SID and DN) for the member. If the user is renamed, moved between OUs, or has their SID changed in dom-a, the reference in dom-b needs to be updated. The Infrastructure Master in dom-b is the DC that walks those phantom references and refreshes them.

The Global Catalog wrinkle — why placement matters

The Infrastructure Master’s job is to find objects it does not have a full copy of. A Global Catalog (GC) DC holds a partial copy of every object in every domain — meaning a GC has nothing to look up, because the data is already local. Putting the Infrastructure Master on a GC DC effectively neutralizes the role: it sees everything as already-up-to-date and stops bothering.

The rule: if all DCs in the domain are GCs (common in single-domain forests and small multi-domain forests), the Infrastructure Master role does nothing and the placement is irrelevant. If only some DCs are GCs, place the Infrastructure Master on a non-GC DC so it actually performs its function.

What breaks when it is offline

In a multi-domain forest with mixed-GC DCs, cross-domain group memberships start to go stale. A renamed user shows up under their old name in another domain’s group membership lists, and applications that rely on those references may break. In a single-domain forest with all DCs as GCs, you will never notice.

Finding the role holders

From any command prompt on a DC:

netdom query fsmo

Output looks like:

Schema master DC-01.lab.local
Domain naming master DC-01.lab.local
PDC DC-02.lab.local
RID pool manager DC-02.lab.local
Infrastructure master DC-03.lab.local

From PowerShell:

Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Or via the GUIs: Active Directory Schema MMC snap-in > right-click root > Operations Master shows Schema Master. Active Directory Domains and Trusts > right-click root > Operations Master shows Domain Naming Master. ADUC > right-click domain > Operations Masters has tabs for RID, PDC, and Infrastructure. You can view all roles from the GUIs but only transfer (not seize) from there.

Transferring vs seizing

Moving a role from one DC to another is a transfer when both DCs are online and healthy. The current role holder is asked to hand the role over; it does so gracefully and replication takes care of the rest. Both DCs agree on who holds the role afterwards.

If the current role holder is permanently offline — failed hardware, deleted VM, ransomware, no recovery path — you seize the role to another DC. Seizing skips the handshake; the new DC simply declares itself the holder. This is recoverable only if the old DC is never coming back. If it does come back online holding the same role, you have a split-brain situation: two DCs both claiming to own a single-master operation. The cure is to keep the old DC isolated from the network until you have demoted it (or, more aggressively, metadata-cleaned it from AD and rebuilt it).

Transferring with PowerShell

The modern way:

Move-ADDirectoryServerOperationMasterRole -Identity DC-02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

You can pass multiple roles in a single call. For forest-wide roles:

Move-ADDirectoryServerOperationMasterRole -Identity DC-01 -OperationMasterRole SchemaMaster, DomainNamingMaster

Seizing with PowerShell

Add -Force to the same cmdlet:

Move-ADDirectoryServerOperationMasterRole -Identity DC-02 -OperationMasterRole PDCEmulator -Force

You will see a warning that PowerShell first tries to transfer; if the source DC does not respond, the seize is performed. Either way, the destination DC ends up holding the role.

The old-school ntdsutil path

The historical method using ntdsutil still works on every supported version of Windows Server and is occasionally required in disaster scenarios where PowerShell on the destination DC cannot reach the source AD database. The command sequence is:

ntdsutil
roles
connections
connect to server DC-02
quit
seize pdc
quit
quit

Use the cmdlet path in normal operations. Use ntdsutil only when something is genuinely broken.

Placement — where to put each role

For most single-domain forests with 2-3 DCs all acting as GCs:

• Put Schema, Domain Naming, PDC, RID, and Infrastructure on the same DC. Single point of failure exists for all five, but they are also all on one DC you actively monitor.
• Keep your second/third DC current with replication so you can seize roles within minutes if the primary dies.

For larger or multi-domain forests:

• Schema and Domain Naming on a quiet forest-root DC.
• PDC and RID on the most performant DC in each domain.
• Infrastructure on a non-GC DC if any DC in the domain is not a GC; anywhere if all DCs are GCs.

Things that bite people

PDC Emulator dies and time drifts within 5 minutes

The most common operational pain. The PDC Emulator is the apex of the time hierarchy — if it is offline and nothing has been seized, member servers and workstations start drifting based on their CMOS clocks. Within 5 minutes Kerberos starts rejecting tickets. The fix is to seize the role to another DC immediately, then chase any drifted hosts with w32tm /resync /force. (See Hyper-V Time Sync Fix for the related Hyper-V quirk that compounds this problem.)

Infrastructure Master on a GC DC in a multi-domain forest

Silent failure mode. The Infrastructure Master appears to be running, but it never refreshes any cross-domain phantom references. Months later, group memberships across domains start showing stale names and old SIDs. The fix is to transfer the role to a non-GC DC. If you do not have one, make a DC stop advertising as a GC, wait for replication to settle, then transfer the role.

Seizing a role and then plugging the old DC back in

Catastrophic if undetected. Two DCs claiming the same single-master role corrupts replication and produces unpredictable behavior. After a seize, the old DC must be quarantined and rebuilt. If it ever needs to come back online, demote it cleanly from another DC first using ntdsutil metadata cleanup, then format and rebuild before joining the new AD.

Schema Master offline during a major product upgrade

The classic case: Exchange or SCCM installer runs, hits the schema-extension step, fails. Less obvious version: adprep /forestprep from a Windows Server 2022 ISO needs the Schema Master to apply the new schema version. If the Schema Master DC is decommissioned without first transferring the role, the next upgrade will fail until you seize and clean up.

RID Master deplete-and-die in a rapidly-growing AD

Rare but real. If the RID Master is offline and your DC fleet is creating thousands of objects per day (typical of large school deployments, MSP onboarding, or test automation farms), one DC after another stops being able to create principals. Monitor RID pool status with repadmin /showattr against the RID Manager$ object during onboarding bursts.

What’s next

FSMO roles are the single-master backbone underneath the multi-master replication system. The next post in the Active Directory pathway is the ADUC structure after the first DC deployment — the default containers and OUs you see when you first open Active Directory Users and Computers, why some are containers and not OUs, and what each one is actually for.