Home > Articles > Certification > Microsoft Certification

MCSE Exam 70-294 Prep: Operations Masters and Global Catalog Servers

In preparation for the MCSE Exam 70-294, Will Willis and David Watts define the Windows Server 2003 operations masters and what they do, and detail what actions you should take if an operations master fails or becomes unavailable.
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.


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


Schema Master


Domain Naming Master


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.


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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020