Understanding DC Roles

The mail I receive indicates that some readers are confused about the roles that domain controllers (DCs) play in the enterprise and how much control administrators have over those roles. Let me give you a practical, elucidating explanation of DC roles.

Roles and Replication
Assigning certain roles to specific DCs results in more efficient replication. Each role-holding DC can replicate its Active Directory (AD) data whenever another DC needs the information, instead of replicating the entire AD database through the enterprise.

Windows NT networks use the clunky paradigm of the single-master replication model. An NT network has one PDC and as many BDCs as needed. After the PDC replicates the SAM to the BDCs, users can log on to and authenticate to the domain through a BDC. If the PDC is across a WAN, changing domain objects is slow at best and impossible if the WAN is down. This bottleneck can cause problems as administrators add users, computers, and groups to the domain and users try to change their passwords.

When Microsoft launched Windows 2000, the company made much of the fact that NT 4.0's PDC/BDC paradigm was no longer an administrative fact of life. We heard and read that with Win2K, all DCs are equal. But in fact, all DCs don't have to be equal. Instead, they can individually assume specific roles, letting you more easily and efficiently maintain your enterprise through AD.

Before we discuss roles, let's talk about terminology. The correct term for roles is Operations Master roles, but administrators who deployed Win2K during the beta period still tend to call them by their original name, Flexible Single-Master Operation (FSMO) roles. Microsoft changed that terminology to Operations Master roles, but some of us just can't break the habit of saying "fizzmo." For the purposes of this column, I simply use the term roles.

The Windows Server 2003/Win2K paradigm is called a multimaster replication model: Because any DC can accept changes to the domain's structure and objects, each DC is a master and replicates its changes to all other DCs in the domain. The multimaster approach is responsible for the idea that all DCs are created equal. But a pure multimaster domain is inefficient—a lot of bandwidth and processing energy are required for every computer to replicate everything all over the place. Furthermore, suppose two members of the IT department, working at different DCs, create a new object with the same name but different configuration settings. Although "the first write wins" rule applies, the second administrator might have a more compelling reason to use the name.

To make the multimaster paradigm more efficient, you can assign roles to specific DCs. Thus, even though all DCs are more or less equal, for a particular role, one DC is more equal than the others (to steal a phrase from George Orwell). For that role, one DC is in charge of replication, so Win2K actually has a multiple single-master replication model.

The Roles
Maintaining a forest and one or more domains requires five roles. You can assign each role to a separate DC, or you can assign multiple roles to one or more DCs.

Schema master (forest role). The schema master DC is in charge of all updates and modifications to the AD schema. (You can think of the schema as the field definitions for the AD database.) A forest can contain only one schema master—by default, the first DC installed in an enterprise is the schema master.

Domain naming master (forest role). The domain naming master is in charge of adding domains to and deleting them from the forest. You can have only one domain naming master in the forest. Although you can create or remove domains from any DC, the domain naming master accepts or rejects your actions and is the keeper of the domain names. If two administrators working at different DCs create a new domain with the same name but different configuration settings, the domain naming master accepts the first domain and rejects the second. Because creating new domains isn't a frequent or ongoing process, the DC that has this role is a good candidate for multiple roles. In Win2K, the domain naming master must also house the Global Catalog (GC). In Windows 2003, however, you can put the GC on any DC and on as many DCs as you wish.

Relative ID master (domain role). Commonly called the RID master, this DC keeps the pool of unique SIDs. When someone creates a new object on a DC, the RID master assigns the object a SID that consists of two parts:

To make sure all objects' SIDs have unique RIDs, you need a single source for RIDs: the RID master. The RID master doesn't get involved every time you create a new object; instead, it hands out pools of 500 RIDs to every DC. Just before a DC runs out of RIDs, it asks the RID master for another pool. Because replenishing RIDs doesn't take much time or use a lot of network bandwidth, the RID master is an ideal candidate to have multiple roles.

