We've all been taught at one time or another that on a Windows network, if at least one domain controller within each domain is functional, then the domain itself should be functional. Sadly, this idea hasn't been completely true since Windows NT went extinct. Even if a domain has functional domain controllers, there are several things that can cause users to not be able to log in, or that can cause Administrators not to be able to manage the domain. In this article, I will discuss some of those causes.
I will start out by starting about the most bizarre issue first. Believe it or not, if the clocks are set wrong on your domain controllers, the Active Directory may not function. The time on your domain controllers must be accurate within five minutes of each other. Domain controllers with clocks that are out of synch by more than five minutes are not honored by the Active Directory until the clock is reset.
Global catalog server failure
When you create a domain within a forest, then the first domain controller within that domain is designated as a global catalog server. Windows uses the global catalog to help it to locate objects within the Active Directory. A global catalog failure is a serious problem though. If your global catalog server goes down, then nobody except for the Administrator will be able to log in until the global catalog server becomes available again.
The easiest way to prevent a global catalog server failure from causing a major disruption to your network is to designate a second domain controller to act as a global catalog server. To do so, open the Active Directory Sites and Services console and navigate through the console tree to Active Directory Sites and Services | Sites | Default First Site Name | Servers | the server that you want to set as a global catalog server | NTDS Settings. Next, right click on the NTDS Settings container and select the Properties command from the resulting shortcut menu to reveal the NTDS Settings Properties sheet. Select the Global Catalog check box and click OK.
DNS server failure
There is no way that I can possibly discuss this issue in any kind of detail in the amount of space that I have to work with. However, I would be extremely negligent if I didn't at least mention that the Active Directory is completely dependent on the DNS services. If you suddenly have an unexplained Active Directory problem, then one of the first things that you should do is to make sure that your DNS server is functional and that your domain controller's TCP/IP settings are still configured to use your DNS server.
Operations master roles
Earlier I mentioned that it is possible for the Active Directory to malfunction even if most of the domain controllers appear to be functional. The reason for this is because not all domain controllers are created equally. Some domain controllers are assigned special tasks, known as operations master roles. There are five different operations master roles. Two of these roles are performed at the forest level and are assigned by default to the first domain controller to be made a part of the forest (the domain naming master role and the schema master role). The other three roles (the PDC emulator role, the relative identifier master role, and the infrastructure master role) are performed at the domain level and are assigned by default to the first domain controller in each domain.
In the next several sections, I will explain what these roles are and what the symptoms are of a role failure.
Domain naming master
The first forest level role that I want to discuss is the domain naming master role. This role is held by default by the first domain controller that is set up in the forest. The domain naming master's purpose is to act as an authoritative collection of domain names. Whenever an administrator tries to create a new domain, the Active Directory checks with this server to make sure that a domain by that name does not already exist. The consequence of a domain naming master failure is that you will be unable to create new domains until the problem is fixed.
Schema master role
Like the domain naming master, the schema master is also a forest level role. The schema master's purpose is to maintain the Active Directory schema. Anytime that a change is made to the Active Directory schema, the change is applied directly to this server. Like the domain naming master, schema master failures typically go unnoticed until an administrator or an application attempts to update the AD schema.
The PDC emulator role is basically just a role that is assigned to one of your domain controllers in an effort to make it the Active Directory backward compatible with Windows NT. If the server that has been assigned the PDC emulator role were to fail, then the symptoms of the failure will vary depending on how your network is set up.
If you have Windows NT domain controllers on your network than a PDC emulator failure is just like having the PDC fail in a pure Windows NT environment. If you don't have any domain controllers running Windows NT, then there are no direct consequences to a PDC emulator failure. Keep in mind though that by default, the domain controller that is acting as the PDC emulator is also hosting the Relative Identifier and Infrastructure Master roles, and as I will explain in a minute, there are consequences to failures involving those roles.
Relative identifier master failure
The primary symptom of a Relative Identifier Master failure is that you suddenly stop being able to create Active Directory objects. The Relative Identifier Master assigns all newly created Active Directory objects a relative identifier. The Relative Identifier master gives the Active Directory relative identifiers in bulk. That way, when new Active Directory objects are created, Administrators don't have to worry about the delay associated with retrieving relative identifiers from the relative identifier master. However, when the pool of relative identifiers runs dry, the Active Directory has to contact the Relative Identifier Master for more. This is usually when a Relative Identifier problem is noticed.
Infrastructure master failure
If you find that you are unable to move or modify large numbers of objects within the Active Directory, then the problem could be related to an infrastructure master failure. The infrastructure master role is responsible for maintaining the consistency of objects within the domain and objects within the global catalog.
Locating operations master roles
If you are experiencing any of the symptoms that I have just described, then you will probably want to check out which domain controller is holding the malfunctioning role so that you can fix the problem. Figuring out which servers are assigned to hold domain level roles is simple. You can identify the operations master roles for a domain through the Active Directory Users and Computers console. To do so, open the Active Directory Users and Computers console. When the console opens, right click on the Active Directory Users and Computers node in the column on the left, and select the All Tasks | Operations Masters commands from the resulting shortcut menus. You will now see a properties sheet that displays the various operations master roles for the current domain.
Checking which servers are holding the forest level roles isn't quite as simple. To identify the server that's holding the domain naming master role, you will have to go through the Active Directory Domains and Trusts console. Begin by opening the Active Directory Domains and Trusts console, right click on the Active Directory Domains and Trusts node, and select the Operations Master command from the resulting context menu. When you do, you'll see a dialog box that provides you with the name of the server that's currently assigned the Domain Naming Master role.
Locating the schema master role is a little more difficult. Before you can view this role, you will have to install the Active Directory Schema snap in. To do so, log into a domain controller as an Administrator. Next, open a Command Prompt window and enter the following command:
This command installs the necessary snap in. Now we can get on with the business of figuring out which server holds the schema master role. To do so, enter the MMC command at the Run prompt. When you do, an empty Microsoft Management Console will open. Select the Add / Remove Snap In command from the File menu to display the Add / Remove Snap In properties sheet. Click the Add button to display a list of all of the 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. You'll now see the Active Directory Schema snap in displayed within the console.
To display the name of the server that's acting as the schema master, right click on the Active Directory Schema node that's located in the column on the left and then select the Operations Master command from the resulting shortcut menu. You'll now see a dialog box that identifies the schema master.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.