What are the FSMO Roles in Active Directory?

Windows 2000/2003 Multi-Master Model

A multi-master enabled database, such as the Active Directory, provides the
flexibility of allowing changes to occur at any DC in the enterprise, but it also
introduces the possibility of conflicts that can potentially lead to problems once
the data is replicated to the rest of the enterprise. One way Windows 2000/2003
deals with conflicting updates is by having a conflict resolution algorithm handle
discrepancies in values by resolving to the DC to which changes were written
last (that is, "the last writer wins"), while discarding the changes in all other
DCs. Although this resolution method may be acceptable in some cases, there
are times when conflicts are just too difficult to resolve using the "last writer
wins" approach. In such cases, it is best to prevent the conflict from occurring
rather than to try to resolve it after the fact.

For certain types of changes, Windows 2000/2003 incorporates methods to

prevent conflicting Active Directory updates from occurring.

Windows 2000/2003 Single-Master Model

To prevent conflicting updates in Windows 2000/2003, the Active Directory
performs updates to certain objects in a single-master fashion.

In a single-master model, only one DC in the entire directory is allowed to

process updates. This is similar to the role given to a primary domain controller
(PDC) in earlier versions of Windows (such as Microsoft Windows NT 4.0), in
which the PDC is responsible for processing all updates in a given domain.

In a forest, there are five FSMO roles that are assigned to one or more domain
controllers. The five FSMO roles are:

Schema Master:

The schema master domain controller controls all updates and modifications to
the schema. Once the Schema update is complete, it is replicated from the
schema master to all other DCs in the directory. To update the schema of a
forest, you must have access to the schema master. There can be only one
schema master in the whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of
domains in the forest. This DC is the only one that can add or remove a domain
from the directory. It can also add or remove cross references to domains in
external directories. There can be only one domain naming master in the whole
forest.
Infrastructure Master:

When an object in one domain is referenced by another object in another

domain, it represents the reference by the GUID, the SID (for references to
security principals), and the DN of the object being referenced. The
infrastructure FSMO role holder is the DC responsible for updating an object's
SID and distinguished name in a cross-domain object reference. At any one
time, there can be only one domain controller acting as the infrastructure master
in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller
that is not a Global Catalog server (GC). If the Infrastructure Master runs on a
Global Catalog server it will stop updating object information because it does not
contain any references to objects that it does not hold. This is because a Global
Catalog server holds a partial replica of every object in the forest. As a result,
cross-domain object references in that domain will not be updated and a
warning to that effect will be logged on that DC's event log. If all the domain
controllers in a domain also host the global catalog, all the domain controllers
have the current data, and it is not important which domain controller holds the
infrastructure master role.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain
controllers in a particular domain. When a DC creates a security principal object
such as a user or group, it attaches a unique Security ID (SID) to the object.
This SID consists of a domain SID (the same for all SIDs created in a domain),
and a relative ID (RID) that is unique for each security principal SID created in a
domain. Each DC in a domain is allocated a pool of RIDs that it is allowed to
assign to the security principals it creates. When a DC's allocated RID pool falls
below a threshold, that DC issues a request for additional RIDs to the domain's
RID master. The domain RID master responds to the request by retrieving RIDs
from the domain's unallocated RID pool and assigns them to the pool of the
requesting DC. At any one time, there can be only one domain controller acting
as the RID master in the domain.

PDC Emulator:

The PDC emulator is necessary to synchronize time in an enterprise. Windows

2000/2003 includes the W32Time (Windows Time) time service that is required
by the Kerberos authentication protocol. All Windows 2000/2003-based
computers within an enterprise use a common time. The purpose of the time
service is to ensure that the Windows Time service uses a hierarchical
relationship that controls authority and does not permit loops to ensure
appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator
at the root of the forest becomes authoritative for the enterprise, and should be
configured to gather the time from an external source. All PDC FSMO role
holders follow the hierarchy of domains in the selection of their in-bound time
partner.
In a Windows 2000/2003 domain, the PDC emulator role holder retains the
following functions:

• Password changes performed by other DCs in the domain are replicated

