Introduction

FSMO (Flexible Single Master Operations) roles are specialized roles in an Active Directory domain that are responsible for specific tasks related to the management and maintenance of the directory. These roles are crucial for the proper functioning of an Active Directory environment. By default, the first domain controller installed in a forest hosts all five roles. However, you can transfer these roles after deploying additional domain controllers. When performing operations master-specific changes, you must connect to the domain controller with the role. The five operations master roles have the following distribution:

  • Each forest has one schema master and one domain naming master.
  • Each AD DS domain has one relative ID (RID) master, one infrastructure master, and one primary domain controller (PDC) emulator.

Forest operations masters

Schema Master

This is the domain controller in which you make all schema changes.

If the schema master is unavailable, you will not be able to make changes to the schema.

Domain Naming Master

This is the domain controller that you must contact when you add or remove a domain or make domain name changes.

If the domain naming master is unavailable, you will not be able to add domains to the forest.

The Windows PowerShell command Get-ADForest from the Active Directory module for Windows PowerShell, displays the forest properties, including the current domain naming master and schema master.

Domain operations masters

RID Master (Domain operations masters)

Whenever you create a security principal such as a user, computer, or group in AD DS, the domain controller where you created the object assigns the object a unique identifying number known as a security ID (SID). To ensure that no two domain controllers assign the same SID to two different objects, the RID master allocates blocks of RIDs to each domain controller within the domain to use when building SIDs.

If the RID master is unavailable, you might experience difficulties adding security principals to the domain. Also, as domain controllers use their existing RIDs, they eventually run out of them and are unable to create new objects. The infrastructure master role should not reside on the domain controller that’s hosting the global catalog role unless every domain controller in the forest is configured to serve as a global catalog. In this case, the infrastructure master role is not necessary because every domain controller knows about every object in the forest.

Infrastructure Master.

This role maintains interdomain object references, such as when a group in one domain has a member from another domain. In this situation, the infrastructure master manages maintaining the integrity of this reference. For example, when you review an object’s Security tab, the system references the listed SIDs and translates them into names. In a multiple-domain forest, the infrastructure master updates references to SIDs from other domains with the corresponding security principal names.

If the infrastructure master is unavailable, domain controllers that are not global catalogs will not be able to perform translation of SIDs security principal names.

PDC Emulator

The domain controller that is the PDC emulator master serves as the time source for the domain. The PDC emulator master in each domain in a forest synchronizes their time with the PDC emulator master in the forest root domain. You set the PDC emulator master in the forest root domain to synchronize with a reliable external time source. Additionally, by default, changes to Group Policy Objects (GPOs) are by default written to the PDC Emulator master. The PDC emulator master is also the domain controller that receives urgent password changes. If a user’s password changes, the domain controller with the PDC emulator master role receives this information immediately. This means that if the user tries to sign in, the domain controller in the user’s current location will contact the domain controller with the PDC emulator master role to check for recent changes. This will occur even if a domain controller in a different location that had not yet received the new password information authenticated the user.

If the PDC emulator master is unavailable, users might have trouble signing in until their password changes have replicated to all the domain controllers.

The Windows PowerShell command Get-ADDomain, from the Active Directory module for Windows PowerShell, displays the domain properties, including the current RID master, infrastructure master, and PDC emulator master.

You can place all five on a single domain controller, or distribute them across several domain controllers.

Different of Transferring and seizing FSMO

Transferring and seizing FSMO roles are two different processes that involve moving the responsibility of a specific FSMO role from one domain controller to another. Here’s a breakdown of each process:

Transferring FSMO Roles:

Transferring FSMO roles is the preferred method of moving a role from one domain controller to another. This process is typically performed when you want to retire a domain controller gracefully or need to move a role to a more reliable or better-performing server. This requires the old server to be online and healthy.

Seizing FSMO Roles:

Seizing FSMO roles is a process used when the current role holder is not available due to hardware failure, network issues, or other reasons. Seizing a role should be considered a last resort and should only be performed if the current role holder cannot be brought back online.

Both transferring and seizing FSMO roles require administrative access and careful consideration to ensure the integrity of the Active Directory environment. Before performing any role transfers or seizures, it’s recommended to have a thorough understanding of the process and its implications.

How to transfer FSMO roles

  • Get FSMO
Get-ADDomain | select InfrastructureMaster, PDCEmulator, RIDMaster
Get-ADForest | select DomainNamingMaster, SchemaMaster

Transfer FSMO

# Transfer PDCEmulator 
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" PDCEmulator
# Transfer RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" RIDMaster
# Transfer InfrastrctureMaster
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" Infrastructuremaster
#  Transfer DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" DomainNamingmaster
# Transfer SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" SchemaMaster

Seize FSMO

The different between transfering and seizeing the FSMO role is by adding -force argument at the end of command. You can use the same command to perform one-by-one process,

Move-ADDirectoryServerOperationMasterRole -Identity "DC01" PDCEmulator -Force
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" RIDMaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" Infrastructuremaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" DomainNamingmaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" SchemaMaster -Force

or moving all together:

Move-ADDirectoryServerOperationMasterRole -Identity AD01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

Manage AD DS schema

AD DS stores and retrieves information from a wide variety of applications and services. It does this, in part, by standardizing how the AD DS directory stores data. By standardizing data storage, AD DS can retrieve, update, and replicate data while helping to maintain data integrity.

An AD DS schema is the component that defines all the object classes and attributes that AD DS uses to store data. All domains in a forest contain a copy of the schema that applies to that forest. Any change in the schema replicates to every domain controller in the forest via their replication partners. However, changes originate at the schema master.

Objects

AD DS uses objects as units of storage. The schema defines all object types. Each time the directory manages data, the directory queries the schema for an appropriate object definition. Based on the object definition in the schema, the directory creates the object and stores the data.

Object definitions specify both the types of data that the objects can store and the data syntax. You can only create objects that the schema defines. Because objects store data in a rigidly defined format, AD DS can store, retrieve, and validate the data that it manages, regardless of which application supplies it.

Relationships among objects, rules, attributes, and classes

AD DS schema objects consist of attributes, which are grouped together into classes. Each class has rules that define which attributes are mandatory and which are optional. For example, the user class consists of more than 400 possible attributes, including cn (the common name attribute), givenName, displayName, objectSID, and manager. Of these attributes, the cn and objectSID attributes are mandatory.

The user class is an example of a structural class. A structural class is the only type of class that can have objects in an AD DS database. To modify the schema, you can create an auxiliary class with its own attributes, and then reference it in the definition of a structural class.

Image alt

Manage AD DS schema

When managing the AD DS schema, you can modify the schema only if you are a member of the Schema Admins group in the root domain of the AD DS forest. For this purpose, you can use the Active Directory Schema snap-in.

AD DS schema does not support deletions.

You should change the schema only when necessary because the schema controls the storage of information. Additionally, any changes made to the schema affect every domain controller. Before you change the schema, you should review the changes and implement them only after you’ve performed testing. This will help ensure that the changes Won’t adversely affect the rest of the forest or any applications that use AD DS.

Image alt