Flexible Single Master Operations, or just single master operation or operations master,
is a feature of Microsoft's Active Directory.
As of 2005, the term FSMO has been deprecated in favour of operations masters.
FSMO is a specialized domain controller 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.
Description of FSMO Roles One per Microsoft Windows Server Domain
These roles are applicable at the domain level The PDC Emulator - 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 you've migrated all your Windows NT 4.0 domain controllers 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.
It's critically important that computer clocks are synchronized across your forest because
if they're off by too much then Kerberos authentication will fail and users won't be able to log on
to the network.
In addition, all password changes occur on the PDC Emulator and receive priority replication.
The RID Master - 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 and a relative ID 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 your 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, so the machine holding
this role doesn't need to be powerful.
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.
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.
Moving FSMO Roles Between Domain Controllers By default AD assigns all operations master
roles to the first DC created in a forest.
If new domains are created in the forest, the first DC in a new domain holds all of
the domain-wide FSMO roles.
This is not a satisfactory position.
Microsoft recommends the careful division of FSMO roles, with standby DCs ready to take
over each role.
When a FSMO role is transferred to a different DC, the original FSMO holder and the new FSMO
holder communicate to ensure no data is lost during the transfer.
If the original FSMO holder experienced an unrecoverable failure, you can force another
DC to seize the lost roles; however, there is a risk of data loss because of the lack
of communications.
If you seize a FSMO role instead of transferring the role, that domain controller can never
be allowed to host that FSMO role again, except for the PDC emulator Master operation and
the Infrastructure Master Operation.
Corruption can occur within Active Directory.
FSMO roles can be easily moved between DCs using the AD snap-ins to the MMC or using
ntdsutil which is a command line based tool.
Certain FSMO roles depend on the DC being a Global Catalog server as well.
For example, the Infrastructure Master role must not be housed on a domain controller
which also houses a copy of the global catalog in a multi-domain forest, while the Domain
Naming Master role should be housed on a DC which is also a GC.
When a Forest is initially created, the first Domain Controller is a Global Catalog server
by default.
The Global Catalog provides several functions.
The GC stores object data information, manages queries of these data objects and their attributes
as well as provides data to allow network logon.
The PDC emulator and the RID master should be on the same DC, if possible.
The Schema Master and Domain Naming Master should also be on the same DC.
To provide fault tolerance, there should be at least 2 domain controllers available within
each domain of the Forest.
Furthermore, the Infrastructure Master role holder should not also be a Global Catalog
Server, as the combination of these two roles on the same host will cause unexpected behaviour
in a multi-domain environment.
References
http:msdn.microsoft.comlibrary/cc223751.aspx http:support.microsoft.com324801
http:www.windowsnetworking.commanaging-active-directory-fsmo-roles.html http:social.technet.microsoft.comcontents832.transferring-fsmo-roles-in-windows-server-2008.aspx