What is FSMO ?Flexible Single Master Operations

Flexible Single Master Operations (FSMO, F is sometimes floating ; pronounced Fiz-mo), or just single master operation or operations master, is a feature of Microsoft‘s Active Directory (AD). As of 2005, the term FSMO has been deprecated in favour of operations masters.

FSMO is a specialized domain controller (DC) set of tasks, used where standard data transfer and update methods are inadequate. AD normally relies on multiple peer DCs, each with a copy of the AD database, being synchronized by multi-master replication. The tasks which are not suited to multi-master replication, and are viable only with a single-master database, are the FSMOs.

 

The following list describes the 5 unique FSMO roles in an Active Directory forest and the dependent operations that they perform:

  • Schema master – The Schema master role is forest-wide and there is one for each forest. This role is required to extend the schema of an Active Directory forest or to run the adprep /domainprep command.
  • Domain naming master – The Domain naming master role is forest-wide and there is one for each forest. This role is required to add or remove domains or application partitions to or from a forest.
  • RID master – The RID master role is domain-wide and there is one for each domain. This role is required to allocate the RID pool so that new or existing domain controllers can create user accounts, computer accounts or security groups.
  • PDC emulator – The PDC emulator role is domain-wide and there is one for each domain. This role is required for the domain controller that sends database updates to Windows NT backup domain controllers. The domain controller that owns this role is also targeted by certain administration tools and updates to user account and computer account passwords.
  • Infrastructure master – The Infrastructure master role is domain-wide and there is one for each domain. This role is required for domain controllers to run the adprep /forestprep command successfully and to update SID attributes and distinguished name attributes for objects that are referenced across domains.

The Active Directory Installation Wizard (Dcpromo.exe) assigns all 5 FSMO roles to the first domain controller in the forest root domain. The first domain controller in each new child or tree domain is assigned the three domain-wide roles. Domain controllers continue to own FSMO roles until they are reassigned by using one of the following methods:

  • An administrator reassigns the role by using a GUI administrative tool.
  • An administrator reassigns the role by using the ntdsutil /roles command.
  • An administrator gracefully demotes a role-holding domain controller by using the Active Directory Installation Wizard. This wizard reassigns any locally-held roles to an existing domain controller in the forest. Demotions that are performed by using the dcpromo /forceremoval command leave FSMO roles in an invalid state until they are reassigned by an administrator.

We recommend that you transfer FSMO roles in the following scenarios:

  • The current role holder is operational and can be accessed on the network by the new FSMO owner.
  • You are gracefully demoting a domain controller that currently owns FSMO roles that you want to assign to a specific domain controller in your Active Directory forest.
  • The domain controller that currently owns FSMO roles is being taken offline for scheduled maintenance and you need specific FSMO roles to be assigned to a “live” domain controller. This may be required to perform operations that connect to the FSMO owner. This would be especially true for the PDC Emulator role but less true for the RID master role, the Domain naming master role and the Schema master roles.

We recommend that you seize FSMO roles in the following scenarios:

  • The current role holder is experiencing an operational error that prevents an FSMO-dependent operation from completing successfully and that role cannot be transferred.
  • A domain controller that owns an FSMO role is force-demoted by using the dcpromo /forceremoval command.
  • The operating system on the computer that originally owned a specific role no longer exists or has been reinstalled.

As replication occurs, non-FSMO domain controllers in the domain or forest gain full knowledge of changes that are made by FSMO-holding domain controllers. If you must transfer a role, the best candidate domain controller is one that is in the appropriate domain that last inbound-replicated, or recently inbound-replicated a writable copy of the “FSMO partition” from the existing role holder. For example, the Schema master role-holder has a distinguished name path of CN=schema,CN=configuration,dc=<forest root domain>, and this mean that roles reside in and are replicated as part of the CN=schema partition. If the domain controller that holds the Schema master role experiences a hardware or software failure, a good candidate role-holder would be a domain controller in the root domain and in the same Active Directory site as the current owner. Domain controllers in the same Active Directory site perform inbound replication every 5 minutes or 15 seconds.

The partition for each FSMO role is in the following list:

FSMO role Partition
Schema CN=Schema,CN=configuration,DC=<forest root domain>
Domain Naming Master CN=configuration,DC=<forest root domain>
PDC DC=<domain>
RID DC=<domain>
Infrastructure DC=<domain>

A domain controller whose FSMO roles have been seized should not be permitted to communicate with existing domain controllers in the forest. In this scenario, you should either format the hard disk and reinstall the operating system on such domain controllers or forcibly demote such domain controllers on a private network and then remove their metadata on a surviving domain controller in the forest by using the ntdsutil /metadata cleanup command. The risk of introducing a former FSMO role holder whose role has been seized into the forest is that the original role holder may continue to operate as before until it inbound-replicates knowledge of the role seizure. Known risks of two domain controllers owning the same FSMO roles include creating security principals that have overlapping RID pools, and other problems.

 

 

 

 

