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.
Video Flexible single master operation
Description of FSMO Roles
Per-domain roles
These roles are applicable at the domain level (i.e., there is one of each for every domain in a forest):
- 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. 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. 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.
- 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. This applies to the domain partition (default naming context) only. netdom query fsmo and ntdsutil will only query the domain partition. However, every application partition, including Forest and Domain-level DNS domain zones has its own Infrastructure Master. The holder of this role is stored in the fSMORoleOwner attribute of the Infrastructure object in the root of the partition, it can be modified with ADSIEdit, for example one can modify the fSMORoleOwner attribute of the CN=Infrastructure,DC=DomainDnsZones,DC=yourdomain,DC=tld object to CN=NTDSSettings,CN=Name_of_DC,CN=Servers,CN=DRSite,CN=Sites,CN=Configuration,DC=Yourdomain,DC=TLD.
Per-forest roles
These roles are unique at the forest level (both are located in the forest root domain):
- The Schema Master - 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, Skype for Business Server, or when you upgrade domain controllers from one version to another version, as all of these situations 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.
Maps Flexible single master operation
Choosing FSMO Placement
Specific tasks should only be completed by a singular entity. For example, when preparing a feast, you do not want several people doing the same task such as preparing the soup as they may apply more ingredients than the normal recipe intended and thus the soup could be ruined. Instead, you would want to split the tasks to prepare the feast and have the other person placed in charge of cleaning the house for the feast. Active Directory Domain Services should function the same way to provide for more resiliency, throughput, separation of duties, stability, redundancy, and workload balance. Specific functions of FSMO roles are recommended to be done by different domain controllers to provide more stability within the Domain so that not just one DC is doing all the legwork and some functions don't play nicely together.
When determining where to place the FSMO roles, it is important to understand the functional level of the domain and forest. In a single domain forest, the Infrastructure Master is not a very critical role since its services are not used at all since there are no remote domains to compare to. In a multiple domain forest, it is very important on where you place the five FSMO roles. Take heavy consideration on which site you will place these domain controllers in as they will run the critical FMSO roles within the forest and its domains:
Forest-wide Roles
- Schema Master - Role is not used very often. Typically, the only time the Schema Master needs to be online after the initial installation of AD DS is when you are making changes to the schema or when the functional level of the forest is raised. You should place the Schema Master in a site where the schema administrators have easy access to it.
- Domain Naming Master - Is not used very often. Its role is to guarantee the uniqueness of domain names within the forest. It is also used when removing domains from the forest. For the Domain Naming Master to perform its function, it must be able to check in with a global catalog server. The global catalog server holds information from every domain within the forest, and when a new domain is added to the forest or a domain is decommissioned, the Domain Naming Master is responsible for identifying the domain information, making sure it is unique, and then updating the configuration information. This role can be located on the same domain controller as the Schema Master.
Domain-wide Roles
- Infrastructure Master - Holds a very important role within a multiple-domain forest. If users from one domain are added to the membership of groups from a second domain, the Infrastructure Master is then responsible for maintaining any updates when changes occur within the remote domain. When you are determining the placement of the Infrastructure Master, place it within a site that also contains domain controllers from most, if not all, of the other domains in the forest. This ensures that the queries and updates are performed on the local network infrastructure.
- RID Master - Is responsible for generating and maintaining the RIDs used by the security principals within the domain. Each domain controller will contact the RID Master to obtain a group of RIDs to be used as the accounts are created. If your domain is in native mode or higher, you should place the RID Master in a site that has domain controllers where administrators are creating a majority of the accounts. This allows the RID Master to efficiently hand out allocations of RIDs to the domain controllers performing most of the account-creation work. If your domain is in mixed mode, consider placing the RID Master on the same server as the PDC emulator. The PDC emulator is the only domain controller that can create accounts within the domain when the domain is in mixed mode.
- PDC Emulator - The RID Master is a highly utilized FSMO role, but the PDC Emulator is the busiest role of all. The domain controller hosting this FSMO role should be highly available and definitely have a standby server available. When a PDC Emulator goes down, you want to make sure you can seize the role quickly so that you do not lose the functionality it provides. If you are making several changes to group policies, position the role close to the administrators responsible for making the updates to GPOs. This keeps the updates local for the administrators. However, if you have a majority of your domain controllers at a site other than where the administrators are located, you have to decide whether the replication cost of GPO updates outweighs local administration.
Moving FSMO Roles Between Domain Controllers
By default AD assigns all operations master roles to the first DC created in a forest. To provide fault tolerance, there should be at least 2 domain controllers available within each domain of the 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 if an active directory has a large number of domain controllers. Microsoft recommends the careful division of FSMO roles, with standby DCs ready to take over each role.
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.
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.
FSMO Roles and Global Catalog
Certain FSMO roles depend on the DC being a Global Catalog (GC) server as well. 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.
Often all domain controllers are also global catalog servers. If this is not the case, 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, as the combination of these two roles on the same host will cause unexpected (and potentially damaging) behaviour in a multi-domain environment. However, The Domain Naming Master role should be housed on a DC which is also a GC.
References
External links
- "6.1.5.3 RID Master FSMO Role". [MS-ADTS]: Active Directory Technical Specification. Microsoft.
- "How to view and transfer FSMO roles in Windows Server 2003". Support. Microsoft. 11 September 2011.
- Tulloch, Mitch (15 March 2005). "How to view and transfer FSMO roles in Windows Server 2003". WindowsNetworking.com. TechGenix.
- "Transferring FSMO Roles in Windows Server 2008". TechNetWiki. Microsoft.
- Arik, Ertugrul (23 December 2014). "How to determine the fsmo role holder (fsmoRoleOwner attribute)". Active Directory Coding.
Source of the article : Wikipedia
0 Comments