Operations Masters and Global Catalog Servers
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
-
Single-master replication
-
Operations master
-
PDC Emulator
-
RID Master
-
Infrastructure Master
-
Schema Master
-
Domain Naming Master
-
Transferring a role
-
Seizing a role
-
Ntdsutil
-
Global Catalog (GC)
-
Universal group
Techniques/concepts you'll need to master:
-
Identifying operations master role dependencies
-
Planning for business continuity of operations master roles
-
Planning a strategy for placing Global Catalog servers
-
Evaluating network traffic considerations when placing Global Catalog servers
-
Evaluating the need to enable Universal Group Membership Caching
Although it's true to say that all domain controllers (DCs) act as peers on a Windows Server 2003 network when Active Directory (AD) replication is used, at times the peer model does not achieve the desired result. Some functions on a network are best suited to being controlled by a single DC. These functions include implementing security measures, ensuring compatibility with down-level (Windows 2000 and Windows NT 4) servers, and ensuring that the security identifiers (SIDs) of the clients created in a domain are unique.
To this end, Microsoft has implemented operations masters. Operations masters have a unique role to play on your network. Management of operations masters is essential to ensuring that you have a healthy and efficient Windows Server 2003 network. In this chapter, we define the operations masters and what they do. We also discuss what actions you should take if an operations master fails or becomes unavailable. In addition, we talk about how the role of an operations master can be moved from one DC to another and what you should do if the original operations master comes back online.
Introducing Operations Masters
When replicating AD data, Windows Server 2003 uses a multimaster concept. This means that any DC can accept a change to AD data, and this change will then be replicated to all partner DCs, who replicate with their partners in the domain and/or forest, and so on, until all domain controllers have received the change. Replication conflicts can, and do, occur. Additionally, some operations that occur on a Windows Server 2003 network could be harmful if conflicts were to occur. In the case of these operations, Windows Server 2003 reverts to using single-master replication. This means that a single DC on the network takes responsibility for performing a specific task. Microsoft uses the term role to describe the task that this DC performs. There are five distinct roles, collectively known as Flexible Single Master Operations (FSMO) roles, or simply operations master roles. When a DC has been assigned a role, it becomes the operations master for that role.
Data regarding which DCs are functioning as operations masters is stored in AD. When a client needs to get in touch with an operations master, the client simply queries AD. There are no specific requirements a DC must meet to function as an operations master. This gives you flexibility in deciding which DC takes on the task. It also means that roles can be moved from one DC to another. This becomes more important when a DC acting as an operations master fails.
NOTE
Although there are no requirements for which DC can act as a specific operations master, pay particular attention to the section "Recommendations for Operations Masters" later in this chapter. For efficiency reasons, it makes sense to assign specific roles to particular DCs.
Identifying Operations Master Role Dependencies
Each of the five operations master roles that exist on your network has a scope—that is, some of the roles are specific to a domain, whereas others play a role in the entire forest. The five operations masters and their corresponding scopes are set out in Table 3.1. Your Windows Server 2003 network may have five servers that are acting as operations masters (this would be the case in a single-domain environment), or it could have more.
Knowing this fact becomes important when you are deciding which DC should play a specific role on your network. Once you understand each of the roles, you can decide where best to have a role placed for maximum efficiency.
Table 3.1 Operations Masters and Their Scopes
|
Operations Master |
Scope |
|
Schema Master |
Forestwide |
|
Domain Naming Master |
Forestwide |
|
Primary Domain Controller (PDC) Emulator |
Specific to a domain |
|
Relative Identifier (RID) Master |
Specific to a domain |
|
Infrastructure Master |
Specific to a domain |
Because three of the five types of operations masters are domainwide, you will have several servers in your environment playing that role. Working out the correct placement of the domainwide roles is easier than doing the same thing for the forestwide roles. This is because the forestwide roles must be placed in a location that offers administrators easy and fast access, which can be difficult on wide area networks (WANs).
All Windows Server 2003 installations start with a single server (if this is a migration, it is the first server upgraded). The first server installed takes on all roles. This is unlikely to be optimal for your network, and you should move the roles to other servers as they come online. (We talk about moving roles to other servers in the "Determining Operations Master Roles" section later in this chapter.) Because the first server also operates as a Global Catalog server and DC, the first server installed will be a little overloaded.
When you install a second domain into your Windows Server 2003 network, the first DC that joins the forest for this new domain assumes the three roles that are domain based. Once again, this may not be feasible from a performance standpoint. These default behaviors should be considered carefully when you are designing your network.
Now let's define what each role achieves. Once you fully understand why these roles exist, you can better plan their placement on your network.
Schema Master
AD is a database built up of instances of objects and objects' attributes. The class of objects and the attributes these objects can have are defined in the schema for the directory. There must be no conflicts when changes are being made to the schema. For instance, with multimaster replication, any DC can make an update to AD data. If any DC were able to make additions or deletions from the schema, you would end up with replication problems. For example, let's say you created a new object type called Database Servers. Replication should take care of letting all other DCs know about this change. But what happens if replication is not yet able to replicate out this schema change to all DCs? You could end up with a situation where one DC is attempting to replicate AD data, but its replication partner doesn't even know the object type is possible!
To go one step further, the schema is obviously a very important piece of AD. Because it defines what can exist within the directory, managing the process of updating it with new objects and attributes should be a closely monitored process. To ensure that this process is limited, there is a single read/write copy of the schema on your Windows Server 2003 network, stored on the Schema Master. In addition, only members of the Schema Admins group can make changes to the schema. Once a change has been made to the schema, the Schema Master then takes on the task of replicating this change to all DCs in the forest.
There is a single Schema Master per forest.
Domain Naming Master
All objects within AD must be unique. That is, you cannot create two objects in a container with the same name. To make sure this is the case, Windows Server 2003 must ensure that new domains added to your Windows Server 2003 network have unique names. This is the job of the Domain Naming Master.
The Domain Naming Master manages the addition and deletion of domains from the forest. This means that whenever you want to add a domain to your Windows Server 2003 network, a call must be made to the Domain Naming Master. You will not be able to add or remove a domain if this connection cannot be made. Domains are added to Windows Server 2003 by running dcpromo.exe. This wizard contacts the Domain Naming Master on your network automatically.
In Windows 2000, the Domain Naming Master was also required to be a Global Catalog (GC) server. As a result, if you are running your forest at the Windows 2000 mixed mode or Windows 2000 native mode functional level, you are required to have the Domain Naming Master on a GC server. Once you are running at the Windows Server 2003 functional level, the GC server requirement for the Domain Naming Master is lifted. Global Catalog servers are discussed later in this chapter.
There is a single Domain Naming Master per forest.
Primary Domain Controller (PDC) Emulator
The PDC Emulator plays several important roles on your Windows Server 2003 network. To understand these roles, remember that a Windows Server 2003 network can operate at one of three functional levels: Windows 2000 mixed mode, Windows 2000 native mode, and Windows Server 2003. Windows 2000 mixed mode means that you have Windows NT 4 servers acting as backup domain controllers (BDCs) alongside Windows 2000 and/or Windows Server 2003 DCs. You cannot change to Windows 2000 native mode until these Windows NT 4 domain controllers have been eliminated from your network. You can have Windows NT 4 member servers in a Windows 2000 native mode domain, just not domain controllers.
The PDC Emulator acts as a conduit between the newer Windows Server 2003 DCs and the older-style Windows NT 4 BDCs. The PDC Emulator is, in effect, the PDC for older Windows NT computers. It takes care of replicating AD data to Windows NT BDCs.
The role of synchronizing older-style DCs with the newer DCs is a two-way street. For instance, if a user object is created within AD, the PDC Emulator makes sure this object is also replicated to older-style DCs. Also, if an older client—a Windows 95 client, for instance—makes a password change, the PDC Emulator accepts the change in the context of being the PDC and replicates that data to AD.
Another area of importance for the PDC Emulator has to do with replication latency, which is the amount of time it takes for a change made in AD to be copied to all replicas. Despite your best efforts, there is no way for this to be done in real time; it takes time for data to be processed and for packets to travel across the cable. Generally, this is not a problem, but in the case of users' passwords, it can be debilitating. For instance, say a user changes her password. This change is made at a DC in Houston. Before this DC has had a chance to replicate this password change to all other DCs, the user logs off and tries to log on again. This time, the user connects to a different DC. Because this DC does not have a copy of the new password, the logon attempt is declined.
To prevent this from happening, all password changes on a Windows Server 2003 network are preferentially replicated to the PDC Emulator. Before a DC rejects a logon attempt, it contacts the PDC Emulator to see if any recent changes to the password have taken place. If they have, the PDC Emulator can replicate this data immediately.
The PDC Emulator in a domain also operates as the time-synchronization master. All DCs in a Windows Server 2003 domain synchronize their time with the PDC Emulator. The PDC Emulator in a domain synchronizes its time with the PDC Emulator in the root domain (the first domain installed on your network). The PDC Emulator for the root domain should be synchronized with an external source.
One final area of concern is Group Policy Objects (GPOs). These objects are automatically edited on the PDC Emulator. Although this is not essential for your network, editing these objects on a single server helps eliminate any possible conflicts. This is the default action.
There is a single PDC Emulator per domain.
RID Master
AD is made up of objects known as security principals. A security principal is essentially something that can be assigned permissions within a Windows Server 2003 network. This includes users, groups, and computers. Each security principal is assigned a security identifier (SID) so it can be identified. This descriptor is unique to the object and must always remain unique.
A SID is made up of two components. The first component, the domain SID, is common to all security principals in a domain. Because it is common to all objects within a domain, the domain SID alone does not allow objects to have a unique SID. The uniqueness comes from the addition of a second number, the relative identifier (RID). The RID is assigned from a pool of RIDs stored at each DC. The RIDs in this pool are assigned to each DC by the RID Master.
RIDs are assigned to each DC in blocks. Once the block of RIDs is exhausted, the DC requests another block from the RID Master. The RID Master keeps track of which RID blocks have been assigned. This ensures uniqueness.
NOTE
If the RID pool on a DC is exhausted and the RID Master is not available, you will not be able to create security principals on that server, which could lead to seemingly strange errors when trying to add objects from a client workstation. You can view the pools by using the Dcdiag utility.
The RID Master also has a role to play when objects are being moved from one domain to another. In this case, the RID Master ensures that an object is not moved to multiple domains. Further, it deletes the object from the previous domain.
There is a single RID Master per domain.
Infrastructure Master
The domain partition of AD contains data about objects that exist within the domain only. It might also contain references to objects from other domains. This occurs, for instance, when you grant permissions for users that exist in other domains to resources in your domain. Universal groups can be used for this purpose (groups are discussed in detail in Chapter 4, "User and Group Administration").
If a change is made to a referenced object, these changes need to be replicated to all domains. It is the job of the Infrastructure Master to receive these changes and to replicate them to all DCs in its domain.
Let's use an example to clarify this process. A user object named Lisa Arase exists in the Asia domain, and it is referenced in the Europe domain. The Lisa Arase object is then moved from the Asia domain to the Americas domain. This means the SID for the user changes. (Don't forget, the SID is made up of two components: the domain SID, which in this case will change, and the RID.) This change must be made in both the Asia domain and the Americas domain, and the reference in Europe must also be updated. The Infrastructure Master will make this change in Europe.
NOTE
The Infrastructure Master records references to objects that it does not contain in its directory partition. In our example, this means that although it contains a reference to the user object Lisa Arase, it does not contain any other object data. It is this distinction that allows the Infrastructure Master to work. If the Infrastructure Master is also a Global Catalog server (which contains a reference to all objects created in a forest), the Infrastructure Master will know about all objects in the forest, and the comparison will not work. This breaks the Infrastructure Master's operation. Therefore, the Infrastructure Master cannot also be a Global Catalog server.
Because there will be no references to external objects in a single domain, there is no need to worry about the Infrastructure Master in a single-domain environment.
There is a single Infrastructure Master per domain.