How Operations Masters Work

Updated: June 08, 2005

In this section
• Operations Masters Protocols
• Operations Masters Roles and Functionality
• Role Transfer and Seizure
• Network Ports Used by Operations Masters
• Related Information
Active directory is a multimaster enabled database, which provides the flexibility of allowing
changes to the directory to occur at any domain controller. However, some changes, if performed in
a multimaster fashion, can cause errors in the Active Directory database. For these changes, one
domain controller, called an operations master, is assigned to accept requests for such changes.
Operations masters perform updates to the directory in a single-master fashion, meaning that only
the domain controller assigned to hold the operations master role is allowed to process the update.
This single-master update model prevents conflicting updates from being made to the Active
Directory database.
Five operations masters are assigned to perform specific tasks in an Active Directory environment.
The schema master and the domain naming master are forestwide roles, meaning that only one of
each of these types of operations masters is in a forest. The relative identifier (RID) master,
infrastructure master, and primary domain controller (PDC) emulator master are domainwide roles,
meaning one of each of these types of operations masters is in each domain in a forest.
Because operation masters are used to perform specific tasks and are important to the performance
of the directory, they must be available to all domain controllers and directory clients that require
their services.
This section describes the functionality and interactions of each operations master in a Windows
Server 2003 Active Directory environment.

Operations Master Protocols

Operations masters use the same protocols as other Active Directory domain controllers. The
protocols that package the data sent to and from a domain controller are described in the following
table.
Operations Master Protocols

Protocol Description

Lightweight The primary directory service protocol that specifies directory communications. It runs directly over
directory access TCP/IP, and it can also run over UDP connectionless transports (UDP access is primarily used by the
protocol (LDAP) domain controller Locator process). Clients use LDAP to query, create, update, and delete information that
is stored in a directory service over a TCP connection through the TCP port 389. Active Directory supports
LDAP v2 (RFC 1777) and LDAP v3 (RFC 2251). LDAP v3 is an industry standard that can be used with
any directory service that implements the LDAP protocol. LDAP is the preferred and most common way of
interacting with Active Directory.

Remote procedure Protocol for replication (REPL), domain controller management communications, and SAM-related
call (RPC) communications. RPC is a powerful, robust, efficient, and secure interprocess communication (IPC)
mechanism that enables data exchange and invocation of functionality residing in a different process. That
Protocol Description

different process can be on the same computer, on the local area network (LAN), or across the Internet.

Simple mail Protocol for replication communications when a permanent, “always on” network connection does not exist
transfer protocol between two domain controllers. SMTP is used to transport and deliver messages based on specifications in
(SMTP) Request for Comments (RFC) 821 and RFC 822. SMTP can replicate configuration, schema, and global
catalog replicas only (not writable domain data).
For more information about Active Directory protocols, see “How the Data Store Works .”
Top of page
Operations Master Roles and Functionality
Five operations master roles manage single-master operations in Active Directory.
Two operations master roles exist in each forest:
• The schema master, which governs all changes to the schema.
• The domain naming master, which adds and removes domains to and from the forest.
In addition to the two forestwide operations master roles, three operations master roles exist in
each domain:
• The primary domain controller (PDC) emulator. The PDC emulator processes all replication requests from Microsoft
Windows NT 4.0 backup domain controllers and processes all password updates for clients that are not running Active
Directory–enabled client software.
• The relative identifier (RID) master. The RID master allocates RIDs to all domain controllers to ensure that all security
principals have a unique identifier.
• The infrastructure master. The infrastructure master for a given domain maintains a list of the security principals from
other domains that are members of groups within its domain.

Schema Master
The schema master controls all originating updates to the schema. The schema contains the master
list of object classes and attributes that are used to create all Active Directory objects, such as
computers, users, and printers. The domain controller that holds the schema master role is the only
domain controller that can perform write operations to the directory schema. These schema updates
are replicated from the schema operations master to all other domain controllers in the forest.

Domain Naming Master

