Operations master roles

99 out of 114 rated this helpful - Rate this topic

Updated: October 24, 2011
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1,
Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Operations master roles

Active Directory supports multimaster replication of the directory data store between all
domain controllers (DC) in the domain, so all domain controllers in a domain are essentially
peers. However, some changes are impractical to perform in using multimaster replication,
so, for each of these types of changes, one domain controller, called theoperations master,
accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or
more domain controllers. Forest-wide operations master roles must appear only once in
every forest. Domain-wide operations master roles must appear once in every domain in the
forest.
Note

The operations master roles are sometimes called flexible single master operations
(FSMO) roles.

Forest-wide operations master roles

Every forest must have the following roles:

Schema master

Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there
can be only one schema master and one domain naming master.

Schema master
The schema master domain controller controls all updates and modifications to the schema.
To update the schema of a forest, you must have access to the schema master. There can be
only one schema master in the entire forest.

Domain naming master

The domain controller holding the domain naming master role controls the addition or
removal of domains in the forest. There can be only one domain naming master in the entire
forest.
Note

Any domain controller running Windows Server 2003 can hold the role of the domain
naming master. A domain controller running Windows 2000 Server that holds the role
of domain naming master must also be enabled as a global catalog server.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

Relative ID (RID) master

Primary domain controller (PDC) emulator master

Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can
have only one RID master, PDC emulator master, and infrastructure master.

RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain
controllers in its domain. At any time, there can be only one domain controller acting as the
RID master in each domain in the forest.
Whenever a domain controller creates a user, group, or computer object, it assigns the
object a unique security ID (SID). The SID consists of a domain SID, which is the same for all
SIDs created in the domain, and a RID, which is unique for each SID created in the domain.
To move an object between domains (using Movetree.exe), you must initiate the move on
the domain controller acting as the RID master of the domain that currently contains the
object.

PDC emulator master

The PDC emulator master processes password changes from client computers and replicates
these updates to all domain controllers throughout the domain. At any time, there can be
only one domain controller acting as the PDC emulator master in each domain in the forest.
The PDC emulator role is used in the following ways:

To provide consistent password experience for users across sites (can be turned off
with AvoidPdcOnWan registry parameter) - The PDC emulator is used as a reference
DC to double-check incorrect passwords and it also receives new password changes.
When the PDC is reachable, users can use a new password immediately and
consistently across the environment. For more information about AvoidPdcOnWan
see, New Password Change and Conflict Resolution Functionality in
Windows(http://go.microsoft.com/fwlink/?LinkId=202451)

As a preferred point of administration for services (examples are Group Policy and
Distributed File System, DFS) - For more information about DFS see, DFS
Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information
about DCs and Group Policy see, Specifying a Domain Controller for Editing Group
Policy (http://go.microsoft.com/fwlink/?LinkId=202457).

As a point of contact for applications hard-coded to the PDC (often written for
Windows NT 4.0 and older domains) - The legacy API often used for this is
NetGetDcName. It is strongly suggested to change applications to use the new API to
locate DCs. DsGetDcName by default does not target the PDC, and has more options
that allows you to pick the type of DC needed to perform the operation. For more

information about locating DCs from applications see, DSGetDcName

Function (http://go.microsoft.com/fwlink/?LinkId=202455).

As a default time server for all other DCs in the domain - The time server
configuration of a PDC requires manual consideration and should be reviewed when
you change the owner of the PDC role.

The domain controller configured with the PDC emulator role supports two authentication
protocols:

The Kerberos V5 protocol

The NTLM protocol

Note

For instructions on how to configure the PDC emulator to synchronize with an external time source, see Synch
Controller with an External Source (http://go.microsoft.com/fwlink/?LinkId=122513).

Infrastructure master
At any time, there can be only one domain controller acting as the infrastructure master in
each domain. The infrastructure master is responsible for updating references from objects
in its domain to objects in other domains. The infrastructure master compares its data with
that of a global catalog. Global catalogs receive regular updates for objects in all domains
through replication, so the global catalog data will always be up to date. If the infrastructure
master finds data that is out of date, it requests the updated data from a global catalog. The
infrastructure master then replicates that updated data to the other domain controllers in
the domain.
Important

Unless there is only one domain controller in the domain, the infrastructure master
role should not be assigned to the domain controller that is hosting the global
catalog. If the infrastructure master and global catalog are on the same domain
controller, the infrastructure master will not function. The infrastructure master will
never find data that is out of date, so it will never replicate any changes to the other
domain controllers in the domain.
In the case where all of the domain controllers in a domain are also hosting the global
catalog, all of the domain controllers will have the current data and it does not matter
which domain controller holds the infrastructure master role.

The infrastructure master is also responsible for updating the group-to-user references
whenever the members of groups are renamed or changed. When you rename or move a
member of a group (and that member resides in a different domain from the group), the
group may temporarily appear not to contain that member. The infrastructure master of the
group's domain is responsible for updating the group so it knows the new name or location

of the member. This prevents the loss of group memberships associated with a user account
when the user account is renamed or moved. The infrastructure master distributes the
update via multimaster replication.
There is no compromise to security during the time between the member rename and the
group update. Only an administrator looking at that particular group membership would
notice the temporary inconsistency