Operations Masters

Domain Controllers: Pieces/Parts

Operations Master Roles:

Domain controllers are the glue that holds a domain together. And because each domain controller replicates to other domain controllers in a domain, they are essentially peers. But doesn't that seem very simplistic? Shouldn't there be some sense of authority or a central point of control? The answer is a reserved "yes." While it is true that all domain controllers are equals in most regards, there are five distinct, separate roles that are assigned to certain domain controllers that set them apart from the rest of the pack. Called the Operations Master roles (sometimes called flexible single master operations or FSMO , pronounced fizz-mo ), no domain would function without them. Let's look at these roles a bit closer.

Schema Master:

The schema master is responsible for maintaining the schema of a domain or forest, and replicating it to other domain controllers in the domain or forest. Now that's a mouthful. But what's the schema, you might ask? The schema makes up the guts of a domain or forest. For example, the schema defines what a user is and what components make up a user (such as username, logon hours, and group membership). Without such definition, we would be unable to perform even the simplest of tasks , such as adding a new user .

Domain Naming Master:

Not to be confused with a Domain Naming Service (DNS) server, the Domain Naming Master is responsible for regulating the addition and/or removal of domains in a forest, and replicating this data to other domain controllers in the domain or forest.

RID (Relative ID) Master:

The RID Master is responsible for passing out special identification codes, called Relative IDs (or RIDs) to each domain controller in a domain. So when we add a new user in Active Directory Users and Computers, a domain controller assigns that new user a RID. That domain controller, in turn , received a table of RIDs from the RID master. What happens when a domain controller runs out of RIDs? The RID master allocates more RIDs to them ( if only employers were this generous with a paycheck ).

Primary Domain Controller (PDC) Emulator Master:

Once upon a time, before Active Directory, there was Windows NT. Windows NT used a concept of domains, but was by no means as powerful and flexible as Active Directory. And unlike Active Directory, servers in a Windows NT domain were not as equal with one another. The lead server was called a Primary Domain Controller (with subordinate Backup Domain Controllers). Older Windows clients such as Windows 98 or Me require the presence of a Primary Domain Controller in order to join a domain. So in order for older Windows 9x clients to log into our Active Directory domain, we must have a service on a domain controller that mimics, or emulates, the Primary Domain Controller, and this is precisely the role of the PDC Emulator.

The PDC also has two other roles. The first is to synchronize the time of all other domain controllers in the domain. The second is to handle recently-made password changes in the domain. For example, let's say that an administrator changes a user's password on domain controller A. That user then tries to log into the domain from domain controller B immediately following the password change. Normally, replication from domain controller A to domain controller B does not take place immediately. The PDC's job is to keep these changes up to date so that clients may log in as soon as possible after a password change. So when domain controller B rejects the new password, it consults the PDC, which contains the updated password information, and passes the updated password back to B so that the user may log in. Now that's slick, huh?

Infrastructure Master:

The Infrastructure Master's job is to "glue" information about objects between domains together. It also is responsible for updating information when users change group memberships. It then replicates this information throughout a domain.

The infrastructure Master relies on the Global Catalog. While the Global Catalog is not a true Operations Master role, it is very important as it keeps a copy, or index, of all objects in an Active Directory forest. The Global Catalog is in the "know" any time changes are made to the domain (e.g., a new shared folder is added, a new user is added, or a group is removed). Because the Global Catalog keeps track of all this information, it is also responsible for responding to search queries for objects in the domain. If you want to know where that one printer in the janitor's closet is located on the network, your computer consults the Global Catalog to get you the information you need.

One point to be made here is that you should never put the Global Catalog and the Infrastructure Master on the same domain controller (unless you only have one domain controller in your domain, which is our situation at this point in our book). Why? Consider that the Infrastructure Master receives changes made to the domain from the Global Catalog and then replicates these changes to every other domain controller in the domain. If it is located on the same machine as the Global Catalog, then it will always see a Global Catalog that is up to date. And if it sees an up-to-date Global Catalog, it will never replicate any changes to other domain controllers in the domain. And an incomplete domain like this can call for large amounts of pain reliever for network administrators.