Share via

How Operations Masters Work

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

In this section

  • Operations Master Protocols

  • Operations Master Roles and Functionality

  • Role Transfer and Seizure

  • Network Ports Used by Operations Masters

  • Related Information

Active Directory Domain Services (AD DS) 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 AD DS 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 AD DS database.

Note

In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named Active Directory. In Windows Server 2008 R2 and Windows Server 2008 , the directory service is named Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also applicable to Active Directory.

Five operations masters are assigned to perform specific tasks in an AD DS 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.

Operations Master Protocols

Operations masters use the same protocols as other 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 access protocol (LDAP)

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 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. AD DS 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 AD DS.

Remote procedure call (RPC)

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 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 (SMTP)

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 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 AD DS protocols, see “How the Data Store Works.”

Operations Master Roles and Functionality

Five operations master roles manage single-master operations in AD DS.

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 AD DS 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 Domain Services 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 or later 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. For domain controllers that run Windows Server 2003 or later, 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 forest with domain controllers that run Windows Server 2003 or later. 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 AD DS 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 later, or if it is unavailable, you cannot add or remove application directory partitions from the forest.

Add or Remove Cross-Reference Objects

When AD DS 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 AD DS 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 AD DS 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 element Description

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 or AD DS 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 AD DS 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 AD DS domain controller 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 AD DS, 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 AD DS 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 AD DS 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 AD DS objects will fail.

RID Attributes in AD DS

The following are RID-related attributes in AD DS:

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 AD DS.

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. Windows Server 2008 R2 and Windows Server 2008 domain controllers cannot interoperate with Windows NT 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 7, Windows Vista, 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 AD DS.

  • Clients use Active Directory to locate network resources. They do not require the Computer Browser service.

In addition, 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 AD DS, 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

The PDC emulator operations master is responsible for managing well-known security principals. For more information about well-known security principals that are added in Windows Server 2008, see Appendix A: Background Information for Upgrading Active Directory Domains (https://go.microsoft.com/fwlink/?LinkId=192800). The rest of this section covers information about well-known security principals that are added in Windows Server 2003.

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 AD DS 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 https://go.microsoft.com/fwlink/?LinkId=48186.

Raising the Domain Functional Level

The functional level of a domain or forest defines the set of advanced AD DS features that are available in that domain or forest. The functional level of a domain or forest also defines the set of Windows Server 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. Therefore, the PDC emulator must be available to raise the domain functional level. For more information 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.

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.

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 AD DS tree for a given domain controller where specific information about the domain controller is kept):

  • becomeRidMaster

  • becomeSchemaMaster

  • becomeDomainMaster

  • becomePDC

  • becomeInfrastructureMaster

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 Domain Services 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. AD DS 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 adversely affect your AD DS 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 AD DS 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 or later, 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.

AD DS 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 Master Role Consequences if Role is Unavailable Risk of Improper Restoration Recommendation for Returning to Service After Seizure

Schema master

You cannot make changes to the schema.

Conflicting changes can be introduced to the schema if both schema masters attempt to modify the schema at the same time. This can result in a fragmented schema.

Not recommended. Can lead to a corrupted forest.

Domain naming master

You cannot add or remove domains from the forest, add or remove application directory partitions, or perform domain rename operations.

You cannot add or remove domains or application directory partitions, or clean-up metadata. Domains and application directory partitions might appear as though they are still in the forest even though they are not.

Not recommended. Can lead to data corruption.

PDC emulator

You cannot change passwords on clients that do not have Active Directory client software installed. No replication to Windows NT 4.0 backup domain controllers.

Password validation can randomly pass or fail. Password changes take much longer to replicate throughout the domain.

Allowed. User authentication can be erratic for a time, but no permanent damage occurs.

Infrastructure master

Delays displaying updated group membership lists in the user interface when you move users from one group to another within a single domain.

Displays incorrect user names in group membership lists in the user interface after you move users from one group to another.

Allowed. May impact the performance of the domain controller hosting the role, but no damage occurs to the directory.

RID master

Eventually, domain controllers cannot create new directory objects as each of their individual RID pools is depleted.

Duplicate RID pools can be allocated to domain controllers, resulting in data corruption in the directory. This can lead to security risks and unauthorized access.

Not recommended. Can lead to data corruption.

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 AD DS 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.

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

The following resources contain additional information that is relevant to this section.