AD DS is multi-master: any writable DC accepts changes. Some operations can’t safely be multi-master, so they are handled by a single DC holding an operations master role, still widely called a Flexible Single Master Operations (FSMO) role.
The five roles
| Role | Scope | What it does | Must be available when |
|---|---|---|---|
| Schema master | One per forest | Only DC that can write schema changes (adprep /forestprep, application schema extensions) |
Schema is updated |
| Domain naming master | One per forest | Adds and removes domains and application partitions (including DNS application partitions) | Domains or partitions are added or removed |
| PDC emulator | One per domain | Receives password changes preferentially; final check for bad passwords; processes account lockout; default DC targeted for Group Policy updates; time source for the domain (forest root PDC is the forest time source) | Always: it should be online all the time |
| RID master | One per domain | Allocates pools of relative IDs to DCs so every SID is unique; moves objects between domains | New DCs promote; DCs need a new RID pool |
| Infrastructure master | One per domain (and per application partition) | Updates cross-domain references (SIDs and distinguished names) | Rarely critical |
The first DC in a new forest gets all five roles; the first DC of each additional domain gets the three domain roles. Roles move only when an administrator transfers or seizes them, or when a role holder is gracefully demoted (the wizard hands its roles to another DC). Figure 1.1 shows which roles exist once per forest and which exist in every domain.
Infrastructure master and the global catalog
The infrastructure master should not be on a global catalog server in a multi-domain forest unless every DC in its domain is a GC, because a GC already holds a partial replica of every object and so never notices stale cross-domain references. The role has no work to do when:
- the forest has a single domain, or
- every DC in the domain is a GC, or
- the AD Recycle Bin is enabled (each DC then updates its own cross-domain references).
Microsoft still recommends defining a proper role owner to avoid warnings from monitoring tools.
Placement guidance
- Put the schema master and domain naming master on the forest root domain’s PDC emulator.
- Put the PDC emulator on reliable, well-specified hardware in a hub site with other DCs of the same domain; all DCs in the domain need network access to it.
- Put the RID master on the same DC as the domain’s PDC emulator; newly promoted DCs, including those in staging sites, need to reach it.
- Designate a direct intra-site replication partner of each role holder as the standby operations master, so a transfer or seizure targets an up-to-date DC.
- RODCs can’t hold any role.
To find the current holders, use netdom query fsmo, Get-ADDomain (PDC emulator, RID master, infrastructure master) and Get-ADForest (schema master, domain naming master), or the Operations Masters dialogs in Active Directory Users and Computers, Active Directory Domains and Trusts, and the Active Directory Schema snap-in.
Common trap: Placing the infrastructure master on a global catalog server in a multi-domain forest where some DCs are not GCs - it stops updating cross-domain references because the GC never sees them as stale; either host it on a non-GC DC or make every DC in the domain a GC.