FSMO Roles

Each domain in an AD-based network has three FSMO roles that must be assigned to domain controllers within the domain:

PDC Emulator.

The DC holding this role plays PDC for any legacy Windows NT BDCs you may still have running. But even if you've migrated all your legacy DCs and your domains are running in Windows 2000 mixed functional level or higher, the PDC Emulator role is still important because the PDC Emulator enforces account lockout, handles password changes, and synchronizes time for all DCs in the domain.

RID Master.

 When an administrator creates a new security principle in Active Directory (typically a new user or group) the SID for the new object is constructed from the domain SID and a relative ID (RID) selected from a pool of RIDs on the domain's DCs. If this pool starts running low (under 50% remaining) the RID Master replenishes it.

Infrastructure Master.

 Ensures cross-domain object references are handled properly, such as when objects in one domain are referenced by objects in a different domain.
The forest root domain also has two additional FSMO roles that must be assigned to domain controllers in that domain:

Domain Naming Master.

 Handles changes to the namespace, for example when a new child domain is added to a parent domain.
Schema Master. Handles changes to the schema and replicates these changes to all other DCs throughout the forest.

There are a number of ways you can determine which DCs are FSMO roles holders on your network, but the simplest is to install the Support Tools from the \Support\Tools folder on your product CD and type netdom query fsmo at a command prompt:

Symptoms of FSMO Problems


If one or more of your FSMO role holders has problems, bad things can happen. To help you troubleshoot such situations, the table below describes some of the symptoms that can occur when FSMO role holders go missing or don't work properly.

1. Schema Master fails: Can't modify the schema. Can't raise the functional level for the forest. This role holder must be available when the raising the forest functional level.

2. Domain Naming Master fails: Can't add or remove a domain. Can't promote or demote a DC. Changes to the namespace need this role holder.

3. PDC Emulator fails:
A) Users can't log on because if system clocks become unsynchronized, Kerberos may fail.
B) Can't change passwords because Password changes need this role holder.
C) Account lockout not working because Account lockout enforcement needs this role holder.
D) Can't raise the functional level for a domain because this role holder must be available when the raising the domain functional level.

4. RID Master fails: Can't create new users or groups because RID pool has been depleted.

5. Infrastructure Master fails: Problems with universal group memberships because Cross-domain objects references need this role holder.

Rules for FSMO Role Placement

Since FSMO roles are crucial for the proper functioning of an AD-based network, it's a good idea to get them right from the planning stage of your deployment. By default, when you install the first DC of your forest root domain, this first DC holds all five FSMO roles. When you install the first DC of any other domain in your forest, that DC will hold all three domain FSMO roles (PDC Emulator, RID Master, and Infrastructure Master). Depending on the complexity of your network, however, this default roles assignment may not be appropriate, so you need to transfer some of your roles to a different machine to achieve optimal FSMO-role placement on your network.

Proper FSMO role placement basically boils down to a few simple rules, tips, and exceptions:

Rule 1: The PDC Emulator and RID Master roles should be on the same machine because the PDC Emulator is a large consumer of RIDs.
Tip: Since the PDC Emulator is the role that does the most work by far of any FSMO role, if the machine holding the PDC Emulator role is heavily utilized then move this role and the RID Master role to a different DC, preferable not a global catalog server (GC) since those are often heavily used also.

Rule 2: The Infrastructure Master should not be placed on a GC.
Tip: Make sure the Infrastructure Master has a GC in the same site as a direct replication partner.

Exception 1: It's OK to put the Infrastructure Master on a GC if your forest has only one domain.
Exception 2: It's OK to put the Infrastructure Master on a GC if every DC in your forest has the GC.

Rule 3: For simpler management, the Schema Master and Domain Naming Master can be on the same machine, which should also be a GC.

Exception: If you've raised your forest functional level to Windows Server 2003, the Domain Naming Master doesn't need to be on a GC, but it should at least be a direct replication partner with a GC in the same site.

Rule 4: Proactively check from time to time to confirm that all FSMO roles are available or write a script to do this automatically.
Tip: If any FSMO role holders at a remote site are unavailable, check first to see if your WAN link is down.