Understanding Operations Master Roles

As I mentioned earlier, all domain controllers are nearly equal in AD DS—that is, any one of them can be updated and can replicate changes to the others. This decentralization is in direct contrast to Windows NT 4.0-style domains, which had only one PDC that accepted directory object modifications and any number of BDCs that held read-only copies of the accounts database. BDCs could authenticate users, but any changes to any attributes of domain accounts had to take place in direct communication with the PDC. Because the PDC pushed out copies of the accounts database, known as the SAM database, to the BDCs for a domain, this sort of replication was known as single-master replication because one master computer communicated changes to slaved, less-capable computers.

Enter AD DS onto the scene, where there are effectively no distinctions between domain controllers in most operations. Unless your domain is functioning at the NT interim functional level (more on that in the migration section later in this chapter), all domain controllers for a domain can accept changes for data in their domain, and domain controllers have peers to which they replicate changes to those objects. This sort of setup typically is called multimaster replication because each domain controller acts as a master, passing changes to other domain controllers until those changes are replicated fully.

Replication is covered in detail in the next section, but that introduction serves as an adequate segue to a fundamental issue: this decentralized approach has problems. Some actions taken within forests and domains could cause havoc if performed simultaneously on two separate domain controllers before replication has occurred. What if:

Clearly, some domain controllers need to have greater control over others, simply because sometimes, all computers need a bit of authority. AD DS is not entirely self-governing. Microsoft took care of this problem by implementing special roles for some domain controllers in AD DS, called operations master roles. (These roles can also be called flexible single master of operations roles, pronounced "fizz-moh," but the proper term is operations masters.) There are five specific operations master roles, listed here in the order in which each corresponds with the scenarios discussed earlier:

These roles are distributed one per domain, except for the schema and domain-naming roles, which are allotted one per forest. After all, schema changes affect the forest-wide AD DS, and you shouldn't have two domains named exactly the same thing within the same AD DS forest. However, RIDs are specific to domains, PDCs are specific to individual domains, and infrastructure masters account for changes within domains only, not the whole forest.

Tip

The first domain controller in a forest assumes all five roles simultaneously. The first domain controller in the second domain of a forest assumes all three domain-specific roles simultaneously. Organizations with only one domain controller have all five roles on that one domain controller.

Schema Master

The schema master in a forest carries out a very important function—ensuring that changes to the schema, or to the actual structure of the AD DS database, are made in a consistent manner. The schema master prevents change collisions across the forest, which is a bigger problem than you might imagine and one that grows with the size of your AD DS-based network. Although you might not think the schema would change often, a few operations actually do this: for one, installing Exchange 2000 or 2003 into a domain will extend the forest-wide schema even if some domains are not using Exchange. Other AD DS-aware applications are likely to modify the schema as well, such as Microsoft's ISA Server firewall and some network and user management applications, such as those from NetIQ.

Also remember that the forest AD DS schema and the global catalog are intertwined. Recall too that the global catalog contains a subset of information from all domains within a forest. If you added new attributes to the schema and wanted to include those in the global catalog, all your domain controllers that act as global catalog servers will need to receive the change. For Windows 2000-based domain controllers, the entire global catalog must be flushed and rebuilt on each domain controller; for Windows Server 2008-based domain controllers, only the change needs to be propagated. For large organizations, this is a big bandwidth saver if most of your GC-based domain controllers are on Windows Server 2008. It is just something to keep in mind.

To identify the schema master in Windows Server 2008, computers use the Schema Management console. You will find the DLL that enables the Schema MMC snap-in—called schmmgmt.dll—under the \WINDOWS\system32 directory. Open a command-line window, navigate to that directory, and then do the following:

  1. Register the COM object by running regsvr32 schmmgmt.dll. Once this has completed, Windows should raise a dialog box to notify you.

  2. Open the MMC—using the Run option on the Start menu and typing mmc always works if you don't have a shortcut handy.

  3. Select Add/Remove Snap-In from the File Menu.

  4. In the resulting dialog box, the list of available MMC snap-ins will appear. Select Active Directory Schema, and then click Add.

  5. Close the dialogs to apply changes.

  6. Right-click the root node of the MMC in the left pane, and then select Operations Master from the context menu.

  7. The Change Schema Master dialog box will appear, and on the first line the full name of the current schema master is revealed. In smaller domains, this will be the first domain controller installed, but in larger domains, someone could have moved the role to another domain controller. This is shown in Figure 5-30.

