So far in this article series, I have explained that the Active Directory consists of a forest filled with domain trees, and that the names of each domain indicate its position within the forest. Given the hierarchical nature of the Active Directory, it might be easy to assume that domains near the top of the hierarchy (or rather the domain controllers within those domains) are the most important. This isn't necessarily the case though. In this article, I will discuss the rules that individual domain controllers play within the Active Directory forest.
Earlier in this series, I talked about how domains in Windows NT were all encompassing. Like Active Directory domains, Windows NT domains supported the use of multiple domain controllers. Remember that domain controllers are responsible for authenticating user logons. Therefore, if a domain controller is not available then no one will be able to log on to the network. Microsoft realized this early on and designed Windows to allow multiple domain controllers so that if a domain controller failed, another domain controller would be available to authenticate logons. Having multiple domain controllers also allows the domain related work load to be shared by multiple computers rather than the full burden falling on a single server.
Although Windows NT supported multiple domain controllers within a domain, one of these domain controllers was considered to be more important than the others. This was known as the Primary Domain Controller or PDC. As you may recall, a domain controller contains a database of all of the user accounts within the domain (among other things). This database was called the Security Accounts Manager, or SAM database.
In Windows NT, the PDC stored the master copy of the database. Other domain controllers within a Windows NT domain were known as Backup Domain Controllers or BDCs. Any time that a change needed to be made to the domain controller’s database, the change would be written to the PDC. The PDC would then replicate the change out to all of the BDCs in the domain. Under normal circumstances, the PDC was the only domain controller in a Windows NT domain to which domain related updates could be applied. If the PDC were to fail, there was a way to promote a BDC to PDC, thus enabling that domain controller to act as the domain’s one and only PDC.
Active Directory domains do things a little bit differently. The Active Directory uses a Multi master replication model. What this means is that every domain controller within a domain is writable. There is no longer the concept of PDCs and BDCs. If an administrator needs to make a change to the Active Directory database, the change can be applied to any domain controller in the domain, and then replicated to the remaining domain controllers.
Although the multimaster replication model probably sounds like a good idea, it opens the door for contradictory changes. For example, what happens if two different administrators apply contradictory changes to two different domain controllers at the same time?
In most cases, the Active Directory assumes that the most recent change takes precedence. In some situations, the consequences of a conflict are too serious to rely on this type of conflict resolution. In these cases, Microsoft takes a stand point that it is better to prevent a conflict from occurring in the first place than to try to resolve the conflict after it happens.
To handle these types of situations, Windows is designed to designate certain domain controllers to perform Flexible Single Master Operation (FSMO) roles. Essentially this means that Active Directory domains fully support multimaster replication except in certain circumstances in which the domain reverts to using a single master replication model. There are three different FSMO roles that are assigned at the domain level, and two additional roles that are assigned the forest level.
Where are the FSMO Roles Located?
For the most part, the FSMO roles pretty much take care of themselves. It is important however for you to know which domain controllers host these roles. By default, the first domain controller in the forest hosts all five roles. As additional domains are created, the first domain controller brought online in each domain holds all three of the domain level FSMO roles.
The reason why it is so important to know which domain controllers hold these roles is because hardware eventually gets old and is decommissioned. I once saw a situation in which a network administrator was preparing to deploy an Active Directory network for his company. While waiting for the newly ordered servers to arrive, the administrator installed Windows onto a junk PC so that he could begin playing around with the various Active Directory management tools.
When the new servers finally arrived, the administrator configured them as domain controllers in the already created domain rather than creating a new forest. Of course this meant that the junk PC was holding the FSMO roles for the domain in the forest. Everything worked fine until the administrator decided to remove the “junk” PC from the network. Had he properly decommissioned this server, there would not have been a problem. Being inexperienced though, he simply reformatted the machine’s hard drive. All of a sudden the Active Directory began to experience numerous problems. If this administrator had realized that the machine that he had removed from the domain was hosting the domain and forest’s FSMO roles, the problems could have been avoided. Incidentally, in a situation like this there is a way of seizing the FSMO roles from the deceased server so that your network can resume normal operations.
What are the FSMO Roles?
I will talk more about the specific functions of the FSMO roles in the next article in this series. I do however want to quickly mention what these roles are. As you may recall, I mentioned that there are three domain specific roles, and two forest specific roles.
The domain specific roles include the Relative identifier, the Primary Domain Controller Emulator, and the Infrastructure Master. Forest level roles include the Schema Master and the Domain Naming master. Below is a brief description of what these roles do:
Schema Master: maintains the authoritative copy of the Active Directory database schema.
Domain Naming Master: maintains the list of domains within the forest.
Relative Identifier Master: responsible for ensuring that every Active Directory object at a domain receives a unique security identifier.
Primary Domain Controller Emulator: acts as the Primary Domain Controller in domains containing domain controllers running Windows NT.
Infrastructure Master: the Infrastructure Master is responsible for updating an object’s security identifier and distinguished name in a cross domain object reference.
