AD's Operations Master Roles

With Windows NT domains, you can make changes only on the PDC's copy of the directory. But as you know, Windows 2000 doesn't have PDCs and BDCs—just domain controllers. All the domain controllers retain read/write copies of the directory, so you can make changes on any of them. The system then uses multimaster replication to ensure that all domain controllers receive the changes you made. To prevent you from making conflicting changes at different domain controllers within a domain, Active Directory (AD) performs conflict resolution using update sequence numbers (USNs) and time stamps that it associates with every AD object change.

However, because some changes are too critical to allow for the possibility of conflict, certain functions can occur only on a specific domain controller in the forest or domain. Such functions are called operations master roles, and the domain controllers that are responsible for these roles are called operations masters. AD has five different operations master roles, two of which are per-forest roles and three of which are per-domain roles. Initially, the first domain controller you create in the forest hosts all five of these roles, including the two per-forest roles. As you add new domains to the forest, the first domain controller in the domain hosts the roles for the three per-domain roles for that domain.

Per-Forest Roles
The per-forest roles are Schema Master and Domain Naming Master. Because these are per-forest roles, there is only one Schema Master and one Domain Naming Master in any forest, no matter how many domains make up the forest.

The Schema Master controls all updates to the schema, which is the master list of all the object types that you can create in AD and the attributes that you can store for each object type. So whenever you want to administratively extend the schema or install an application that needs to update the schema, the Schema Master machine has to be online and available.

The Domain Naming Master controls adding and removing domains from the forest. Whenever you use dcpromo.exe to add or remove a domain controller in the forest, the system contacts the Domain Naming Master to make sure that you're using a unique name for the domain. Because the Domain Naming Master queries the Global Catalog (GC) to verify that no other object is using the name, the machine that assumes this role also must be a GC server.

Per-Domain Roles
The per-domain roles are PDC Emulator, RID Master, and Infrastructure Master. Because these are per-domain roles, there will be one of these for every domain in your forest.

In a mixed-mode domain, the PDC Emulator plays the role of PDC to any NT BDCs. Because the BDCs don’t have a read/write copy of the directory and don't support multimaster replication, they are dependent on the PDC Emulator to receive updates and make changes to the directory. The PDC Emulator also manages password changes from downlevel clients and is the first domain controller in the domain to receive password changes from other domain controllers. This feature lets you use the new password immediately, without waiting for the change to replicate to every domain controller in the domain.

The RID Master helps prevent different objects from receiving the same SID. Every SID comprises two parts, a domain ID that every object in the domain shares and a relative identifier (RID) that's unique to that particular object. All domain controllers can create objects, and if each domain controller were to generate its own RIDs, two different objects could, in theory, end up with the same SID. To prevent such a conflict, the RID Master generates all the RIDs and allocates them to other domain controller in the domain in blocks.

The Infrastructure Master is responsible for keeping object references that point to other domains up to date. Because a domain's groups and permissions can reference another group's users or groups, the Infrastructure Master periodically checks these objects' Distinguished Names and SIDs and replicates any changes to other domain controllers in its domain. To do so, the Infrastructure Master queries the GC to look for changes. The Infrastructure Master shouldn’t be a GC server.

Transferring and Seizing Roles
As I mentioned earlier, these roles initially reside on the first domain controller that goes up in a forest and on the first domain controller in any subsequent domains that you add to the forest. Because of the critical role they play in AD operations, it's important that you evaluate whether these are the right machines for hosting these roles in your environment. The roles should reside on centrally located, well-connected subnets and on machines that are stable and fault tolerant. To determine which domain controller is currently hosting roles in your forest or to transfer roles to another machine, you can use various Microsoft Management Console (MMC) snap-ins. You can use AD Users and Computers for RID Master, PDC Emulator, and Infrastructure Master; AD Domains and Trusts for Domain Naming Master; and AD Schema for Schema Master. If a machine that was hosting a role is down and won't be back online soon enough, you can seize the role instead of performing a transfer. To do so, you have to use the command-line utility ntdsutil.exe. I prefer to use this tool to view roles and perform transfers as well because I don’t have to open up several MMCs. Be careful though—ntdsutil.exe is a powerful utility that's not user friendly.