PDC emulator (domain role). You can have only one PDC emulator in each domain. The PDC emulator role has slightly different responsibilities depending on the version of Windows your DCs run. Until all your DCs run Windows 2003 or Win2K, the DC that's designated as the PDC emulator master pretends to be a PDC and acts as if it were part of an NT network. NT BDCs don't accept account changes from administrators or users; a PDC must make those changes. Consequently, an NT BDC insists on accessing a PDC when it needs to update the SAM. And if you try to establish a trust with an NT domain, the NT domain won't talk to any computer that isn't a PDC. NT is designed that way.

But the need for a PDC emulator continues even after you've eliminated all NT DCs from your network. Client computers sometimes require the services of a PDC. For example, Network Neighborhood and My Network Places use browsing functions that require the election of a master browser—a computer that tracks the names of all the computers on the network. Because the PDC, by default, is the master browser, having a PDC emulator master assume this task is much easier than changing the way the master browser is elected.

The PDC emulator master also provides the important function of instant replication. Although AD replicates most of its changes at regularly scheduled intervals, AD must immediately replicate one type of change: a user's password change. As soon as someone changes a password on any DC in the enterprise, the DC that accepts the password change contacts the PDC emulator master and records the change. Left to itself, the PDC emulator master won't replicate the change immediately, it will replicate the change during the next scheduled replication. So, if a user attempts to use the new password to log on to a DC other than the one that originally accepted the change, the password change might not yet be replicated on that DC. In that case, the DC doesn't deny the user the right to log on. It asks the PDC emulator master, "Did this account change?" The PDC emulator master answers, "The account has a new password; here it is."

In addition, the PDC emulator master synchronizes time across the forest. By default, Windows 2003, Windows XP, and Win2K Server computers check with a time server periodically to make sure their time is in sync with the time server's time. The PDC emulator master is the authoritative time server for the forest. (For more information about the Windows Time service, see Getting Started with Win2K, "Perfect Timing," November 2002, http://www.winnetmag.com, InstantDoc ID 26697, and Inside Out, "Keeping Time with Win2K," April 2001, InstantDoc ID 20079.) Because of its wide range of duties, you should put the PDC emulator master on a DC that has no other roles.

Infrastructure master (domain role). The infrastructure master DC keeps track of objects in its domain and provides that information to all other DCs in the domain. To track objects, the infrastructure master compares its data with that on the GC, which receives regular updates through replication. When the data doesn't match, the infrastructure master requests an update from the GC.

In essence, the data the infrastructure master keeps is a domain catalog. And therein lies a potential problem. Because the GC takes precedence over the infrastructure master, if the GC resides on the DC that acts as an infrastructure master, the domain data never replicates to the other DCs in the domain. Therefore, if you're distributing roles among DCs, don't put a copy of the GC on the DC that acts as the infrastructure master. This problem doesn't arise if you have only one domain and only one DC in the domain, because in that case the GC is the domain catalog. Also, if all the DCs in a domain host the GC, all the DCs will have the current data, and it doesn't matter which DC holds the infrastructure master role.

Reassigning Roles
When you install the first Windows 2003 or Win2K Server DC and create the first forest and domain, that DC has all the forest and domain roles. As you add DCs to the domain, those roles don't automatically move to another DC. When you add domains to the forest, the first DC in the domain has all the domain roles, and adding DCs to the forest doesn't change that fact. You must reassign roles manually, and you can split the roles among DCs however you wish. For instructions about moving roles among DCs, see the sidebar "How to Move DC Roles."

Give It Some Thought
Assigning roles thoughtfully keeps your network running at top performance levels. Reassign roles only when necessary. Adhere to the guiding principles "Keep it simple" and "If it ain't broke, don't fix it," and change roles only when doing so makes sense. For instance, if a DC with multiple roles is slowing down noticeably, transfer one or more of its roles to other DCs. Or, if most of the administrators who manage and manipulate the enterprise are at one site and the forest roles are on a DC at another site, move the forest roles to DCs nearer the administrators so that they don't have to work across a WAN.