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.
Prev. page
[1]
2
next page 
