What are FSMO roles?

The IT industry is notorious for its use of acronyms. If we can shorten complex terminology or a lengthy product name into an acronym, we will. Even the term "IT" is just an acronym for information technology. While there are some great acronyms out there, including PDQ, I want to go over one of my all-time favorites: FSMO (pronounced fiz-mo). What is FSMO, and how does it impact your domain environment? Let's find out.

What is FSMO?

FSMO (which just rolls off the tongue) stands for Flexible Single Master Operation. It is a set of operations or roles in AD (Active Directory) designed to help avoid replication conflicts. To better understand why AD utilizes FSMO roles, commonly referred to as operation masters, we first need to understand AD's replication structure.

Active Directory uses what is known as multi-master replication. Essentially, multi-master replication allows directory changes on any domain controller (DC) on a domain. Multi-master replication is great because having multiple DCs that can all write changes removes the risk of a single point of failure and creates redundancy. However, there are some drawbacks, including the risk of replication conflicts.

To help avoid replication disputes, especially for sensitive operations, some AD objects are updated using the single-master model, meaning specific DCs are assigned to be the primary authority of particular AD objects and structures. These designations are the FSMO role holders or operation masters. Once a FSMO role holder has updated an object, the changes are replicated to the rest of the DCs. 

What are the five FSMO roles?

There are five FSMO roles, and a DC can be given a single role, several roles, or all the roles (more on that later). Roles can be transferred to any DC in a domain or forest, preventing a single point of failure, which is where "Flexible" in FSMO comes from. Additionally, some of these roles are forest-level roles, while others are domain level in scope.

• Schema master (forest)

• Domain naming master (forest)

• RID master (domain)

• PDC emulator (domain)

• Infrastructure master (domain)

A domain has one RID master, one PDC emulator, and one infrastructure master. A forest has one schema master and one domain naming master. If a forest contains multiple domains, each domain has its own RID master, PDC emulator, and infrastructure master. However, the forest always has just one schema master and one domain naming master.

Let's look at each of the five roles and go over what they do.

1. Schema master

The schema master role is responsible for updating changes to the directory schema and functions at the forest level. 

The schema in Active Directory defines every object class and attribute in an AD forest. Think of the schema as the structure of the AD database. Any update which modifies the schema is done via the schema master role.

Changes to the schema are pretty infrequent but commonly occur when raising the forest functional level or integrating applications that require a change to the schema, such as Exchange and SCCM. Once the change is made on the DC with the schema master role, the change is replicated to the remaining domain controllers.

2. Domain naming master

The domain naming master role is responsible for the forest-wide directory name space. Some responsibilities of this role include adding or removing domains, changing domain names, and adding or removing cross-references to domains. Like the schema master, the domain naming master is a forest-level role.

3. RID master

The relative ID (RID) master is responsible for ensuring each object in a domain is assigned a unique ID. No two objects in a domain can have the same security identifier (SID). The RID master accomplishes this by allocating RID sequences to each domain controller in a domain. When a domain controller has used a portion of its allotted RIDs, it requests more from the RID master domain controller. By default, the RID master assigns RIDs to domain controllers in blocks of 500. Once a domain controller issues half of its RID pool to objects, it requests more RIDs from the RID master.

4. PDC emulator

While each of the FSMO roles is important, the primary domain controller (PDC) emulator plays perhaps the most prominent role in day-to-day directory maintenance. Here are some of the PDC emulator's domain responsibilities:

• Password change authority: The PDC emulator is responsible for ensuring passwords are updated and properly synchronized throughout a domain. When a password is changed on a domain controller, the change is replicated preferentially to the PDC emulator, ignoring inter-site replication schedules. The change is then routinely replicated across the domain to the rest of the domain controllers. If a user fails to authenticate to a domain controller, the request is routed to the PDC emulator to check for an updated password that may not have been replicated yet. The PDC emulator then accepts or rejects the request.

• Account lockouts: Since all failed authentication requests are sent to the PDC emulator, it is responsible for account lockouts. Account lockouts do not follow normal replication, instead requiring urgent replication across all domain controllers. This security measure ensures that users who had their accounts locked cannot immediately try to authenticate to a different domain controller that hasn't received the account change through normal replication.

• Time synchronization: Keeping time synced across clients on a network is critically important. Kerberos, the default authentication protocol used by Windows, has a clock synchronization tolerance of five minutes. If a host is out of sync by more than five minutes from the DC it's authenticating with, the authentication request fails. Clients in a forest synchronize their time upstream to the PDC emulator. The PDC emulator in the parent domain should be configured to sync its clock with an authoritative network time protocol (NTP) server.

Needless to say, the DC designated with the PDC emulator role has a lot on its plate. With this in mind, it's vital to ensure this server has plenty of resources and high availability. If the PDC emulator server fails and is offline, this could significantly impact network services. If quickly recovering a failed PDC emulator server is unlikely, it may be worthwhile to seize and transfer the role to another domain controller.

5. Infrastructure master

The infrastructure master, along with the PDC emulator and RID master, is another domain-level role. The infrastructure master is responsible for translating cross-domain object references. The infrastructure master role should be held by a DC that is not configured as a global catalog (GC) server. If all servers on the domain are GCs (global catalogs), then it doesn't matter which server holds the infrastructure master role.

Identifying FMSO role holders with the command line

The command line makes it super easy to find what servers are assigned as the operation masters or FMSO role holders using netdom. Here's the one-liner you'll need:

Identifying FSMO role holders with PowerShell