The Change Schema Master screen

Figure 5-30. The Change Schema Master screen

To change the schema master (you must be a member of the Schema Admins group to do this) from within the Schema Management console you loaded in the previous procedure, right-click the root node labeled Active Directory Schema in the left pane, and select Change Domain Controller from the context menu. In the dialog box that appears, type the name of the domain controller to which you want to move the schema master role, and then click OK. Then, proceed from step 7 in the previous exercise, and click the Change button in the Change Schema Master dialog box. Confirm your choice, and once the processing is complete, click Close. The schema master role has been moved.

Domain Naming Master

The domain naming master role is one of the forest-specific roles, meaning that only one domain controller in the entire forest has this role. This role protects against the creation of identically named domains in the same forest—if this were to happen, AD DS could not cope with the same names and panic would result.

Keep in mind that this role is designed to be placed on a global catalog server, and not just a standalone server. It would seem that this role uses some information contained in the GC (excerpts of the directories of other domains in the forest) to fulfill its responsibilities. However, if you are operating in the Windows Server 2003 or Windows Server 2008 forest functional level, this placement is unnecessary.

To change the domain naming master role (you must be a member of the Enterprise Admins group to do this), use the Active Directory Domains and Trusts tool. Open it from the Administrative Tools menu and then:

  1. Right-click the root node in the left pane, and select Operations Master.

  2. Click Change to move the role.

RID Master

