Along with basic duties, a Windows 2000 server must keep Active Directory running, which can bog down the server. To help manage the load, certain servers are assigned roles of handling tasks within the Windows 2000 forest. However, there may come a time, due to server failure, maintenance, etc., when you will need to move these roles from one server to another. In this Daily Drill Down, I’ll explore situations where you might need to move a server role, and then I’ll explain the effects of doing so.

A crash course in server roles
A role is a specific type of task that’s assigned to a domain controller within AD. There are two basic types of roles, forest-specific roles and domain-specific roles. With a forest-specific role, only one domain controller in the entire forest occupies the role. Domain controllers performing forest roles are critical to the functionality of the entire AD. In fact, servers functioning in a forest-specific role would affect the entire AD if they were to go down. However, servers performing domain-specific roles are found in every Windows 2000 domain. When a server that’s conducting a domain-specific role fails, only that domain is affected by the failure.

There are two forest-wide roles, Schema Master and Domain Naming Master. Windows designates the first domain controller in the domain as the Schema Master. Because all domain controllers in the entire forest use the same AD schema, the forest needs only one Schema Master. Any time that a change is made to the AD schema, the change is also made on the Schema Master.

By default, the Domain Naming Master is also found on the first domain controller within a forest. Another name for the Domain Naming Master is the Global Catalog server. In this role, the domain controller contains a record of every object within the forest. Any time that you create or rename an object, the Domain Naming Master makes sure the new object’s full DNS name is unique within the forest. So you can’t add or remove domains from the forest when the Domain Naming Master is down.

There are three domain-specific roles you need to know about:

  • Infrastructure Master
  • RID Master
  • PDC Emulator

You’ll have a separate domain controller performing these roles within each domain.

The Infrastructure Master ensures that objects within the domain and objects found in the global catalog are consistent. The RID Master domain controller distributes relative identifiers to the other domain controllers within the domain. Finally, Windows NT machines see the PDC Emulator domain controller as the primary domain controller within a mixed mode environment.

Need to know more about domain controllers?

For more detailed information about domain controllers and the roles they can assume, see the Daily Drill Down “Understanding Windows 2000 domain controller operations master roles.”

Reasons for moving a role
You can achieve a significant performance gain by moving a role from an overworked domain controller to another domain controller that’s less frequently used. However, unless a server’s performance is extremely slow, it might be better to leave the roles as they are. When it comes to networking, I’ve always said, “If it isn’t broken, you shouldn’t fix it.” Any time you make a major AD change, there’s a chance that something could go wrong that might cause the network to go down. I’ve spent many nights cleaning up messes caused by a “quick and harmless change.”

Of course, there are reasons other than performance gains for moving server roles. Remember that AD is highly dependant on the various server roles. From a role standpoint, when a server performing one of the various roles goes down for a short period of time, it’s usually no big deal, as long as no one is trying to make major changes to AD during the downtime.

However, if you know that a domain controller that’s responsible for one of the roles is going to be down for maintenance, etc., you might want to move the role to a different server prior to the downtime. You would want to do this primarily in situations in which your company is so big that AD changes are being made quite frequently, so it’s nearly impossible to keep people from making Active Directory changes during the downtime. This would also apply in situations in which the server will be down, or potentially unreliable, for an extended period of time.

If you’re trying to decide whether to move a role during a maintenance operation, consider the fact that some server roles are more important than others. For example, a server role that only affects a single domain isn’t quite as important as a role that services an entire forest, unless the forest is made of only one domain.

Operations master failures
When a server performing an operations master role goes down, you may at first only notice the obvious effects, such as problems logging on or rights not appearing properly that are felt any time that any server goes down. Eventually though, AD will no longer work properly. The actual effects depend greatly on which operations master has failed and how long it has been down. The effects can be anything from the inability to reset passwords to users not being able to logon to a breakdown of AD services.

One of the strangest things about operations master role failures is that many times their effects can be misread as other problems. For example, in a Windows NT environment, if a client has trouble performing some operation with a server, the problem had to be with either the client or with the server, assuming that the user had successfully authenticated into the network in the first place. In an AD environment, however, it’s entirely possible that the problem could be related to an operations master role on an entirely different server. An inexperienced technician might examine the client and server all day long and never find the source of the problem.

When the Schema Master goes down, there won’t be any effect on the users. The administrators will be affected by the failure only if they try to modify the schema or install an application that needs to modify the schema. Likewise, a Domain Naming Master failure doesn’t affect the users and will only affect administrators if they are trying to add a domain to or remove a domain from the forest. However, just because there are no immediate consequences to these types of failures doesn’t mean that such a failure should be ignored.

Relative Identifier Master failures also go unnoticed by users. Administrators will notice such a failure if they are creating AD objects and run out of relative identifiers. An Infrastructure Master failure doesn’t affect users but is noticeable to administrators if they’ve recently tried to move or rename large numbers of accounts.

The type of failure that immediately affects everyone, though, is a PDC Emulator failure. In such a failure, some users may not be able to log on to the network. Of course this issue becomes much less pressing in a native mode environment, because the PDC Emulator doesn’t really affect native mode.

What do I do about roles that need to be changed?
AD can’t function unless the various operations master roles are being performed, so if a system that’s performing one of the operations master roles dies, you’ll need to move the role to another server. There are two ways to do this: transfer the role or seize the role.

Transferring roles is the easier of the two methods, because you can do so from within the GUI. If the server performing a specific role is still live or is down only temporarily and you need to move the role to a different server, you’ll have to transfer the role. Seizing a role is used only in situations in which the domain controller that currently has the role is completely dead.

Windows 2000 servers are constantly doing things in the background that you need to be aware of. To keep AD working smoothly, Windows 2000 divides up maintenance tasks across several servers. Normally, it does a fine job of assigning roles, but if the wrong server has the wrong role or if a server crashes, you have to know what it will affect and what your options are. Then you can identify the problem and correct it.