While PowerShell is almost always more powerful than the command line, it's not always easier. This is the case with identifying FSMO role holders using PowerShell. While the command line gave us a nice, easy one-liner, PowerShell requires the installation of the ActiveDirectory PowerShell module.

To use the ActiveDirectory PowerShell module on a desktop OS, such as Windows 10, you'll need to install the appropriate RSAT tools. Here is the optional RSAT feature you'll want to install: RSAT: Active Directory Domain Services and Lightweight Directory Services Tools.

If you're working on a server that is not a domain controller, you can run this PowerShell command to install the necessary features:

Once you've got the PowerShell module installed, here are the PowerShell commands you can run to retrieve the domain-level and forest-level role holders:

Domain level:

Forest level:

Transferring FSMO roles

Occasionally, you may want or need to transfer a FSMO role to another DC. Transferring FSMO roles should not be a frequent occurrence. However, it may be necessary if you need to demote a DC assigned a FSMO role or if a FSMO role holder has failed and will be offline for a significant amount of time. Ideally, FSMO role transfers should be done while both the source DC and the target DC are online.

The easiest way to transfer FSMO roles that I've found is using PowerShell. Here is the command you'll need:

You'll need to change TargetDC to the target domain controller. Also, this particular command transfers all five FSMO roles. Only include the roles you need to transfer in your command.

Once you run the command, you will receive a prompt to ensure you want to transfer the role or roles.

If the source DC is not online, you can try to seize the role using the above command and adding the -Force switch. The command first tries to transfer the role, and if that fails, it attempts to seize the role.

FSMO best practice

Here are Microsoft’s FSMO placement and optimization recommendations: 

• It's easier to keep track of FSMO roles if you host them on fewer computers.

• Place roles on domain controllers that can be accessed by the computers, which need access to a given role, especially on networks that aren't fully routed. For example, to obtain a current or standby RID pool or perform pass-through authentication, all DCs need network access to the RID and PDC role holders in their respective domains.

• You should transfer (not seize) the role to the new domain controller under the following conditions:

  • a role must be moved to a different domain controller

  • the current role holder is online and available

• FSMO roles should only be seized if the current role holder isn't available. For more information, see Managing Operations Master Roles.

• FSMO roles assigned to domain controllers that are offline or in an error state only have to be transferred or seized if role-dependent operations are being done. If the role holder can be made operational before the role is needed, you may delay seizing the role. If role availability is critical, transfer or seize the role as required. The PDC role in each domain should always be online.

• Select a direct intrasite replication partner for existing role holders to act as a standby role holder. If the primary owner goes offline or fails, transfer or seize the role to the designated standby FSMO domain controller as required.

• Place the schema master on the PDC of the forest root domain.

• Place the domain naming master on the forest root PDC. The addition or removal of domains should be a tightly controlled operation. Place this role on the forest root PDC. Certain operations that use the domain naming master fail if the domain naming master isn't available. These operations include creating or removing domains and application partitions. On a domain controller that runs Microsoft Windows 2000, the domain naming master must also be hosted on a global catalog server. On domain controllers that run Windows Server 2003 or later versions, the domain naming master doesn't have to be a global catalog server.

• Place the PDC on your best hardware in a reliable hub site that contains replica domain controllers in the same Active Directory site and domain. In large or busy environments, the PDC frequently has the highest CPU usage because it handles pass-through authentication and password updates. If high CPU usage becomes a problem, identify the source. The source includes applications or computers that may be performing too many operations (transitively) targeting the PDC. Techniques to reduce CPU include:

  • Adding more or faster CPUs

  • Adding more replicas

  • Adding more memory to cache Active Directory objects

  • Removing the global catalog to avoid global catalog lookups

  • Reducing the number of incoming and outgoing replication partners

  • Increasing the replication schedule

  • Reducing authentication visibility by using LDAPSRVWEIGHT and LDAPPRIORITY, and by using the Randomize1CList feature.

• All domain controllers in a particular domain, and computers that run applications and admin tools that target the PDC, must have network connectivity to the domain PDC.

• Place the RID master on the domain PDC in the same domain. RID master overhead is light, especially in mature domains that have already created the bulk of their users, computers, and groups. The domain PDC typically receives the most attention from administrators. Co-locating this role on the PDC helps ensure reliable availability. Make sure that existing domain controllers and newly promoted domain controllers have network connectivity to obtain active and standby RID pools from the RID master, especially the domain controllers promoted in remote or staging sites.

• Legacy guidance suggests placing the infrastructure master on a non-global catalog server. There are two rules to consider:

  • Single domain forest: In a forest that contains a single Active Directory domain, there are no phantoms. So, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, whether that domain controller hosts the global catalog or not.

  • Multidomain forest: If every domain controller in a domain that's part of a multi-domain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain. Practically, most administrators host the global catalog on every domain controller in the forest.

  • If every domain controller in a given domain that's located in a multi-domain forest doesn't host the global catalog, the infrastructure master must be placed on a domain controller that doesn't host the global catalog.

Working silently in the background to keep your domain in shape

While multi-master replication is great for many domain- and forest-wide operations, some operations are too critical to allow possible replication conflicts. To ensure the accuracy and integrity of your domain operations, the FSMO role holders are busy silently working in the background to keep your domain in order.

If you enjoy utilities that provide loads of functionality while working silently in the background, check out PDQ Deploy and Inventory. With Deploy and Inventory, you can automate all those pesky tasks that keep nagging you, like patch and inventory management. Try them out with a 14-day free trial.