Windows Server 2003 : Active Directory - Understanding Operations Master Roles

All domain controllers are nearly equal in Active Directory—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 Active Directory 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 , 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 this 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:

• Two people made changes to the attributes of the Active Directory schema on two separate domain controllers and created an attribute named CC—one person wanted that attribute to be for credit card numbers, and another meant wanted it to be for calling card numbers. Which would be which, and under what circumstances?

• An administrator in one location, geographically separate from his company's headquarters, created a new domain, and then eight hours later at the headquarters complex (before replication took place) someone else created the same domain, thinking it hadn't been done yet. Which domain wins?

• Two distinct domain controllers were doling out security IDs (SIDs) to new objects, and by chance one object on one domain controller was assigned the same SID as another object on the other domain controller. How would Active Directory keep track of these two unique objects if they have the same SID?

• You still have NT domain controllers acting as BDCs on your network. (This is very, very common now.) As you know, those NT domain controllers aren't capable of multimaster replication, so all of them need to agree on one place from which they can get updates to their SAMs. Which Windows Server 2003 or Windows 2000 Server-based domain controller would perform this role?

• You renamed a user or made a user a member of a certain group, and you were attached to one domain controller but that change needed to replicate to the domain controller that's local to the user whom you're administering. How might you speed up replication for those essential attributes—how can they take priority over, say, changes to phone numbers for a user in Active Directory?

Clearly, some domain controllers need to have greater control over others, simply because sometimes, all computers need a bit of authority. Active Directory is not entirely self-governing. Microsoft took care of this problem by implementing special roles for some domain controllers in Active Directory, called operations master roles. (These roles also can 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, and each is listed here in the order in which it corresponds with the scenarios discussed earlier:

• Schema master (one per forest)

• Domain naming (one per forest)

• RID pool (one per domain)

• PDC emulator (one per domain)

• Infrastructure (one per domain)

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 forestwide Active Directory, and you shouldn't have two domains named exactly the same within the same Active Directory 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.

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.

1. 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 Active Directory 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 Active Directory-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 forestwide schema even if some domains are not using Exchange. Other Active Directory-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 recall that the forest Active Directory schema and the global catalog are intertwined. Recall also 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 2003-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 2003. It is just something to keep in mind.

To identify the schema master on Windows 2000 Server and Windows Server 2003, 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, click Add. The list of available MMC snap-ins will appear.

5. Select Active Directory Schema, and then click Add.

6. Close the dialogs to apply changes.

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

8. 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 1.

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.

Figure 1. The Change Schema Master dialog box

2. 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, Active Directory 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 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 right-click the root node in the left pane of the window and select Change Domain Controller from the pop-up context menu. Type the name of the domain controller to which you want to move the role, and then click OK. The focus of the management console will switch to this domain controller. Then follow these steps:

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

2. Click Change to move the role.

3. RID Master

The RID master role handles the assignment and distribution of the latter portion of SIDs for objects within Active Directory. You know that when objects are 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 Active Directory 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 ADUC.

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 RID tab, and note the name of the RID master. This is shown in Figure 2.

6. Click Change to move the role.

4. PDC Emulator

The PDC emulator operations master role serves a very important function for mixed Windows NT Server, 2000 Server, and Windows Server 2003 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 Active Directory domains require a PDC, or a PDC emulator, because NT thinks only one computer has the read/write copy of the SAM database.

Figure 2. Identifying the RID pool master

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 Active Directory: 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 Active Directory 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 if 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 ADUC, as follows:

1. Open ADUC.

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 3.

6. Click Change to move the role.

Figure 3. Identifying the PDC emulator master

5. 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 ADUC 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 ADUC.

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 infrastructure master. This is shown in Figure 4.

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

Figure 4. Identifying the infrastructure master

6. 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.

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 2003 comes with the NTDSUtil tool, a command-line utility that allows you to perform Active Directory 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.

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.

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.