The RID master role handles the assignment and distribution of the latter portion of SIDs for objects within AD DS. You know that when an object is created in Windows, a unique SID is assigned to it. The SID comes in the form of S-1-5-21-A-B-C-RID, where the S-1-5-21 is common to all SIDs. The "A," "B," and "C" parts of the number are randomly generated 32-bit numbers that are specific to a domain, or to a particular machine (if AD DS is not installed on the server or if a workstation isn't joined to a domain). The RID, or relative identifier, part of the SID is another 32-bit number that is the unique part of the SID and identifies a distinct object in the directory.

The domain controller with the RID master role distributes groups of 500 unique RIDs to its brother and sister domain controllers with the domain, so that when they create unique objects, the SIDs they assign to those unique objects should also be unique. Much like DHCP ensures that no two workstations have the same IP address, distributing pools of RIDs in this way ensures that no two domain controllers have the same groups of RIDs to assign.

To move the RID master role to another domain controller in a domain, follow these steps:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Operations Masters.

  3. Click the RID tab, and note the name of the RID master. This is shown in Figure 5-31.

    Identifying the RID pool master

    Figure 5-31. Identifying the RID pool master

  4. Click Change to move the role.

PDC Emulator

The PDC emulator operations master role serves a very important function for mixed Windows NT Server, 2000 Server, Windows Server 2003, and Windows Server 2008 domains. As I mentioned at the beginning of this section, NT domain controllers—whether primary or backup—don't support multimaster replication, so if your PDC has been upgraded to Windows 2000 or Windows Server 2003, obviously there is no computer from which your BDCs can get updates, or at least none they can understand. Those of you familiar with Microsoft's older networking protocols know that the Master Browser service, the utility that populates Network Neighborhood and My Network Places on workstations and servers, typically runs on the PDC in an NT domain. System policies for Windows 95 are stored on the PDC, not on any BDCs. And trusts between NT domains and AD DS domains require a PDC, or a PDC emulator, because NT thinks only one computer has the read/write copy of the SAM database.

The PDC emulator runs on one domain controller in a domain to perform these functions. It also helps speed up propagation and replication of changes to two specific attributes of a user object in AD DS: the password and the account lockout attribute. Think about large organizations, and the time it can take for changes made at one domain controller to filter out. (I'll cover replication in a lot more detail in the next section, but know for now that replication can involve a considerable amount of time if you have many domain controllers handling AD DS responsibilities in your environment.) If a user called to reset a password and the help desk personnel responding to that call were in another site, the password change would take effect first on the domain controller local to the help desk personnel, not necessarily local to the person whose password was being changed. Do you really want to wait the hours it might take for that change to take effect? Of course not, so the domain controller for the help desk personnel immediately contacts the domain controller holding the PDC emulator role for the domain, and it gets that updated password, thus avoiding replication delays. So, although the local domain controller for the user might not have the new password, the local domain controller will look at the PDC emulator domain controller to check whether the password matches there. If it does, the user gets a green light to log in. (Of course, password changes aren't actually immediate—there is still lag time.)

This policy stretches to one other attribute as well. If you use account lockouts—when a password is entered incorrectly for x number of times, the account becomes temporarily disabled for a period of time—it probably wouldn't do a lot of good for only the password to be passed quickly to the PDC emulator role. The user would have the right password, but neither the PDC emulator nor the local domain controller for the user would know the account actually wasn't locked out anymore. So, the account lockout attribute is passed at the same time as a password reset, to make sure users aren't sitting, twiddling their thumbs without access to their domain user accounts while the domain controllers wait for replicated changes to arrive.

Finally, the PDC emulator handles time synchronization in a domain.

Ideally, the PDC emulator role should be on the same domain controller as the RID master role. To move the PDC emulator role, use Active Directory Users and Computers, as follows:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Connect to Domain Controller.

  3. Enter the name of the domain controller to which you want to switch the role.

  4. Then, right-click the domain name in the left pane again, and select Operations Masters from the context menu.

  5. Click the PDC tab, and note the name of the PDC emulator master. This is shown in Figure 5-32.

  6. Click Change to move the role.

Identifying the PDC emulation master

Figure 5-32. Identifying the PDC emulation master

Infrastructure Master

The infrastructure master also helps to speed up propagation and replication of certain pieces of information among domain controllers. The infrastructure master role is designed to not be on a domain controller functioning as a GC server—that is, unless every domain controller in your domain is a GC server as well, or if you have only one domain.

To find out and change which domain controller holds the infrastructure master role, use the Active Directory Users and Computers tool. As before, if you have only one domain controller in your domain, that is obviously the infrastructure master. In larger domains, to identify and/or change this machine, follow these steps:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Connect to Domain Controller.

  3. Enter the name of the domain controller to which you want to switch the role.

  4. Then, right-click the domain name in the left pane again, and select Operations Masters from the context menu.

  5. Click the Infrastructure tab, and note the name of the infrastructure master. This is shown in Figure 5-33.

  6. Click Change to move the role to the domain controller of focus.

Changing the infrastructure master

Figure 5-33. Changing the infrastructure master

Transferring and Seizing Roles Manually

Sometimes you might need to change the operations master roles that domain controllers are playing without necessarily using the graphical interface. It might be that you inadvertently unplugged and reformatted your first domain controller in your domain too early, without transferring its roles elsewhere. Or maybe your specific server is temporarily offline but you really need a role transferred as soon as possible.

Tip

If your PDC emulator domain controller or infrastructure masters are offline, it is OK to transfer these roles through the GUI using the aforementioned procedures. You'll need to confirm the offline transfer a couple of times before it will go through, but eventually it will succeed.

Windows Server 2008 comes with the NTDSUtil tool, a command-line utility that allows you to perform AD DS maintenance that goes above and beyond what the GUI tools allow. In this case, you might need to transfer the schema master, domain naming master, or RID master roles—or you might need to force that transfer if the original holder of those roles is unavailable.

To transfer a role using NTDSUtil, open a command prompt and run NTDSUTIL. Then follow these steps:

  1. Enter roles to switch into FSMO Maintenance mode.

  2. Enter connections to enter the Server Connections context.

  3. Enter connect to <targetcomputer>, where <targetcomputer> is the computer to which you want to transfer the role.

  4. Enter quit to leave the Server Connections context.

  5. Enter transfer schema master, transfer domain naming master, or transfer rid master, whichever is appropriate, to transfer the role you want. NTDSUtil will attempt to contact the current holder of that operations master role. If it can, and that machine approves the transfer, your operation is complete. However, if for some reason the utility can't contact that computer, error messages will result.

If you find error messages when you're simply attempting a transfer, you can force the role transfer by using the SEIZE command. After step 4 in the previous procedure, start the following:

  1. Enter seize schema master, seize domain naming master, or seize rid master to force the transfer of the role to the target computer.

  2. Type quit to leave NTDSUtil once the seizure is complete.

Warning

Once you have seized a role, never let the previous holder of that role back onto the network unless you've reformatted the machine. I repeat: never, ever do this. The previous holder doesn't know the roles were transferred and is not able to figure it out for itself. Picture a bitter custody battle.