How Operations Masters Work

• Operations Masters Protocols

• Operations Masters Roles and Functionality
• Role Transfer and Seizure
• Network Ports Used by Operations Niasters

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 directory The primary directory service protocol that specifies directory
communications. It runs directly over TCP/IP, and it can also run over UDP
connectionless transports (UDP access is primarily used by the domain controller
access protocol 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) 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 communications. RPC is a powerful, robust, efficient,
and secure interprocess communication (IPC) mechanism that call (RPC) enables data
exchange and invocation of functionality residing in a different process. That different
process can be on the same computer, on the local area network (LAN), or across the
Internet.
Simple mail transfer Protocol for replication communications when a permanent, “always
on” network connection does not exist between two domain controllers. SMTP is used to
transport and deliver messages based on specifications in protocol (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
1’ Top of pacje
Operations Master Roles and Functionality
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 2 of 11

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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 3 of 11

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 msDSUpdateScript 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
[http://technet2.microsoft.com/WindowsServer/en/library/35e63f1e-f097-4c9c-a788-
efc840d78193 1033.mspx]
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-i 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.
Yi-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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 4 of 11

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:
Fsmo RoleOwner
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.
Rid NextRid
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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 5 of 11

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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008
How Operations Masters Work Page 6 of 11
• 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 [http://go.microsoft.com/fwlink/?Linkld=48186] at
http://go.microsoft.com/fwlink/?Linkld=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.
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 7 of 11

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.
1’ Top of pacje
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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 8 of 11

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
• becomelnfrastructureMaster
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 (5P3) 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
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 9 of 11

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
Operations Recommendation for Returning to Service After
Consequences if Role is Unavailable Risk of Improper Restoration
Master Role Seizure
Schema master You cannot make changes to the schema. Conflicting changes can be
introduced to the schema if both schema masters attempt to Not recommended. Can lead
to a corrupted forest.
modify the schema at the same time. This can result in a fragmented schema.
Domain naming You cannot add or remove domains from the forest, add or remove You
cannot add or remove domains or application directory partitions, or clean-up Not
recommended. Can lead to data corruption.
master application directory partitions, or perform domain rename operations. metadata.
Domains and 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 clients that do not have Active Password
validation can randomly pass or fail. Password changes take much longer to Allowed.
User authentication can be erratic for a time,
Directory client software installed. No replication to Windows NT 4.0 replicate
throughout the domain, but no permanent damage occurs.
backup domain controllers.
Infrastructure Delays displaying updated group membership lists in the user interface
Displays incorrect user names in group membership lists in the user interface after you
Allowed. May impact the performance of the domain
master when you move users from one group to another within a single move users from
one group to another. controller hosting the role, but no damage occurs to the
domain, directory.
RID master Eventually, domain controllers cannot create new directory objects as
Duplicate RID pools can be allocated to domain controllers, resulting in data corruption
in Not recommended. Can lead to data corruption.
each of their individual RID pools is depleted. the directory. This can lead to security
risks and 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:
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 10 of 11

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 Serverl 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
is present on the LDAP://DC=Contoso,DC=com object.
‘‘ Top of pacje
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
SMBoverIP 445 445
Top of pacje
http ://technet2 .microsoft.comlwindowsserver/enllibrary/795229a5 -8a74-4edb-a2f4-d5
794d3 1 c2a7 1033 .mspx?pf=true 6/23/2008

How Operations Masters Work Page 11 of 11

Related Information
The following resources contain additional information that is relevant to this section.
• What are Operations Masters?
[http://technet2.microsoft.com/WindowsServer/en/library/6a773f69-e153-4460-9a9b-
014e981 lObablO33.mspx]
• How the Data Store Works
• Active Directory Functional Levels Technical Reference