preferentially to the PDC emulator.
• Authentication failures that occur at a given DC in a domain because of
an incorrect password are forwarded to the PDC emulator before a bad
password failure message is reported to the user.
• Account lockout is processed on the PDC emulator.
• Editing or creation of Group Policy Objects (GPO) is always done from the
GPO copy found in the PDC Emulator's SYSVOL share, unless configured
not to do so by the administrator.
• The PDC emulator performs all of the functionality that a Microsoft
Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows
NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary when all workstations,
member servers, and domain controllers that are running Windows NT 4.0 or
earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs
the other functions as described in a Windows 2000/2003 environment.

At any one time, there can be only one domain controller acting as the PDC
emulator master in each domain in the forest.

What are the considerations for the FSMO

placement in Active Directory?
Windows 2000/2003 Active Directory domains utilize a Single Operation Master
method called FSMO (Flexible Single Master Operation), as described in
Understanding FSMO Roles in Active Directory.

In most cases an administrator can keep the FSMO role holders (all 5 of them) in
the same spot (or actually, on the same DC) as has been configured by the
Active Directory installation process. However, there are scenarios where an
administrator would want to move one or more of the FSMO roles from the
default holder DC to a different DC.

Windows Server 2003 Active Directory is a bit different than the Windows 2000
version when dealing with FSMO placement. In this article I will only deal with
Windows Server 2003 Active Directory, but you should bear in mind that most
considerations are also true when planning Windows 2000 AD FSMO roles.

Single Domain Forest

In a single domain forest, leave all of the FSMO roles on the first domain
controller in the forest.
You should also configure all the domain controller as a Global Catalog servers.
This will NOT place additional stress on the DCs, while allowing GC-related
applications (such as Exchange Server) to easily perform GC queries.

Multiple Domain Forest

In a multiple domain forest, use the following guidelines:

• In the forest root domain:

• If all domain controllers are also global catalog servers, leave all
of the FSMO roles on the first DC in the forest.
• If all domain controllers are not also global catalog servers, move
all of the FSMO roles to a DC that is not a global catalog
server.
• In each child domain, leave the PDC emulator, RID master, and
Infrastructure master roles on the first DC in the domain, and ensure that
this DC is never designated as a global catalog server (unless the
child domain only contains one DC, then you have no choice but to leave
it in place).

Configure a standby operations master - For each server that holds one or
more operations master roles, make another DC in the same domain available as
a standby operations master. Making a DC as a standby operation master
involves the following actions:

• The standby operations master should not be a global catalog server

except in a single domain environment, where all domain controllers are
also global catalog servers.
• The standby operations master should have a manually created
replication connection to the domain controller that it is the standby
operations master for, and it should be in the same site.
• Configure the RID master as a direct replication partner with the standby
or backup RID master. This configuration reduces the risk of losing data
when you seize the role because it minimizes replication latency.

To create a connection object on the current operations master:

1. In Active Directory Sites and Services snap-in, in the console tree in the
left pane, expand the Sites folder to see the list of available sites.
2. Expand the site name in which the current role holder is located to
display the Servers folder.
3. Expand the Servers folder to see a list of the servers in that site.
4. Expand the name of the server that is currently hosting the operations
master role to display NTDS Settings.
5. Right-click NTDS Settings, click New, and then click Connection.
6. In the Find Domain Controllers dialog box, select the name of the
standby operations master then click OK.
7. In the New Object-Connection dialog box, enter an appropriate name for
the connection object or accept the default name and click OK.
To create a connection object on the standby operations master perform the
same procedure as above, and point the connection to the current FSMO role
holder.

Note regarding Windows 2000 Active Directory domains: If the forest is

set to a functional level of Windows 2000 native, you must locate the domain
naming master on a server that hosts the global catalog. If the forest is set to a
functional level of Windows Server 2003, it is not necessary for the domain
naming master to be on a global catalog server.

Server performance and availability

Most FSMO roles require that the domain controller that holds the roles be:

Highly available server - FSMO functions require that the FSMO role holder is
highly available at all times. A highly available DC is one that uses computer
hardware that enables it to remain operational even during a hardware failure.
For example, having a RAID1 or RAID5 configuration enables the server to keep
running even if one hard disk fails.

Although most FSMO losses can be dealt with within a matter of hours (or even
days at some cases), some FSMO roles, such as the PDC Emulator role, should
never be offline for more than a few minutes at a time.

What will happen if you keep a FSMO role offline for a long period of time? This
table has the info:

FSMO Role Loss implications

