Understanding the 5 FSMO Roles in Active Directory

FSMO roles are a crucial piece in Active Directory functionality. Learn about their purpose, types, and how they work together in this guide.

Windows Server Active Directory multi-master model

A multi-master enabled database, such as Active Directory, provides the flexibility of allowing changes to occur at any domain controller (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 Active Directory 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, Active Directory incorporates methods to prevent conflicting updates from occurring using a single-master model.

Windows Server Active Directory single-master model

To prevent conflicts, 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 Flexible Single Master Operation (FSMO) roles that are assigned to one or more domain controllers.

What are the 5 FSMO roles in Active Directory?

FSMO roles, or Flexible Single Master Operation (roles), are special roles assigned to specific Active Directory domain controllers in a forest/domain. Each role can only be assigned to one DC. Two of these roles are assigned to a single DC in an entire forest.

The specified/assigned domain controller with a role is the only DC permitted to perform a specific function in the domain or forest.

The FSMO roles were assigned to one or more DCs during the DCPROMO process. The following table summarizes the FSMO default locations:

FSMO Role	# DCs holding this role	Original DC holding the role
Schema	One per forest	The first DC in the first domain in the forest (i.e. the Forest Root Domain)
Domain Naming	One per forest
RID	One per domain	The first DC in a domain (any domain, including the Forest Root Domain, any Tree Root Domain, or any Child Domain)
PDC Emulator	One per domain
Infrastructure	One per domain

Let me explain the 5 FSMO roles and what function they play.

1. Schema master

The Schema Master role is a forest-level role. Only one domain controller in an entire forest will hold this role. This DC manages updates to the Active Directory schema – this defines what attributes like employee ID, email address, are part of all your accounts.

Whenever you perform updates to the schema (before installing Exchange Server, or adding your first Windows Server 2022 domain controller), you will need access to this domain controller (in addition to an account with Schema Admins permissions…) 

Whenever the schema is modified at all, those updates are always completed by the domain controller with the schema master role.  Schema is updated during the normal replication, and the schema updates are replicated throughout all the domains in the forest.  Since the schema master role is only needed once in the forest, it is kept in the forest root domain.  It’s advisable to place the schema master role on the same domain controller (DC) as the primary domain controller (PDC) emulator.

2. Domain naming master

This is the other forest-level role. Only one domain controller in your forest will house this role. This role ensures that you don’t make a mistake by trying to create a second domain in the same forest with an existing domain name. That would be bad. Think of this server as the master of your domain names.

As domains join or leave the forest, the domain naming master makes the updates into active directory.  Only this DC actually commits those changes into the directory.  The domain naming master also commits the changes to application partitions.  Like the schema master role, this role is a forest level FSMO, and it is only needed once across all domains in a forest.  Also like the schema master, it is suggested to let this role be handled by the same domain controller – the PDC emulator in the forest root.

3. Infrastructure master

This is a domain-level role – you will have one DC with this infrastructure master role in every AD domain in your forest. This role is responsible for updating references from objects in its (source) domain to objects in other domains (destination).

The infrastructure master is a translator, between globally unique identifiers (GUIDs), security identifiers (SIDs), and distinguished names (DNs) for foreign domain objects.  If you’ve ever looked at group memberships of a domain local group which has members from other domains, you can sometimes see those users and groups from the other domain listed only by their SID.  The infrastructure master of the domain of which those accounts are in is responsible for translating those from a SID into their name.

Each domain has their own infrastructure master, including the forest root and every child domain.  Usually, you do not put the infrastructure master role on a domain that holds the global catalog.  However, if you’re in a single domain forest, the infrastructure master has no work to do, since there is no translation of foreign principals.  In that case it’s acceptable to place the infrastructure master it on any domain controller (DC), even if it has the global catalog. For a forest with multiple domains, if there’s even one domain controller that doesn’t have the global catalog on it, then you need to put the infrastructure master role on a domain controller that does not have the global catalog.

4. Relative ID (RID) master

Another domain-level role, this role takes care of processing RID (Relative ID) pool requests from all other domain controllers in a specific domain.

When a domain controller creates a security principal object like a user or group, it attaches a SID (Security IDentifier) to the object. This SID includes a domain SID and a Relative ID (RID). RIDs are allocated from an RID pool that is controlled by the DC with this role.

The RID Master also facilitates moving an object from one domain to another. This role validates that the SID assigned to each AD object is unique.

SID vs RID

One of the first things understood about a security identifier (SID) is that they are unique.  There are two parts of a SID: the domain identifier (domain ID), and the relative ID (RID).  The domain identifier part of the SID is uniform among all security principals in the domain.  When looking at a list of SIDs in a domain, it’s easy to identify the domain SIDs – they all look the same.  On the contrary, the relative ID part of the SID is the unique part.  The two parts together make up what we commonly identify as a SID.

It is conceivable, then, that if two or more domain controllers were responsible for determining the relative IDs for the SIDs that two domain controllers may come up with the same relative ID for two different objects before they’ve replicated with each other.

That is impossible when only one DC in a domain is responsible for the creation of the relative IDs for SIDs. The relative ID master, or RID master, hands out batches of relative IDs to individual domain controllers, then each domain controller can use their allotment to create new users, groups, and computers.  When domain controllers need more relative IDs in reserve, they request them from, and are assigned by, the domain controller with the RID master FSMO role.

Every domain in a forest must have a domain controller with the RID master FSMO role assigned to it.  It is recommended that the RID master FSMO role be assigned to whichever domain controller has the PDC emulator FSMO role.

5. Primary Domain Controller (PDC) Emulator

This is probably the most important role as it has the widest array of functions. Whether you are using physical hardware or virtualization for your domain controllers, you’ll want to make sure this domain controller is highly available, 24×7.

This role is the third domain-level role – one domain controller in each domain houses this role. Let me explain in detail the most important functions this role includes.

1. Account Lockout – Account lockouts are processed on the PDC emulator role. These get replicated to all other DCs in the domain.
2. Password Changes – When a password change occurs on another domain controller in a domain, the changes are replicated first to the DC with this role. Users will not be able to change their AD password unless the PDC emulator role DC is online and available.
3. Authentication Requests – If a user attempts to log in and the request fails, the authenticating DC will forward the request to the PDC emulator role DC to verify the most current password for that account.
4. Time Synchronization – The PDC emulator role DC, by default, servers as the end all, be all time source for all computers in the domain. It ensures that all computer clocks are synchronized. This is crucial for Kerberos authentication – if a computer clock is off by 5 minutes or more, authentication requests will likely fail.
5. Group Policy Objects (GPOs) – The PDC emulator domain controller manages all Group Policy Objects. 

What is the best practice for splitting FSMO roles?

There are several schools of thought on this topic. Some IT Pros swear by putting all five roles on one domain controller and ensuring that DC is always on, however they can. You probably noticed I had all of them in my lab on my first DC. But, that’s just a lab.

Let me go through some strategies employed in this space.

• Split FSMO Roles – This one is rather simplistic. Assign the roles to various domain controllers in your Active Directory domain/forest. Only include one role per domain controller. This balances the load across your environment.
• Forest-wide roles – For the two roles per forest, most administrators (and Microsoft) recommend placing both roles on one DC, your first forest root-level domain controller.
• Domain-wide Roles – For the three remaining roles, these can be placed on the same DC. This is straightforward and should handle all but the largest and complex AD forests.
• All-In-One – This places all five roles on a single DC. There are pros and cons of course. If this DC becomes unavailable, you may be in a pickle.

Let’s look at this in more detail.

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.

Windows Server 2008 Active Directory introduced the ability to designate ahead of time standby operations masters by allowing you to set designated standby operations masters as direct replication partners of the actual operations masters.

FSMO 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
Schema	The schema cannot be extended. However, in the short term no one will notice a missing Schema Master unless you plan a schema upgrade during that time.
Domain Naming	Unless you are going to run DCPROMO, then you will not miss this FSMO role.
RID	Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you’re building hundreds of users or computer object per week.
PDC Emulator	Will be missed soon. NT 4.0 BDCs will not be able to replicate, there will be no time synchronization in the domain, you 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.

Can I move FSMO roles between domain controllers?

So what about redundancy and fault tolerance? What if one of the domain controllers with one or more of these roles becomes unresponsive? You can make changes and recover your environment. Essentially, we have a proactive approach and a reactive approach – transferring a role ahead of an issue and seizing a role if a DC is down. You can check FSMO roles, and which DCs hold each role, using the GUI and command line.