Description
Operations masters keep the directory functioning properly by performing specific tasks that no other domain controllers are permitted to perform. Because operations masters are critical to the long-term performance of the directory, they must be available to all domain controllers and desktop clients that require their services.
Careful placement of your operations masters becomes more important as you add more domains and sites to build your forest.
To perform these functions, the domain controllers hosting these operations master roles must be consistently available and be located in areas where network reliability is high.
Role transfer is the preferred method to move an operations master role from one domain controller to another. During a role transfer, the two domain controllers replicate 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 corruption in the directory.
Purpose
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.
It also processes all password updates for clients not running Active Directory–
enabled client software, plus any other directory write operations.
● The relative identifier (RID) master. The RID master allocates RID pools to all domain controllers to ensure that new security principals can be created with a unique identifier.
● The infrastructure master. The infrastructure master for a given domain maintains a list of the security principals for any linked-value attributes.
In addition to the three domain-level operations master roles, 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 and application partitions to and from the forest.
Guidelines
Design principles and best practices for initial operations master role assignment is covered in the Windows Server 2003 Deployment Kit: Planning, Testing, and Piloting Deployment Projects. Operations master role holders are placed automatically when the first domain controller in a given domain is created. The three domain-level roles are assigned to the first domain controller created in a domain. The two forest-level roles are assigned to the first domain controller created in a forest.
Reasons for moving the operations master role(s) include inadequate service performance, failure or decommission of a domain controller hosting an operations master role, or if dictated by configuration changes made by an administrator.
Inadequate Level of Service
The PDC emulator is the operations master role that most impacts the performance of a domain controller. For clients that do not run Active Directory client software, the PDC emulator processes requests for password changes, replication, and user authentication. While providing support for these clients, the domain controller continues to perform its normal services, such as authenticating Active Directory–
enabled clients. As the network grows, the volume of client requests can increase the workload for the domain controller that hosts the PDC emulator role and its
performance can suffer. To solve this problem, you can transfer all or some of the master operations roles to another, more powerful domain controller. Alternately, you may choose to transfer the role to another domain controller, upgrade the hardware on the original domain controller, and then transfer the role back again.
Master Operations Role Holder Failure
In the event of a failure, you must decide if you need to relocate the operations master roles to another domain controller or wait for the domain controller to be returned to service. Base that determination on the role that the domain controller hosts and the expected downtime.
Decommissioning of the Domain Controller
Before permanently taking a domain controller offline, transfer any operations master roles held by the domain controller to another domain controller.
Configuration Changes
Configuration changes to domain controllers or the network topology can result in the need to transfer master operations roles. Except for the infrastructure master, you can assign operations master roles to any domain controller regardless of any other tasks that the domain controller performs. Do not host the infrastructure master role on a domain controller that is also acting as a global catalog server unless all of the domain controllers in the domain are global catalog servers or unless only one domain is in the forest. If the domain controller hosting the infrastructure master role is configured to be a global catalog server, you must transfer the infrastructure master role to another domain controller. Changes to the network topology can result in the need to transfer operations master roles in order to keep them in a particular site.
You can reassign an operations master role by transfer or, as a last resort, by seizure.
To transfer a role to a new domain controller, ensure that the destination domain controller is a direct replication partner of the previous role holder and that
replication between them is up to date and functioning properly. This minimizes the time required to complete the role transfer. If replication is sufficiently out of date, the transfer can take a while, but it eventually finishes.
Important If you must seize an operations master role, never reattach the previous role holder to the network without following the procedures in this guide. Incorrectly reattaching the previous role holder to the network can result in invalid data and corruption of data in the directory.
Guidelines for Role Placement
By improperly placing operations master role holders, you might prevent clients from changing their passwords or being able to add domains and new objects, such as Users and Groups. You might also be unable to make changes to the schema. In addition, name changes might not properly appear within group memberships that are displayed in the user interface.
As your environment changes, you must avoid the problems associated with improperly placed operations master role holders. Eventually, you might need to reassign the roles to other domain controllers.
Although you can assign the forest-level and domain-level operations master roles to any domain controller in the forest and domain respectively, improperly placing the infrastructure master role can cause it to function improperly. Other improper configurations can increase administrative overhead.
Requirements for Infrastructure Master Placement
Do not place the infrastructure master on a domain controller that is also a global catalog server.
The infrastructure master updates the names of security principals for any domain-named linked attributes. For example, if a user from one domain is a member of a group in a second domain and the user’s name is changed in the first domain, then the second domain is not notified that the user’s name must be updated in the group’s membership list. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never becomes aware of the change. The infrastructure master constantly monitors group memberships, looking for security principals from other domains. If it finds one, it checks with the security principal’s domain to verify that the information is updated. If the information is out of date, the infrastructure master performs the update and then replicates the change to the other domain controllers in its domain.
Two exceptions apply to this rule. First, if all the domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalogs do replicate the updated information regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller that hosts the infrastructure master role is not needed because security principals from other domains do not exist.
Recommendations for Role Placement
Although you can assign the operations master roles to any domain controller, follow these guidelines to minimize administrative overhead and ensure the performance of Active Directory. If a domain controller that is hosting operations master roles fails, following these guidelines also simplifies the recovery process.
Guidelines for role placement include:
● Leave the two forest-level roles on a domain controller in the forest root domain.
● Place the three domain-level roles on the same domain controller.
● Do not place the domain-level roles on a global catalog server.
● Place the domain-level roles on a higher performance domain controller.
● Adjust the workload of the operations master role holder, if necessary.
● Choose an additional domain controller as the standby operations master for the forest-level roles and choose an additional domain controller as the standby for the domain-level roles.
Forest-level Role placement in the Forest Root Domain
The first domain controller created in the forest is assigned the schema master and domain naming master roles. To ease administration and backup and restore procedures, leave these roles on the original forest root domain controller. Moving the roles to other domain controllers does not improve performance. Separating the roles creates additional administrative overhead when you must identify the standby operations masters and when you implement a backup and restore policy.
Unlike the PDC emulator role, forest-level roles rarely place a significant burden on the domain controller. Keep these roles together to provide easy, predictable management.
Forest-level Role Placement on a Global Catalog Server
In addition to hosting the schema master and domain naming master roles, the first domain controller created in a forest also hosts the global catalog.
Domain-level Role Placement on the Same Domain Controller
The three domain-level roles are assigned to the first domain controller created in a new domain. Except for the forest root domain, leave the roles at that location. Keep the roles together unless the workload on your operations master justifies the additional management burden of separating the roles.
Because all clients prior to Active Directory submit updates to the PDC emulator, the domain controller holding that role uses a higher number of RIDs. Place the PDC emulator and RID master roles on the same domain controller so that these two roles interact more efficiently.
If you must separate the roles, you can still use a single standby operations master for all three roles. However, you must ensure that the standby is a replication partner of all three of the role holders.
Backup and restore procedures also become more complex if you separate the roles.
Special care must be taken to restore a domain controller that hosted an operations master role. By hosting the roles on a single computer, you minimize the steps that are required to restore a role holder.
Domain-level Role Absence on a Global Catalog Server
Do not host the infrastructure master on a domain controller that is acting as a global catalog server. Because it is best to keep the three domain-level roles together, avoid putting any of them on a global catalog server.
Domain-level Role Placement on a Higher Performance Domain Controller
Host the PDC emulator role on a powerful and reliable domain controller to ensure that it is available and capable of handling the workload. Of all the operations master