The schema cannot be
extended. However, in the short term
Schema no one will notice a missing Schema
Master unless you plan a schema
upgrade during that time.
Unless you are going to run DCPROMO,
Domain Naming
then you will not miss this FSMO role.
Chances are good that the existing DCs
will have enough unused RIDs to last
RID some time, unless you're building
hundreds of users or computer object
per week.
Will be missed soon. NT 4.0 BDCs will
not be able to replicate, there will be no
time synchronization in the domain, you
PDC Emulator will probably not be able to change or
troubleshoot group policies and
password changes will become a
problem.
Infrastructure Group memberships may be
 incomplete. If you only have one
domain, then there will be no impact.

Not necessarily high capacity server - A high-capacity domain controller is

one that has comparatively higher processing power than other domain
controllers to accommodate the additional work load of holding the operations
master role. It has a faster CPU and possibly additional memory and network
bandwidth. FSMO roles usually do not place stress on the server's hardware.

One exception is the performance of the PDC Emulator, mainly when used in
Windows 2000 Mixed mode along with old NT 4.0 BDCs. That is why you should:

• Increase the size of the DC's processing power.

• Do not make the DC a global catalog server.
• Reduce the priority and the weight of the service (SRV) record in DNS to
give preference for authentication to other domain controllers in the site.
• Do not require that the standby domain controller be a direct replication
partner (Seizing the PDC emulator role does not result in lost data, so
there is no need to reduce replication latency for a seize operation).
• Centrally locate this DC near the majority of the domain users.

How To Find Servers That Hold Flexible Single Master

Operations Roles
This article describe how to find the servers that hold the Flexible Single Master
Operation (FSMO) roles in a forest. Active Directory defines five FSMO roles:
• Schema master
• Domain naming master
• RID master
• PDC master
• Infrastructure master
The schema master and the domain naming master are per-forest roles. Therefore,
there is only one schema master and one domain naming master per forest.

The RID master, the PDC master, and the infrastructure master are per-domain roles.
Each domain has its own RID master, PDC master, and infrastructure master.
Therefore, if a forest has three domains, there are three RID masters, three PDC
masters, and three infrastructures masters.

How to Determine the RID, PDC, and Infrastructure FSMO Holders of a

Selected Domain
1. Click Start, click Run, type dsa.msc, and then click OK.
2. Right-click the selected Domain Object in the top left pane, and then click
Operations Masters.
3. Click the PDC tab to view the server holding the PDC master role.
4. Click the Infrastructure tab to view the server holding the Infrastructure
master role.
5. Click the RID Pool tab to view the server holding the RID master role.

How to Determine the Schema FSMO Holder in a Forest

1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click
Active Directory Schema, click Close, and then click OK.
3. Right-click Active Directory Schema in the top left pane, and then click
Operations Masters to view the server holding the schema master role.

NOTE: For the Active Directory Schema snap-in to be available, you may have to
register the Schmmgmt.dll file. To do this, click Start, click Run, type regsvr32
schmmgmt.dll in the Open box, and then click OK. A message is displayed that
states the registration was successful.

How to Determine the Domain Naming FSMO Holder in a Forest

1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active
Directory Domains and Trusts, click Close, and then click OK.
3. In the left pane, click Active Directory Domains and Trusts.
4. Right-click Active Directory Domains and Trust, and then click Operations Master to view
the server holding the domain naming master role in the Forest.

Seizing FSMO Roles

How can I forcibly transfer (seize) some or all of the FSMO
Roles from one DC to another?

The five FSMO roles are:

• Schema master - Forest-wide and one per forest.

• Domain naming master - Forest-wide and one per forest.
• RID master - Domain-specific and one for each domain.
• PDC - PDC Emulator is domain-specific and one for each domain.
• Infrastructure master - Domain-specific and one for each domain

In most cases an administrator can keep the FSMO role holders (all 5 of them) in
the same spot (or actually, on the same DC) as has been configured by the
Active Directory installation process. However, there are scenarios where an
administrator would want to move one or more of the FSMO roles from the
default holder DC to a different DC.
Moving the FSMO roles while both the original FSMO role holder and the future
FSMO role holder are online and operational is called Transferring, and is
described in the Transferring FSMO Roles article.

