When multi-master isn't quite so: Managing FSMO roles

As we all know, one of the greatest advantages of Active Directory over Windows NT4 is its use of multi-master replication to propagate changes to directory information. Rather than having a single master domain controller that you can make changes to, and then a number of read-only backup domain controllers, AD allows you to make changes to the directory from multiple locations and then replicates those changes around the network. However, there are certain types of changes that are so sensitive that they don't lend themselves well to this type of multi-master architecture.

Making changes to the schema, for example, is a sufficiently delicate operation that you wouldn't want more than one administrator attempting to do so at the same time. Similarly, you wouldn't want two administrators attempting to create the same child domain twice through poor scheduling or miscommunication. To protect these delicate operations, Active Directory administrators can designate certain individual servers within a domain and/or forest to act as a Flexible Single Master Operations role holder (FSMO, for short.) There are two FSMO roles that are forest-wide, so that only one DC in the entire forest can hold them:

Schema Master – manages any and all changes that are made to the Active Directory schema

Domain Naming Master – manages the creation and deletion of domains and application partitions to ensure unique names across a forest

In addition to these forest-wide FSMO role-holders, there are three more that are unique to a domain:

RID Master – allocates relative identifiers (RIDs) to each DC in a forest to ensure that all objects created within the domain possess a unique SID

Infrastructure Master – manages references to objects in other domains, which is necessary when you grant access to resources in one domain to users from another domain

PDC Emulator – acts as a Primary Domain Controller (PDC) for down-level client logons, as well as managing time synchronization and Group Policy management within a domain

So in a forest that consists of a single domain, there will be five FSMO roles: the two forest-wide FSMOs, and three domain-wide FSMOs for the single domain. If you add a second domain to the forest, you will have eight FSMOs: two forest-wide, and three domain-wide for each domain, for a total of six. It's important to remember that a single physical DC can hold more than one FSMO role at a time, so there's no need to look at your FSMO and faint at the thought of standing up five domain controllers just to house the FSMO roles.

By default, the first domain controller installed in a forest holds all five forest- and domain-wide FSMOs, and the first DC installed in any additional domains will hold all three domain-wide FSMOs for the newly-created domain. For optimum placement, you should ensure that the PDC Emulator and the RID Master are housed on the same physical DC, and that the Domain Naming Master resides on a Global Catalog. However, you should place the Infrastructure Master on a DC that is not a Global Catalog, since the information stored in the Global Catalog will interfere with how the Infrastructure Master functions. You can safely ignore this recommendation in either of the following situations:

You only have a single domain in your environment, or

You are working in a multi-domain environment and every DC is a GC.

If you want to transfer a FSMO role to a different server, you can do so using the NTDSUTIL command-line utility, or one of the following GUI utilities:

Use the Active Directory Schema snap-in to transfer the Schema Master

Use Active Directory Domains & Trusts to transfer the Domain Naming Master

Use Active Directory Users & Computers to transfer the three domain-wide FSMOs: PDC Emulator, RID Master, and Infrastructure Master

However, the transfer process I just described is only possible if the original role-holder is available on your network. If the original role-holder has failed or is completely unavailable, you'll need to forcibly seize the FSMO roles onto a new domain controller. In our next article, we'll look at what's involved in recovering from a lost FSMO role holder in this manner.