Networking Basics: Part 8 – FSMO Roles continued

Continuation of the discussion of FSMO roles.

Introduction

This article will continue the discussion of FSMO roles by discussing what the various roles do, the consequences of FSMO failures, and how to determine which server is hosting the FSMO roles.

The Importance of FSMO Roles

In the previous part of this article series, I explained that Active Directory domains use multi master replication except in certain situations in which it is critically important to avoid a conflict. In those situations, Windows reverts to a single master replication model in which a single domain controller acts as the sole authority for the change in question. These domain controllers are said to hold Flexible Single Operations Master (FSMO) roles.

As I explained in Part 7 of this article series, there are five different FSMO roles. Two of these roles exist at the forest level, and three of the roles exist at the domain level. The Forest level roles include the Schema Master and the Domain Naming master, while the domain level FSMO roles include the Relative Identifier Master, Primary Domain Controller (PDC) Emulator, and Infrastructure Master.

I actually debated as to whether or not to discuss FSMO roles so early in this article series. Ultimately I decided to go ahead because FSMO roles are so important to supporting Active Directory functionality.

As I’m sure you probably know, in order to be able to function, the Active Directory requires that the DNS services are accessible and that the domain have at least one domain controller. When an Active Directory based network is initially created, the first domain controller to be brought online is almost always configured to act as the network’s DNS server. This same domain controller is also assigned all five of the FSMO roles. If other domains are created within the forest, then the first domain controller within each domain will host the FSMO roles for that domain. The forest level FSMO roles are only hosted on a single domain controller regardless of the number of domains in the forest.

I tell you this because I want to talk about what will happen if a domain controller that is hosting the FSMO roles fails. If the domain controller that contains the forest level FSMO roles fails, you are definitely going to notice the problem. It isn’t that the FSMO roles themselves are all that critical to the network’s operation, but rather that the domain controller that hosts the forest level FSMO roles is usually also hosting the DNS services, which are considered critical to Active Directory. If the DNS services were hosted on a separate server and the domains within the forest each had more than one domain controller, you probably wouldn’t even notice the failure for a while (unless you had monitoring software to alert you to the failure).

Usually, there are no immediate consequences to an FSMO role failure, but some rather strange symptoms will develop later on if the problem is not corrected. That being the case, it is important to know the signs of an FSMO role failure. It is also important for you to know how to determine which server is hosting each FSMO role. That way, if symptoms matching that of an FSMO failure occur, you can check to see which server is hosting the role that may have failed, and can then begin the troubleshooting process on that server.

The Schema Master

The Active Directory is really nothing more than a database, and like any other database, the Active Directory contains a schema. Unlike many other databases, the Active Directory’s schema is not static. There are any number of operations that require extending the schema. For example, installing Exchange Server requires the Active Directory schema to be extended. Any time that changes are made to the Active Directory schema, those changes are applied to the Schema Master.

The Schema Master is by far the most critical of the FSMO roles, so Microsoft hides it from view. If you need to find out which server is hosting the Schema Master role, then insert your Windows Server 2003 installation CD, and double click on the ADMINPAK.MSI file that’s found in the CD’s I386 directory. When you do, Windows will launch the Administration Tools Pack Setup Wizard. Follow the wizard’s prompts to install the Administration Tools pack.

When the installation process completes, close the Setup wizard and open the Microsoft Management Console by entering the MMC command at the Run prompt. When the console opens, select the Add / Remove Snap-In command from the File menu. When you do, Windows will display the Add / Remove Snap-in properties sheet. Click the Add button found on the properties sheet’s Standalone tab to reveal a list of available snap-ins. Select the Active Directory Schema snap-in from the list and click the Add button, followed by the Close and OK buttons.

Now that the snap-in has been loaded, right click on the Active Directory Schema container and select the Operations Master command from the resulting shortcut menu. You will now see a dialog box that tells you which server is acting as the forest’s Schema Master.

The Domain Naming Master

As I have already explained, an Active Directory forest can contain multiple domains. It’s the Domain Naming Master’s job to keep track of these domains. If the Domain Naming Master were to fail, then it would be impossible to create or remove domains until the Domain Naming Master comes back online.

To determine which server is acting as the Domain naming Master for the forest, open the Active Directory Domains and Trusts console. When the console opens, right click on the Active Directory Domains and Trusts container and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Domain Naming master.

The Relative Identifier

As you know, the Active Directory allows administrators to create Active Directory objects on any domain controller. The catch is that each object must have a unique relative identifier number. To prevent relative identifier numbers from being duplicated, the Relative Identifier Master allocates a pool of relative identifiers to each domain controller. When a new object is created within a domain, the domain controller that the object is being created on takes one of its relative identifiers out of its pool and assigns it to the object. When the pool is exhausted, the domain controller must contact the Relative Identifier Master for additional relative identifiers. As such, the eventual symptom of a Relative Identifier Master failure is the inability to create objects in the Active Directory.

To determine which server is acting as the Relative Identifier for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Relative Identifier by looking at the properties sheet’s RID tab.

The Primary Domain Controller Emulator

Throughout this article series, I have talked about the role that the Primary Domain Controller (PDC) plays in Windows NT environments. The PDC emulator role was created to allow Active Directory domain controllers to co-exist with Windows NT domain controllers. The basic idea was that when an organization is being upgraded from Windows NT to Windows 2000 or to Windows Server 2003, the PDC is the first domain controller to be upgraded. At that point, the newly upgraded domain controller functions both as an Active Directory domain controller and as a PDC to the domain controllers that are still running Windows NT.

Today the PDC emulator role is largely irrelevant because very few organizations still use Windows NT Server. If you need to determine which server in your domain is hosting the PDC Emulator role though, you can do so by opening the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the PDC Emulator by looking at the properties sheet’s PDC tab.

The Infrastructure Master

In an Active Directory environment, a forest can contain multiple domains. Of course the implication of this is that Active Directory domains are not completely independent entities. They must occasionally communicate with the rest of the forest. This is where the Infrastructure Master comes into play. When you create, modify, or delete an object within a domain, the change will naturally be propagated throughout the domain. The problem is that the rest of the forest is not aware of the change. It’s the Infrastructure Master’s job to make the rest of the forest aware of the change.

If an Infrastructure Master server fails then changes to objects will not be visible across domain boundaries. For example, if you were to rename a user account, the user account would still appear to have its old name when viewed from other domains in the forest.

To determine which server is acting as the Infrastructure Master for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Infrastructure Master by looking at the properties sheet’s Infrastructure tab.

As you can see, the FSMO roles play a critical role in the functionality of the Active Directory. In the next part of this article series, I will continue the discussion by talking about the structure of the Active Directory and the naming scheme used by Active Directory objects.