However, when the original FSMO role holder went offline or became non
operational for a long period of time, the administrator might consider moving
the FSMO role from the original, non-operational holder, to a different DC. The
process of moving the FSMO role from a non-operational role holder to a
different DC is called Seizing, and is described in this article.

If a DC holding a FSMO role fails, the best thing to do is to try and get the server
online again. Since none of the FSMO roles are immediately critical (well, almost
none, the loss of the PDC Emulator FSMO role might become a problem unless
you fix it in a reasonable amount of time), so it is not a problem to them to be
unavailable for hours or even days.

If a DC becomes unreliable, try to get it back on line, and transfer the FSMO
roles to a reliable computer. Administrators should use extreme caution in
seizing FSMO roles. This operation, in most cases, should be performed only if
the original FSMO role owner will not be brought back into the environment.
Only seize a FSMO role if absolutely necessary when the original role holder is
not connected to the network.

What will happen if you do not perform the seize in time? This table has the info:

FSMO Role Loss implications

The schema cannot be
extended. However, in the short term
Schema no one will notice a missing Schema
Master unless you plan a schema
upgrade during that time.
Unless you are going to run DCPROMO,
Domain Naming
then you will not miss this FSMO role.
Chances are good that the existing DCs
will have enough unused RIDs to last
RID some time, unless you're building
hundreds of users or computer object
per week.
Will be missed soon. NT 4.0 BDCs will
not be able to replicate, there will be no
time synchronization in the domain, you
PDC Emulator will probably not be able to change or
troubleshoot group policies and
password changes will become a
problem.
Group memberships may be
Infrastructure incomplete. If you only have one
domain, then there will be no impact.
Important: If the RID, Schema, or Domain Naming FSMOs are seized, then the
original domain controller must not be activated in the forest again. It is
necessary to reinstall Windows if these servers are to be used again.

The following table summarizes the FSMO seizing restrictions:

FSMO Role Restrictions

Schema
Domain Naming Original must be reinstalled
RID
PDC Emulator
Can transfer back to original
Infrastructure

Another consideration before performing the seize operation is the

administrator's group membership, as this table lists:

FSMO Role Administrator must be a member of

Schema Schema Admins
Domain Naming Enterprise Admins
RID
PDC Emulator Domain Admins
Infrastructure

To seize the FSMO roles by using Ntdsutil, follow these steps:

Caution: Using the Ntdsutil utility incorrectly may result in partial or complete
loss of Active Directory functionality.

1. On any domain controller, click Start, click Run, type Ntdsutil in the Open
box, and then click OK.

2. Type roles, and then press ENTER.

Note: To see a list of available commands at any of the prompts in the Ntdsutil
tool, type ?, and then press ENTER.

3. Type connections, and then press ENTER.

 4. Type connect to server <servername>, where <servername> is the
name of the server you want to use, and then press ENTER.

5. At the server connections: prompt, type q, and then press ENTER again.

6. Type seize <role>, where <role> is the role you want to seize. For
example, to seize the RID Master role, you would type seize rid master:

Options are:

7. You will receive a warning window asking if you want to perform the
seize. Click on Yes.

Note: All five roles need to be in the forest. If the first domain controller is out
of the forest then seize all roles. Determine which roles are to be on which
remaining domain controllers so that all five roles are not on only one server.

8. Repeat steps 6 and 7 until you've seized all the required FSMO roles.
9. After you seize or transfer the roles, type q, and then press ENTER until
you quit the Ntdsutil tool.

Note: Do not put the Infrastructure Master (IM) role on the same domain
controller as the Global Catalog server. If the Infrastructure Master runs on a GC
server it will stop updating object information because it does not contain any
references to objects that it does not hold. This is because a GC server holds a
partial replica of every object in the forest.

Transferring FSMO Roles

How can I transfer some or all of the FSMO Roles from one DC
to another?

Windows 2000/2003 Active Directory domains utilize a Single Operation Master

method called FSMO (Flexible Single Master Operation), as described in
Understanding FSMO Roles in Active Directory.
In most cases an administrator can keep the FSMO role holders (all 5 of them) in
the same spot (or actually, on the same DC) as has been configured by the
Active Directory installation process. However, there are scenarios where an
administrator would want to move one or more of the FSMO roles from the
default holder DC to a different DC.

Moving the FSMO roles while both the original FSMO role holder and the future
FSMO role holder are online and operational is called Transferring, and is
described in this article.

