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.

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.