The domain naming master is a forestwide operations master role because it manages the addition
and removal of all directory partitions, regardless of domain, in the forest hierarchy. The domain
controller that has the domain naming master role must be available in order to perform the
following actions:
• Add or remove domains.
• Add or remove application directory partitions.
• Add or remove cross-reference objects.
• Validate domain rename instructions.
Add or Remove Domains
Only the domain controller holding the domain naming master role has the authority to add a new
domain. The domain naming master manages this process, preventing multiple domains from
joining the forest with the same domain name. When you use the Active Directory Installation
Wizard to create or remove a child domain, it contacts the domain naming master and requests the
addition or deletion. The domain naming master is responsible for ensuring that domain names are
unique. If the domain naming master is unavailable, you cannot add domains or remove them from
the forest.
Add or Remove Application Directory Partitions
Application directory partitions are special partitions that can be created on domain controllers
running Windows Server 2003 to provide LDAP storage for dynamic data. In Windows 2000 Server,
nondomain data is limited to configuration and schema data, which is replicated to every domain
controller in the forest. In a Windows Server 2003 forest, application directory partitions provide
storage for nondomain, application-specific data that can be replicated to any arbitrary set of
domain controllers in the forest — as few or as many as needed by the application that uses the
data.
The Domain Name System (DNS) creates and uses application directory partitions by default when
it is installed in a Windows Server 2003 forest. DNS automatically creates two default DNS
application directory partitions below the forest root domain in the domain hierarchy, one for the
forest (ForestDnsZones) and one for the domain (DomainDnsZones). Thereafter, when you install
Active Directory to create a new domain in the forest and configure that server to be a DNS server,
DNS creates one default application directory partition below the new domain directory partition in
the domain hierarchy.
If the domain controller hosting the domain naming operations master role is not running Windows
Server 2003, or if it is unavailable, you cannot add or remove application directory partitions from
the forest.
Add or Remove Cross-Reference Objects
When Active Directory is installed to create the first domain controller in a new forest, the schema,
configuration, and domain directory partitions are created on the domain controller. At this time, a
cross-reference object (class crossRef) is created for each directory partition in the Partitions
container in the configuration directory partition
(CN=partitions,CN=configuration,DC=forestRootDomain). Creation of each subsequent directory
partition in the forest, either by installing Active Directory to create a new domain or by creating a
new application directory partition on an existing domain controller, initiates the creation of an
associated cross-reference object in the Partitions container.
Note
• You can also manually create a cross-reference object for an application directory
partition.
A cross-reference object identifies the name and server location of each directory partition in the
forest. The replication system uses this information to identify servers that store the same directory
partitions. LDAP queries use cross-reference objects to create referrals to different domains. If the
domain naming master is unavailable, you cannot add or remove cross-reference objects.
Validate Domain Rename Instructions
When you use the domain rename tool, rendom.exe, to rename an Active Directory domain, the tool
must be able to access the domain naming operations master. The domain naming master is the
domain controller responsible for validating the instructions that the domain rename tool has
generated for the new forest.
Certain changes occur on the domain naming master in preparation for the actual execution of a
domain rename. On the domain naming master, the XML-encoded script containing the domain
rename instructions is written to the msDS-UpdateScript attribute on the Partitions container
object (cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory
partition. The Partitions container can only be updated on the domain controller holding the domain
naming operations master role for the forest. Therefore, the msDS-UpdateScript attribute must be
changed on the domain naming master.
In addition to the msDS-UpdateScript attribute value being written to the Partitions container, the
new DNS name of each domain being renamed is also written by rendom.exe to the msDS-
DnsRootAlias attribute on the cross-reference object (class crossRef) corresponding to that
domain. Again, because cross-reference objects are stored in the Partitions container and the
Partitions container can only be updated on the domain naming master, the msDS-DnsRootAlias
attribute can only be changed on the domain naming operations master.
The domain naming master replicates the script stored in the msDS-UpdateScriptattribute and the
DNS name in the msDS-DnsRootAlias attribute to all domain controllers in the forest through
scheduled replication of the configuration directory partition.
In preparation of a domain rename operation; rendom.exe uses the domain naming operations
master to:
• Retrieve all information needed to compute the list of rename instructions for updating the configuration and schema
directory partitions.
• Write the resulting script to the msDS-UpdateScript attribute of the Partitions container.
• Change the msDS-DnsRootAlias attribute of all cross-reference objects for domains that are being renamed.
• Validate the forest description against the current state of the forest. If any of these validity checks fails, the command
fails. The following requirements are verified:
• Each existing domain is part of the new forest.
• The new forest is well formed.
• The new forest does not re-assign domain names that are being relinquished as part of the current domain rename
operation.
For more information about domain rename, see “Domain Rename Technical Reference .”

Relative Identifier Master

The relative identifier (RID) master is a domainwide operations master role. The RID master is
responsible for allocating sequences of unique RIDs to each domain controller in its domain and for
moving objects from one domain to another.
You can create a new security principal object (user, group, or computer) on any domain controller.
When you create a security principal object, the domain controller attaches a unique Security ID
(SID) to the object. There are four elements of a domain SID, one of which is the RID for the
domain.
The following table describes the elements of the domain SID: S-1-5-Y1-Y2-Y3-Y4.
Elements of a Security Identifier (SID)

SID
Description
element

S-1 Indicates a revision 1 SID. At this time 1 is the only SID revision in use.

5 Indicates the issuing agency or issuing authority. A 5 always indicates Windows NT, Windows 2000 Server, or
Windows Server 2003 domains. Note that a well-known SID may use a 1 or 0 as the issuing identity to signify
that it is a well known SID.

Y1-Y2-Y3 The domain identifier portion of the SID. This is the same for every security principal object created in that
domain.

Y4 The relative ID (RID) for the domain, which represents a user name or group. This is obtained from the RID
pool on a domain controller at the time the object is created.
RID Allocation
Domain controllers running Windows 2000 and Windows Server 2003 have a shared RID pool. The
RID operations master is responsible for maintaining a pool of RIDs to be used by the domain
controllers in its domain and for providing groups of RIDs to each domain controller when
necessary. When a new domain controller running Windows 2000 or Windows Server 2003 is added
to the domain, the RID master allocates a batch of approximately 500 RIDs from the domain RID
pool to that domain controller. Each time a new security principal is created on a domain controller,
the domain controller draws from its local pool of RIDs and assigns one to the new object. When the
number of RIDs in a domain controller’s RID pool falls below approximately 100, that domain
controller submits background requests (by means of RPC) for additional RIDs from the domain’s
RID master. The RID master allocates a block of approximately 500 RIDs from the domain’s RID
pool to the pool of the requesting domain controller.
The RID master does not actually maintain a pool of numbers. Rather, it maintains the highest
value of the last range it allocated. When a new request is received, it increments that value by one
to establish the low value in the new RID pool and then adds four hundred and ninety nine to
establish the new maximum value. It sends these two values to the requesting domain controller to
use as its next allocation of RIDs.
If a domain controller’s local RID pool is empty, and it cannot contact the domain’s RID master to
request additional RIDs, the domain controller will log event ID 16645, indicating that the maximum
account identifier allocated to the domain controller has been assigned and the domain controller
has failed to obtain a new identifier pool from the RID master. Likewise, when attempting to add
new objects in Active Directory, such as users, computers, or domain controllers, you might notice
event ID 16650 in the System log indicating that the object cannot be created because the directory
service was unable to allocate a relative identifier. Network connectivity to the RID master might
have been lost or the RID master might have been removed from the network. In any case, you
cannot create new security principal objects on the domain controller until RID pool acquisition is
successful.
Cross-Domain Moves
Migrating Active Directory objects from one domain to another requires the availability of the RID
master. You can only move an object out of its domain if the domain’s RID master can be
contacted. Requiring that objects be moved from one domain to another by using the RID master
prevents Active Directory from creating two objects in different domains with the same unique
identifier. This might happen if one object is moved from two domain controllers simultaneously to
two different domains.
You can use the Active Directory Migration Tool (ADMT) to perform intraforest migrations of domain
objects from one domain (the source domain) to another (the target domain). The RID master must
be online and available in the source domain for ADMT to migrate successfully. If the RID master is
unavailable, cross-domain migration of Active Directory objects will fail.
RID Attributes in Active Directory
The following are RID-related attributes in Windows Server 2003 Active Directory:

FsmoRoleOwner
DN path: CN=RID Manager$,CN=System,DC=<domain>,DC=com
This attribute points to the Domain Name path for the current RID master’s NTDS Settings object
according to the domain controller that is being queried.

RidAvailablePool
DN path: CN=RID Manager$,CN=System,DC=<domain>,DC=com
This attribute defines the global RID space from which RID pools are allocated to the RID master.
RidAllocationPool
DN Path: CN=Rid Set,CN=<computername>,OU=domain controllers,DC=<domain>,DC=com
Each domain controller has two RID pools: the one that they are currently allocating from, and the
pool that they will use next. This attribute defines the RID pool that will be used in the domain when
the current RID pool is exhausted.

RidNextRid
DN Path: CN=Rid Set,CN=<computername>,OU=domain controllers,DC=<domain>,DC=com
This attribute defines the next free RID in the current allocation pool that is assigned to the next
security principal created on the local domain controller. RidNextRid is a non-replicated value in
Active Directory.

RidPreviousAllocationPool
DN Path: CN=Rid Set,CN=<computername>,OU=domain controllers,DC=<domain>,DC=com
This attribute defines the RID pool from which the RID master actually allocates from. The value for
RidNextRid is implicitly a member of this pool.

RidUsedPool
DN Path: CN=Rid Set,CN=<computername>,OU=domain controllers,DC=<domain>,DC=com
This attributed defines the RID pools that have been used by a domain controller.

NextRid
DN Path: DC=<domain>,DC=com
This attribute defines the next RID field used by the RID master.

Primary Domain Controller (PDC) Emulator

The PDC emulator serves as primary domain controller for compatibility with earlier Windows
operating systems. Windows 2000 Server and Windows Server 2003 interoperate with
Windows NT workstations, member servers, and backup domain controllers. The primary domain
controller (PDC) in a Windows NT 3.51 or Windows NT 4.0 domain is responsible for the following:
• Processing password changes from both users and
computers
• Replicating updates to backup domain controllers
• Running the Domain Master Browser
Active Directory uses multimaster replication for most directory updates, including password
changes. Therefore, if the PDC emulator becomes unavailable, the impact is small. However, in a
mixed environment with Windows NT–based domain controllers and Active Directory, the
unavailability of the PDC emulator has the following impact:
• When a user of a computer running Windows NT Workstation 4.0, Windows 95, or Windows 98 without the Active
Directory client installed attempts a password change, the user sees a message similar to the following: “Unable to change
password on this account. Please contact your system administrator.”
• In a mixed domain, the event logs of Windows NT 4.0 BDCs contain entries showing failed replication attempts.
• In a mixed domain, when a user tries to start User Manager on a Windows NT 4.0 backup domain controller, it results in a
“domain unavailable” error message. If User Manager is already running, you will see an “RPC server unavailable”
message. Attempting to create an account by using the net user /add command results in a “could not find domain
controller for this domain” message. When you run Server Manager, you will see a message similar to the following:
“Cannot find the primary domain controller for <domain name>. You may administer this domain, but certain domain-
wide operations will be disabled.”
As operating systems are upgraded, either to Windows XP, Windows 2000, Windows Server 2003,
or (for Windows NT Workstation 4.0, Windows 95, and Windows 98) by installing the Active
Directory client, they cease to rely on the PDC and, instead, behave in the following manner:
• Clients do not make password changes at the PDC emulator. Instead, clients update passwords at any domain controller in
the domain.
• The PDC emulator does not receive Windows NT 4.0 replication requests after all Windows NT 4.0 BDCs in a domain are
upgraded to Windows 2000 Server or Windows Server 2003.
• Clients use Active Directory to locate network resources. They do not require the Computer Browser service.
After all computers are upgraded to Windows XP, Windows 2000 and Windows Server 2003, the
domain controller holding the PDC emulator role performs the following functions:
• When password changes are performed by other domain controllers in the domain, they are sent to the PDC emulator by
using higher priority replication.
• When an authentication fails with an invalid password at other domain controllers in the domain, the authentication request
is retried at the PDC emulator before failing. If a recent password update has reached the PDC emulator, the retried
authentication request should succeed.
• When an authentication succeeds for an account for which the most recent authentication attempt at the domain controller
failed, the domain controller communicates this fact (“zero lockout count”) to the PDC emulator. This resets the lockout
counter at the PDC emulator in case another client attempts to validate the same account by using a different domain
controller.
Therefore, when the PDC emulator is unavailable, you might experience an increase in support
requests regarding password difficulties. However, unlike the Windows NT 4.0 environment, where
the PDC was the only computer that wrote the updated password to the domain, in Windows 2000
Server and Windows Server 2003, any domain controller can write the password update to the
directory and normal replication will ensure that all domain controllers in the domain eventually
become aware of the change. This will occur even if the PDC emulator operations master remains
unavailable.
Windows Server 2003 Well Known Security Principals
In Windows Server 2003, the PDC emulator operations master is responsible for managing well-
known security principals. When you upgrade your environment from Windows 2000 Server, it is
important that you upgrade the PDC emulator early in the upgrade process so that the
“CN=WellKnown Security Principals,CN=Configuration,DC=<YourDomain>” container is updated
with the well-known security principals that are introduced in Windows Server 2003.
After upgrading the Windows 2000–based domain controller holding the role of the PDC emulator in
each domain in the forest to Windows Server 2003, several new well-known and built-in groups are
created and some new group memberships are established. If you transfer the PDC emulator role to
a Windows Server 2003–based domain controller instead of upgrading it, these groups will be
created when the role is transferred. The new well-known and built-in groups are:
• Builtin\Remote Desktop Users
• Builtin\Network Configuration Operators
• Performance Monitor Users
• Performance Log Users
• Builtin\Incoming Forest Trust Builders
• Builtin\Performance Monitoring Users
• Builtin\Performance Logging Users
• Builtin\Windows Authorization Access Group
• Builtin\Terminal Service License Server
The newly established group memberships are:
• If the Everyone group is in the Pre-Windows 2000 Compatible Access group, the Anonymous Logon group and
Authenticated Users group are also added to the Pre-Windows 2000 Compatible Access group.
• The Network Servers group is added to the Performance Monitoring Users group.
• The Enterprise Domain Controllers group is added to the Windows Authorization Access group.
In addition, when upgrading the Windows 2000–based domain controller that holds the role of the
PDC emulator in the forest root domain, the following additional security principals are created:
• LocalService
• NetworkService
• NTLM Authentication
• Other Organization
• Remote Interactive Logon
• SChannel Authentication
• This Organization
AdminSDHolder
The Administrator security descriptor holder protects administrative groups through a background
task that computes the set of memberships and checks whether their security descriptors are well-
known protected security descriptors. If the security descriptor of any administrative account does
not match that of AdminSDHolder, the security descriptor is overwritten with the security descriptor
of AdminSDHolder. This task is executed only on the domain controller that holds the primary
domain controller (PDC) emulator operations master role.
DNS and the PDC
The first domain controller deployed in every domain is automatically assigned the PDC emulator
role. During the Active Directory installation on this server, Net Logon registers the
_ldap._tcp.pdc._msdcs.DnsDomainName DNS SRV resource record that enables clients to locate the
PDC emulator. Only the PDC emulator of the domain registers this SRV resource record.
DFS and the PDC
When a change is made to a Distributed File System (DFS) domain-based namespace, the change is
made on the domain controller that acts as the PDC emulator master. DFS root servers that host
domain-based namespaces poll the PDC emulator periodically to obtain an updated version of the
DFS metadata, and then they store this metadata in memory. Therefore, if the domain controller
that holds the PDC emulator role is not available, DFS will not function properly.
For more information about DFS and the role of the PDC emulator, see "How DFS Works" on the

Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=48186.

Raising the Domain Functional Level
In Windows Server 2003, the functional level of a domain or forest defines the set of advanced
Windows Server 2003 Active Directory features that are available in that domain or forest. The
functional level of a domain or forest also defines the set of Windows operating systems that can
run on the domain controllers in that domain or forest.
The PDC emulator is the domain controller targeted when you raise the domain functional level of
an Active Directory domain. Therefore, the PDC emulator must be available to raise the domain
functional level. For more information about Windows Server 2003 domain and forest functional

levels, see “Active Directory Functional Levels Technical Reference .”

Infrastructure Master
The infrastructure master is responsible for updating the group-to-user references whenever the
members of groups are renamed or changed within a domain.
For example, suppose you use Active Directory Users and Computers to add a user to a group
within a single domain. While still connected to the same domain controller, you can view the
group’s membership and see the user you just added. If you then rename the user object (that is,
change its CN attribute) and then display the group membership, you instantly see the user’s new
name in the list of group members.
However, when the user and group are in different domains, there is a lag between the time when
you rename a user object and when a group containing that user displays the user’s new name. This
time lag is inevitable in a distributed system where sites function independently and must rely on
replication for changes to be distributed to all sites.
The domain controller holding the infrastructure master role for the group’s domain is responsible
for updating the cross-domain group-to-user reference to reflect the user’s new name. Periodically,
the infrastructure master scans the domain accounts and verifies the membership of the groups. If
a user account is moved to a new domain, the infrastructure master identifies the user account’s
new domain and updates the group accordingly. After the infrastructure master updates these
references locally, it uses replication to update all other replicas of the domain. If the infrastructure
master is unavailable, these updates are delayed.
Phantom Records
Whenever a domain controller contains a reference to an object in another domain, the domain
controller’s local database contains a phantom record for that object. Within the local database, a
reference to the object is represented as the database pointer to (in fact the primary key of) the
phantom record.
For example, if a user in domain A is a member of a group in domain B, the local database of a
domain controller in domain B, holding the group, contains a phantom record for that user. The
group references the user by pointing to the phantom. The infrastructure master is responsible for
updating the phantom records in its local database. If the distinguished name of the user in domain
A changes, the infrastructure master in domain B is responsible for updating its reference to the
user.
Each phantom record in the database contains the referenced object’s GUID, its SID (for references
to security principals), and its distinguished name. If the referenced object is renamed or moved, its
GUID does not change; its SID changes if the move is cross-domain, and its distinguished name
always changes.
The infrastructure master periodically examines the phantom records in its local database. It
compares the data in a phantom record to the corresponding data on the replica of the referenced
object contained in the global catalog. Because global catalog servers receive regular updates for all
objects in the forest through replication, the global catalog’s data is – allowing for replication
latency – always up to date. If the SID or the distinguished name in a phantom record does not
match the SID or the distinguished name of the object in the global catalog, then the infrastructure
master updates its local database with the values from the global catalog. The infrastructure master
then replicates the new values to the other domain controllers in its domain.
A global catalog server holds a complete replica of its own domain and a partial replica of every
other domain in the forest. The complete replica of its own domain includes the GUID, SID, and
distinguished name of the domain’s objects. The partial replica of another domain includes the
GUIDs, SIDs, and distinguished names of all the objects in that domain. Because this data exists in
the global catalog server’s local database, there are no phantom records representing cross-domain
object references on a global catalog server.
Cross-domain object references on a global catalog server are represented in the same way as
intradomain references on any domain controller – that is, as a direct pointer to the referenced
object. Therefore, if the infrastructure master is running on a global catalog server, it never finds
any phantom records representing cross-domain references in its local database. Consequently, the
infrastructure master is unable to replicate any updated references to cross-domain objects to any
other domain controller in its domain. For this reason, the infrastructure master should never run on
a global catalog server in a forest that contains multiple domains.
If every domain controller in a domain is a global catalog server, then no domain controller in the
domain has any phantom records that need to be updated. In this case, the infrastructure master
has no work to do and remains in a dormant state.

For more information about phantom records, see “How the Data Store Works ” in this
collection.
Top of page
Role Transfer and Seizure
You can reassign an operations master role by transfer or, as a last resort, by seizure.
Role transfer is the preferred method to move an operations master role from one domain controller
to another. When an operations master role is transferred, the previous role holder replicates its
most recent updates to the new role holder to ensure that no information is lost. After the transfer
completes, the previous role holder reconfigures itself so that it no longer attempts to perform as
the operations master while the new domain controller assumes those duties. This prevents the
possibility of duplicate operations masters existing on the network at the same time, which can lead
to inconsistencies in the directory.
Role seizure should be used only as a last resort to forcibly remove an operations master role from
one domain controller and assign the role to a different domain controller. Use this process only
when the previous operations master fails and remains out of service for an extended period of
time. For more information about the ramifications of roles seizure, see “Seizing Operations Master
Roles” later in this section.
During a role seizure, the domain controller that assumes the operations master role does not verify
that replication is updated, so recent changes can be lost. Because the previous role holder is
unavailable during the role seizure, it cannot know that a new role holder exists. If the previous role
holder comes back online, it assumes that it is still the operations master. This can result in
duplicate operations master roles on the network, which can lead to corruption of data in the
directory.

Transferring Operations Master Roles

To transfer a role to a new domain controller, ensure that replication is up to date and functioning
properly between the domain controller you are transferring the role from and the domain controller
assuming the new role. This minimizes the time required to complete the role transfer. If replication
is sufficiently out of date, the transfer process will take longer.
When an operations master role is transferred from one domain controller to another, the original
role holder checks that all recent updates have been replicated to the new role holder. In the event
that you must transfer an operations master role, it is best to transfer the role to a domain
controller located in the same site as the original role holder. Changes made by the original role
holder will replicate during the next replication cycle. Therefore, domain controllers located in the
same site are likely to have the most recent information from the original operations master role
holder.
If the new role holder is not located in the same site, changes might still need to replicate before
the role transfer completes (this occurs during the role transfer process). If the new role holder is in
the same site, it is more likely that the changes are already replicated, eliminating the need to
replicate a large amount of changes during the role transfer process. This can significantly decrease
the time required to transfer the role.
Operational Attributes Used to Transfer Roles
Not all attribute values are stored in a directory service. Instead, attribute values that are not
contained in the directory can be calculated when a request for the attribute is made. This type of
attribute is called an operational attribute. Note that this type of attribute is defined in the schema
but it does not contain a value in the directory. Instead, the domain controller that processes a
request for an operational attribute calculates the attribute’s value to answer the client request.
The following operational attributes are used to transfer operations master roles and are located on
the rootDSE (or root DSA-specific entry, the root of the Active Directory tree for a given domain
controller where specific information about the domain controller is kept):
• becomeRidMaster
• becomeSchemaMaster
• becomeDomainMaster
• becomePDC
• becomeInfrastructureMaste
r
During the operation of writing to the appropriate operational attribute on the domain controller that
is receiving the operations master role, the role is removed from the old domain controller and is
assigned to the new domain controller automatically. No manual intervention is required.
Decommissioning a Role Holder
When you use the Active Directory Installation Wizard to decommission a domain controller that
currently holds one or more operations master roles, the wizard reassigns the roles to a different
domain controller. When the wizard is run, it determines whether the domain controller currently
holds any operations master roles. If it detects any operations master roles, it queries the directory
for other eligible domain controllers and transfers the roles to a new domain controller. A domain
controller is eligible to hold a domainwide role if it is a member of the same domain. A domain
controller is eligible to hold a forestwide role if it is a member of the same forest.
You cannot control which domain controller the wizard chooses and the wizard does not indicate
which domain controller receives the roles. Because of this behavior, it is best to transfer the roles
prior to decommissioning the role holder so that you have control over which new domain controller
will hold the role.
Operational Attributes Used to Decommission a Role Holder
If you do not transfer operations master roles before demoting a domain controller, the
GiveAwayAllFsmoRoles operational attribute is written, which triggers the domain controller to
locate other domain controllers to transfer any roles it currently owns. Windows Server 2003
determines which roles the domain controller being decommissioned currently owns and locates a
suitable domain controller to assume these roles by following these rules:
• Locate a server in the same site
• Locate a server to which there is RPC connectivity
• Use a server over an asynchronous transport such as
SMTP
In all role transfers, if the role is a domain-specific role, the role can be moved only to another
domain controller in the same domain. Otherwise, any domain controller in the forest is a candidate.

Seizing Operations Master Roles

Role seizure is the act of assigning an operations master role to a new domain controller without the
cooperation of the current role holder. During role seizure, a new domain controller assumes the
operations master role without communicating with the current role holder. Because this can have
an adverse affect in your Active Directory environment, seize operations master roles only as a last
resort and if the current role owner is offline and unlikely to return to service.
Role seizure can create two conditions that can cause problems in the directory. First, the new role
holder starts performing its duties based on the data located in its current directory partition. If
replication did not complete prior to the time when the original role holder went offline, the new role
holder might not receive changes that were made to the previous role holder. This can cause data
loss or data inconsistency in the directory database.
To minimize the risk of losing data to incomplete replication, do not perform a role seizure until
enough time has passed to complete at least one complete end-to-end replication cycle across your
network. Allowing enough time for complete end-to-end replication ensures that the domain
controller that assumes the role is as up-to-date as possible.
Second, the original role holder is not informed that it is no longer the operations master role
holder, which is not a problem if the original role holder stays offline. However, if it comes back
online (for example, if the hardware is repaired or the server is restored from a backup), it might
try to perform the operations master role that it previously owned. This can result in two domain
controllers performing the same operations master role simultaneously. Depending on the role that
was seized, the severity of duplicate operations master roles varies from no visible effect to
potential corruption of the Active Directory database. Seize the operations master role to a domain
controller that has the most recent updates from the current role holder to minimize the impact of
the role seizure.
In Windows 2000 Server with Service Pack 3 (SP3) or later and Windows Server 2003, if an
operations master that has been taken offline is intentionally or unintentionally returned to service,
it must successfully replicate inbound changes on the directory partition that replicates and
maintains that operations master state before resuming its previously held role. The directory
partitions that maintain each operations master are defined in the following table.
Operations Masters and Corresponding Directory Partitions

Operations Master Role Directory Partition

Schema Master Schema partition

Domain Naming Master Configuration partition

Primary Domain Controller (PDC) Emulator Domain partition for the operations master role owner’s domain

RID Master Domain partition for the operations master role owner’s domain

Infrastructure Master Domain partition for the operations master role owner’s domain
By waiting a full replication cycle, the domain controller can determine if another operations master
exists before it brings itself back online. Successful replication must occur before dependent
operations can be performed. When the previous role holder receives the current environmental
state from another replica through inbound replication, it will update its copy of the database so
that it no longer hosts the role in question. This is to prevent more than one domain controller from
holding the same operations master role in each domain or forest.
Operations master roles that are hosted by a single domain controller in that role’s domainwide or
forestwide replication scope do not have to satisfy the initial synchronization requirement because
the domain controller has no replication partners. Initial synchronization requirements only exist
when a current operations master role owner’s hasMasterNC attribute contains references to more
than one domain controller. The hasMasterNC attribute is part of a domain controller’s NTDS
settings object in the CN=configuration partition of an operations master.
Ramifications of Role Seizure
If a role is seized, the new role holder is configured to host the operations master role with the
assumption that you do not intend to return the previous role holder to service. Use role seizure
only when the previous role holder is not available and you need the operations master role to keep
the directory functioning. Because the previous role holder is not available during a seizure, you
cannot reconfigure the previous role holder and inform it that another domain controller is now
hosting the operations master role.
To reduce risk, perform a role seizure only if the missing operations master role unacceptably
affects performance of the directory. Calculate the effect by comparing the impact of the missing
service provided by the operations master to the amount of work that is needed to bring the
previous role holder safely back online after you perform the role seizure.
Active Directory continues to function when the operations master roles are not available. If the role
holder is offline only for a short period, you might not need to seize the role to a new domain
controller. Remember that returning an operation master to service after the role is seized can have
dire consequences if it is not done properly. The following table shows the consequences of an
unavailable operations master role and restoring a role holder after the role has been seized.
Operations Master Role Functionality Risk Assessment

Recommendation for
Operations Consequences if Role is Risk of Improper
Returning to Service
Master Role Unavailable Restoration
After Seizure

Schema master You cannot make changes to the Conflicting changes can be Not recommended. Can lead to a
schema. introduced to the schema if both corrupted forest.
schema masters attempt to modify
the schema at the same time. This
can result in a fragmented schema.

Domain naming You cannot add or remove domains You cannot add or remove domains Not recommended. Can lead to data
master from the forest, add or remove or application directory partitions, or corruption.
application directory partitions, or clean-up metadata. Domains and
perform domain rename operations. application directory partitions might
appear as though they are still in the
forest even though they are not.

PDC emulator You cannot change passwords on Password validation can randomly Allowed. User authentication can
clients that do not have Active pass or fail. Password changes take be erratic for a time, but no
Directory client software installed. much longer to replicate throughout permanent damage occurs.
No replication to Windows NT 4.0 the domain.
backup domain controllers.

Infrastructure Delays displaying updated group Displays incorrect user names in Allowed. May impact the
master membership lists in the user group membership lists in the user performance of the domain
interface when you move users interface after you move users from controller hosting the role, but no
from one group to another within a one group to another. damage occurs to the directory.
single domain.

RID master Eventually, domain controllers Duplicate RID pools can be allocated Not recommended. Can lead to data
cannot create new directory objects to domain controllers, resulting in corruption.
as each of their individual RID data corruption in the directory. This
pools is depleted. can lead to security risks and
 Recommendation for
Operations Consequences if Role is Risk of Improper
Returning to Service
Master Role Unavailable Restoration
After Seizure

unauthorized access.
Operational Attributes Used to Seize Roles
When you seize an operations master role from an existing computer, the fsmoRoleOwner
attribute is modified on the object that represents the root of the data directly, bypassing
synchronization of the data and graceful transfer of the role.
The fsmoRoleOwner attribute of each of the following objects is written with the distinguished
name of the NTDS Settings object (the data in the Active Directory that defines a computer as a
domain controller) of the domain controller that is taking owner’ship of that role:

Schema master
LDAP://CN=Schema,CN=Configuration,DC=Contoso,DC=Com

Domain naming master

LDAP://CN=Partitions,CN=Configuration,DC=Contoso,DC=Com

RID master
LDAP://CN=Rid Manager$,CN=System,DC=Contoso,DC=Com

PDC emulator
LDAP://DC=Contoso,DC=Com

Infrastructure master
LDAP://CN=Infrastructure,DC=Contoso,DC=Com
As replication of this change starts to spread, other domain controllers learn of the operations
master role change.
For example, if Server1 is the PDC emulator in the Contoso.com domain and is decommissioned and
the administrator is unable to decommission the computer properly, Server2 needs to be forcibly
assigned the PDC emulator role. After the role is seized, the value
CN=NTDS Settings,CN=Server2,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=Contoso,DC=Com
is present on the LDAP://DC=Contoso,DC=com object.
Top of page
Network Ports Used by Operations Masters
The following ports are used by all domain controllers.
Port Assignments for Operations Masters

Service Name UDP TCP

LDAP 389 389

LDAP 686 (Secure Sockets Layer [SSL])

RPC/REPL 135 (endpoint mapper)

NetLogon 137

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

 Top of page
Related Information
The following resources contain additional information that is relevant to this section.
• What are Operations Masters?
• How the Data Store Works
• Active Directory Functional Levels Technical Reference