Consider the following scenario: For two years your organization has been operating a Windows 2000 Active Directory with eight domain controllers. Your budget request for replacement of the two oldest servers has been approved, and you have installed the new servers. Once they are up and running, you shut down and turn off the old servers and remove them from the rack. Now, a week later, you attempt to create a new domain in your forest, but Active Directory will not allow you to do it, even though you are a member of the Enterprise Administrators group. Still later, you try to install Exchange 2000, but this fails, too, because you cannot modify the schema, even though you are also a member of the Schema Admins group. What has gone wrong?
First, there are a few things you need to understand. Windows NT 4.0 networks use a single-master model, in which you have a Primary Domain Controller (PDC) and a number of Backup Domain Controllers (BDCs). With the advent of Active Directory, introduced with Windows 2000 Server, Microsoft moved to a multi-master model, in which you have a number of Domain Controllers, all of which are more or less equal, replicating information between each other. However, it turns out that not quite all the servers are equal. A few of them carry out unique and important roles within Active Directory. I'm going to take a look at each of these roles to see which functions they perform. This will help you see why you might have run into some of the problems mentioned above.
In addition to multi-master operations servers, Active Directory in both Windows 2000 and 2003 has what are called Flexible Single-Master Operations servers, or FSMO (pronounced "fizz-mo") for short. A FSMO server may have one or more of five possible roles within Active Directory. The reason for having these special servers is to help prevent conflicts within Active Directory. If only one server can control access to the schema, for instance, there will be no conflicts in the schema. The five roles found in FSMO servers are:
- Schema master: 1 per forest
- Domain naming master: 1 per forest
- Relative identifier master (RID): 1 per domain
- PDC emulator: 1 per domain
- Infrastructure master: 1 per domain
Two of these roles, schema master and domain naming master, are unique to each forest. In other words, there is only one schema master and one domain naming master in each forest. The other three are unique to each domain. So, for instance, there will be one infrastructure master in each domain within a forest. In a small network, with only one domain, it is possible that all five of these roles are found on the same domain controller. Or they could be split up, with per-forest roles on one server, and per-domain roles on one or more other domain controllers. These roles are placed by default on the first server that becomes a domain controller in the forest. However, an administrator may, and in some cases should, move the roles to another server. I will now discuss each of these roles in turn.
Schema operations master
The schema is simply the structure of the AD database itself. If a change needs to be made to the schema after AD is installed, it is the schema master that controls those changes. You may never need to change the schema, in which case it won't matter whether the schema master is operational or not.
On the other hand, there are a few "AD-aware" applications on the market, such as Exchange 2000, which modify the AD schema as part of the installation process. It would seem likely that the number of these AD-aware applications would grow in the future. If the schema operations master is not available, you would not be able to install these applications.
There are a few things to remember about the schema operations master:
- There is only one schema operations master in the forest.
- By default, the first server in the forest has the schema operations master role.
- In order to change the schema or move the schema operations master role to another server, you must be a member of the schema administrators group.
Domain naming operations master
Although it may seem implausible, it is theoretically possible that two enterprise managers might try to create domains with the same name at the same time. To prevent such a conflict, the "domain naming operations master" governs the naming of domains in AD.
Here's what you need to remember about the domain naming operations master:
- There is only one domain naming operations master in the forest.
- By default, the first server in the forest has the domain naming operations master role.
- In order to create a domain or move the domain naming operations master role to another server, you must be a member of the Enterprise Administrators group.
- The domain naming operations master role must be placed on a domain controller that is also a Global Catalog server (remember that a Global Catalog server contains part of the schema, including domain names).
Relative ID operations master (RID)
A security identifier, or SID, uniquely identifies everything in a Windows NT/2000/2003 network. That SID is composed of two parts: three 32-bit numbers that are always the same within a given domain, and one 32-bit number that uniquely identifies a particular object. That last 32-bit number is called a "relative identifier," or RID.
One DC in each domain contains the RID operations master roles for that domain. Its function is to distribute pools of relative identifiers to all the DCs in the domain, to use when creating users, groups, computers, printers, etc. In that way, it ensures the uniqueness of every RID in that domain.
There are some different things that you should remember about the RID operations master:
- Unlike the last two operations master roles, there is one RID operations master in every domain in the forest (e.g., if you have three domains, then there are three RID operations masters in the forest).
- By default, the first server in a domain is the RID operations master.
- In order to move the RID operations master role to another server, you must be a member of the Domain Administrators group.
PDC emulator operations master
There are times when workstations running Windows NT or Windows 9x will require access to a domain's primary domain controller (PDC). If these workstations are part of a Windows 2000 or 2003 network, there could be a problem, since there is no PDC. For this reason, another domain-level FSMO role is the PDC emulator. As the name implies, the DC containing this role emulates a PDC for those workstations running an OS earlier than Windows 2000.
But what if all your workstations are running either Windows 2000 Pro or Windows XP Pro? Do you still need a PDC emulator? The answer is yes.
Changes made to AD are automatically replicated to all domain controllers. But in a large network, this can take time. Often, that is okay, but there are two particular instances when you don't want to have to wait very long for replication: unlocking an account and changing a password. The reason, of course, is that the user cannot work until the change has been replicated and is in effect. Therefore, replication for these two events is forced immediately to the PDC emulator. If the local DC for that user determines that the account is locked or the password is incorrect, it will check the PDC emulator before denying logon. In this way, the user can get right to work.
Like the RID operations master, there is one PDC emulator per domain. By default, it is the first server in the domain, and you must be a Domain Administrator in order to move the role to another DC.
Infrastructure operations master
The fifth and final FSMO role in Active Directory is the infrastructure operations master. This role is responsible for expediting replication of Active Directory changes across domains. If the infrastructure operations master is not available, replication will still take place, but it will take longer.
Like the RID and PDC emulator roles, there is one infrastructure operations master in every domain, and, by default, it is placed on the first DC in the domain.
However, there is something else that you must be aware of in placing the infrastructure operations master. It should not be placed on a DC that is also a Global Catalog server. The reason for this is very simple. The function of the infrastructure master is to query other domain controllers, update references found that are not in its own domain controller, and then replicate those updates to other domain controllers. Remember that the Global Catalog holds a partial replica of every object in the forest. If the infrastructure master is located on a Global Catalog server, it will never find references to objects that are not found on its own DC. Thus it will never replicate changes or updates.
Taking the next step
Flexible single-master operations roles in Active Directory help prevent conflicts, but can cause problems on your network if their function is interrupted for any length of time. That's why it's important to not only know exactly where those servers are in the network, but also to plan for their placement ahead of time. Moreover, you will need to know what to do if any of those functions are interrupted.
In part two of this article, I will discuss the placement of FSMO servers, how to transfer FSMO roles to another server if the FSMO server is functional, and how to move the role to another server if the original FSMO is no longer available.