The transfer of an FSMO role is the suggested form of moving a FSMO role
between domain controllers and can be initiated by the administrator or by
demoting a domain controller. However, the transfer process is not initiated
automatically by the operating system, for example a server in a shut-down
state. FSMO roles are not automatically relocated during the shutdown process -
this must be considered when shutting down a domain controller that has an
FSMO role for maintenance, for example.

In a graceful transfer of an FSMO role between two domain controllers, a

synchronization of the data that is maintained by the FSMO role owner to the
server receiving the FSMO role is performed prior to transferring the role to
ensure that any changes have been recorded before the role change.

However, when the original FSMO role holder went offline or became non
operational for a long period of time, the administrator might consider moving
the FSMO role from the original, non-operational holder, to a different DC. The
process of moving the FSMO role from a non-operational role holder to a
different DC is called Seizing, and is described in the Seizing FSMO Roles article.

You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by
using an MMC snap-in tool. Depending on the FSMO role that you want to
transfer, you can use one of the following three MMC snap-in tools:

• Active Directory Schema snap-in

• Active Directory Domains and Trusts snap-in
• Active Directory Users and Computers snap-in

To transfer the FSMO role the administrator must be a member of the following
group:

FSMO Role Administrator must be a member of

Schema Schema Admins
Domain Naming Enterprise Admins
RID
PDC Emulator Domain Admins
Infrastructure

Transferring the RID Master, PDC Emulator, and Infrastructure Masters via GUI
To Transfer the Domain-Specific RID Master, PDC Emulator, and Infrastructure
Master FSMO Roles:

1. Open the Active Directory Users and Computers snap-in from the
Administrative Tools folder.
2. If you are NOT logged onto the target domain controller, in the snap-in,
right-click the icon next to Active Directory Users and Computers and
press Connect to Domain Controller.
3. Select the domain controller that will be the new role holder, the target,
and press OK.
4. Right-click the Active Directory Users and Computers icon again and
press Operation Masters.
5. Select the appropriate tab for the role you wish to transfer and press the
Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.

Transferring the Domain Naming Master via GUI

To Transfer the Domain Naming Master Role:

1. Open the Active Directory Domains and Trusts snap-in from the
Administrative Tools folder.
2. If you are NOT logged onto the target domain controller, in the snap-in,
right-click the icon next to Active Directory Domains and Trusts and press
Connect to Domain Controller.
3. Select the domain controller that will be the new role holder and press
OK.
4. Right-click the Active Directory Domains and Trusts icon again and press
Operation Masters.
5. Press the Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.

Transferring the Schema Master via GUI

To Transfer the Schema Master Role:

1. Register the Schmmgmt.dll library by pressing Start > RUN and typing:

2. Press OK. You should receive a success confirmation.

3. From the Run command open an MMC Console by typing MMC.
4. On the Console menu, press Add/Remove Snap-in.
5. Press Add. Select Active Directory Schema.
6. Press Add and press Close. Press OK.
7. If you are NOT logged onto the target domain controller, in the snap-in,
right-click the Active Directory Schema icon in the Console Root and
press Change Domain Controller.
8. Press Specify .... and type the name of the new role holder. Press OK.
 9. Right-click right-click the Active Directory Schema icon again and press
Operation Masters.
10. Press the Change button.
11. Press OK all the way out.

Transferring the FSMO Roles via Ntdsutil

To transfer the FSMO roles from the Ntdsutil command:

Caution: Using the Ntdsutil utility incorrectly may result in partial or complete
loss of Active Directory functionality.

1. On any domain controller, click Start, click Run, type Ntdsutil in the Open
box, and then click OK.

2. Type roles, and then press ENTER.

Note: To see a list of available commands at any of the prompts in the Ntdsutil
tool, type ?, and then press ENTER.

3. Type connections, and then press ENTER.

4. Type connect to server <servername>, where <servername> is the

name of the server you want to use, and then press ENTER.

5. At the server connections: prompt, type q, and then press ENTER again.

6. Type transfer <role>. where <role> is the role you want to transfer.

For example, to transfer the RID Master role, you would type transfer rid
master:

Options are:

7. You will receive a warning window asking if you want to perform the
transfer. Click on Yes.
8. After you transfer the roles, type q and press ENTER until you quit
Ntdsutil.exe.
9. Restart the server and make sure you update your backup.