Flexible single master operation

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).^[1] As of 2005, the term FSMO has been deprecated in favor 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.^[2]

Contents 1 Description of FSMO Roles 1.1 One per Microsoft Windows Server Domain 1.2 One per Microsoft Windows Forest of Domains 2 Moving FSMO Roles Between Domain Controllers 3 Active Directory support tools 3.1 List and description of tools 4 Global Catalog 5 References

Description of FSMO Roles

One per Microsoft Windows Server Domain

These roles are applicable at the domain level

• The Relative ID Master allocates security RIDs to DCs to assign to new AD security principals (users, groups or computer objects). It also manages objects moving between domains.
• The Infrastructure Master maintains security identifiers, GUIDs, and DN for objects referenced across domains. Most commonly it updates user and group links.This is another domain-specific role and its purpose 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. As you can guess however, if your Active Directory deployment has only a single domain, then the Infrastructure Master role does not work at all, and even in a multi-domain environment it is rarely used except when complex user administration tasks are performed. Because of this, the hardware requirements for machines holding this role are relatively small.
• The PDC Emulator operations master role processes all password changes in the domain. Failed authentication attempts due to a bad password at other domain controllers are forwarded to the PDC Emulator before rejection. This ensures that a user can immediately login following a password change from any domain controller, without having to wait several minutes for the change to be replicated. The PDC Emulator Operations Master role must be carefully sited in a location to best handle all password reset and failed-authentication forwarding traffic for the domain. The PDC emulator role holder retains the following functions:

1. Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
2. 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.
3. Account lockout is processed on the PDC emulator.
4. Backwards compatibility: 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.

One per Microsoft Windows Forest of Domains

These roles are unique at enterprise level

• The Schema Master maintains all modifications to the schema of the forest. The schema determines the types of objects permitted in the forest and the attributes of those objects.
• The Domain Naming Master tracks the names of all domains in the forest and is required to add new domains to the forest or delete existing domains from the forest. It is also responsible for group membership.

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 an 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.^[3]

Certain FSMO roles depend on the DC being a Global Catalog (GC) 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 (unless all domain controllers in the domain are also global catalog servers), 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 (and potentially damaging) behaviour in a multi-domain environment.^[4]

Active Directory support tools

Note: These tools are not restricted to FSMO administration.

Several additional tools that can be used to configure, manage, and debug Active Directory are available as command-line tools.^[5] These tools are known as the Support Tools and are available on the installation CD in the \Support\Tools folder.

List and description of tools

In addition, the Active Directory Migration Tool (ADMT)^[6] is available to help you migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains to Active Directory domains. The Active Directory Migration Tool is a Microsoft Management Console (MMC) snap-in and is available on the installation compact disk in the \i386\ADMT folder.

Tool Description

• Movetree: Move objects from one domain to another.
• SIDWalk: Set the access control lists on objects previously owned by accounts that were moved, orphaned, or deleted.
• LDP: Allows LDAP operations to be performed against Active Directory. This tool has a graphical user interface (GUI).
• Dnscmd: Enables administrator to check presence of domain controller locator records in DNS, add or delete such records and perform configuration of DNS servers, zones and records.
• DSACLS: View or modify the access control lists of directory objects.
• Netdom: Batch management of trusts, joining computers to domains, verifying trusts and secure channels.
• NETDiag: Check end to end network and distributed services functions.
• NLTest: Check that the locator and secure channel are functioning.
• Repadmin: Check replication consistency between replication partners, monitor replication status, display replication metadata, force replication events and knowledge consistency checker recalculation.
• Replmon: Display replication topology, monitor replication status (including group policies), force replication events and knowledge consistency checker recalculation. This tool has a graphical user interface (GUI).
• DSAStat: Compare directory information on domain controllers and detect differences.
• ADSI Edit: A Microsoft Management Console (MMC) snap-in used to view all objects in the directory (including schema and configuration information), modify objects and set access control lists on objects.
• SDCheck: Check access control list propagation and replication for specified objects in the directory. This tool enables an administrator to determine if access control lists are being inherited correctly and if access control list changes are being replicated from one domain controller to another.
• ACLDiag: Determine whether a user has been assigned or denied access to a directory object. It can also be used to reset access control lists to their default state.
• DFSUtil: Command-line utility for managing all aspects of Distributed File System (DFS), checking the configuration concurrency of DFS servers, and displaying the DFS topology.
• Dcdiag: Analyzes the state of domain controllers in a forest or enterprise and reports any problems to assist in troubleshooting.
• Active Directory Migration Tool (ADMT): A Microsoft Management Console (MMC) snap-in used to migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains to Active Directory domains (available on the installation compact disk in the \i386\ADMT folder).
• RENDOM: This is a command-line based tool which is help to RENAME DOMAIN's name (used on windows server 2003 Based domains only). by default available in server 2003 setup disk \ENGLISH\WIN2003\ENT\VALUEADD\MSFT\MGMT\DOMREN.

Global Catalog

Note: The Global Catalog task is not restricted to a single host within a domain or forest. It is not a FSMO task.

The Global Catalog (GC) contains an entry for every object in an enterprise forest but only a few properties for each object.^[7] An entire forest shares a Global Catalog, with multiple servers holding copies. You can perform an enterprise wide forest search only on the properties in the GC, whereas you can search for any property in a user’s domain tree. Only Directory Services (DS) or Domain Controller (DC) can hold a copy of the GC.

Configuring an excessive number of GCs in a domain wastes network bandwidth during replication. One GC server per domain in each physical location is sufficient. Windows NT sets servers as GCs as necessary, so you don’t need to configure additional GCs unless you notice slow query response times.

Because full searches involve querying the whole domain tree rather than the GC, grouping the enterprise into one tree will improve your searches. Thus, you can search for items not in the GC.

By default, the first DC in the First Domain in the First Tree in the AD Forest (the root domain) will be configured as the GC.

You can configure another DC to become the GC, or even add it as another GC while keeping the first default one. Reasons for such an action might be the need to place a GC in each AD Site. To configure a Windows 2000/2003 Domain Controller as a GC server, perform the following steps:

Start the Microsoft Management Console (MMC) Active Directory Sites and Services Manager. (From the Start menu, select Programs, Administrative Tools, Active Directory Sites and Services Manager).

Select the Sites branch. Select the site that owns the server, and expand the Servers branch. Select the server you want to configure. Right-click NTDS Settings, and select Properties. Select or clear the Global Catalog Server checkbox, which the Screen shows. Click Apply, OK.

You must allow for the GC to replicate itself throughout the forest. This process might take anywhere between 10–15 minutes to even several days, all depending on your AD infrastructure.

References

http://support.microsoft.com/kb/324801