In Active Directory Domain Services (AD DS), domain controllers can run different versions of Windows Server operating systems. The functional level of a domain or forest depends on which versions of Windows Server operating systems are running on the domain controllers in the domain or forest

 

One per Microsoft Windows Server Domain

These roles are applicable at the domain level

  • The PDC Emulator (Primary Domain Controller) – This role is the most used of all FSMO roles and has the widest range of functions The domain controller that holds the PDC Emulator role is crucial in a mixed environment where Windows NT 4.0 BDCs are still present. This is because the PDC Emulator role emulates the functions of a Windows NT 4.0 PDC. But even if all Windows NT 4.0 domain controllers have been migrated to Windows 2000 or later, the domain controller that holds the PDC Emulator role still does a lot. The PDC Emulator is the domain source for time synchronization for all other domain controllers; in a multi-domain forest, the PDC Emulator in each domain synchronizes to the forest root PDC Emulator. All other domain member computers synchronize to their respective domain controllers.[3] It is critically important that computer clocks are synchronized across the forest because excessive clock skew causes Kerberos authentication to fail. In addition, all password changes occur on the PDC Emulator and receive priority replication.[4]
  • The RID Master – (Relative ID) This FSMO role owner is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for moving an object from one domain to another during an interdomain object move. When a DC creates a security principal object such as a user or group, it attaches a unique 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 FSMO role owner, the RID Master FSMO role owner responds to the request by retrieving RIDs from the domain’s unallocated RID pool and assigns them to the pool of the requesting DC.
  • The Infrastructure Master – The purpose of this role is to ensure that cross-domain object references are correctly handled. For example, if you add a user from one domain to a security group from a different domain, the Infrastructure Master makes sure this is done properly. However, if the Active Directory deployment has only a single domain, then the Infrastructure Master role does no work at all, and even in a multi-domain environment it is rarely used except when complex user administration tasks are performed.

One per Microsoft Windows Forest of Domains

These roles are unique at enterprise level

  • The Schema Master – While the first three FSMO roles described above are domain-specific, the Schema Master role and the one following are forest-specific and are found only in the forest root domain (The first domain you create when you create a new forest). This means there is only one Schema Master in a forest, and the purpose of this role is to replicate schema changes to all other domain controllers in the forest. Since the schema of Active Directory is rarely changed however, the Schema Master role will rarely do any work. Typical scenarios where this role is used would be when you deploy Exchange Server onto your network, or when you upgrade domain controllers from Windows 2000 to Windows Server 2003, as these situations both involve making changes to the Active Directory schema.
  • The Domain Naming Master – The other forest-specific FSMO role is the Domain Naming Master, and this role also resides in the forest root domain. The Domain Naming Master role processes all changes to the namespace, for example adding the child domain vancouver.mycompany.com to the forest root domain mycompany.com requires that this role be available, so if you can’t add a new child domain or new domain tree, check to make sure this role is running properly.

To summarize then, the Schema Master and Domain Naming Master roles are found only in the forest root domain, while the remaining roles are found in each domain of your forest.

 

Microsoft definition

Single-Master Model

To prevent conflicting updates in Windows, 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 3.51 and 4.0), in which the PDC is responsible for processing all updates in a given domain.

Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any domain controller (DC) in the enterprise. Because an Active Directory role is not bound to a single DC, it is referred to as a Flexible Single Master Operation (FSMO) role. Currently in Windows there are five FSMO roles:

  • Schema master
  • Domain naming master
  • RID master
  • PDC emulator
  • Infrastructure master

Schema Master FSMO Role

The schema master FSMO role holder is the DC responsible for performing updates to the directory schema (that is, the schema naming context or LDAP://cn=schema,cn=configuration,dc=<domain>). This DC is the only one that can process updates to the directory schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. There is only one schema master per directory.

Domain Naming Master FSMO Role

The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory (that is, the Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC=<domain>). 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.

RID Master FSMO Role

The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.

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 Windows 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. There is one RID master per domain in a directory.

PDC Emulator FSMO Role

The PDC emulator is necessary to synchronize time in an enterprise. Windows includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows-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 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.
  • 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. The PDC emulator still performs the other functions as described in a Windows 2000 environment.

The following information describes the changes that occur during the upgrade process:

  • Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package do not perform directory writes (such as password changes) preferentially at the DC that has advertised itself as the PDC; they use any DC for the domain.
  • Once backup domain controllers (BDCs) in down-level domains are upgraded to Windows 2000, the PDC emulator receives no down-level replica requests.
  • Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package use the Active Directory to locate network resources. They do not require the Windows NT Browser service.

Infrastructure FSMO Role

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.

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.

When the Recycle Bin optional feature is enabled, every DC is responsible to update its cross-domain object references when the referenced object is moved, renamed, or deleted. In this case, there are no tasks associated with the Infrastructure FSMO role, and it is not important which domain controller owns the Infrastructure Master role. For more information, see 6.1.5.5 Infrastructure FSMO Role at http://msdn.microsoft.com/en-us/library/cc223753.aspx

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s