Active Directory FSMO Placement Guidance

FSMO Placement Guidance Summary:

• Make sure the PDC is highly available and connected.
• Place the PDC on your best hardware in a reliable hub site that contains replica domain controllers in the same Active Directory site and domain.
• Place the Forest FSMOs on the forest root PDC (schema master & domain naming master).
• Place the RID master on the domain PDC in the same domain.
• If you have a single domain environment, all DCs are GCs, OR you have enabled the recycle bin (see MSDN note below), place the infrastructure master on the PDC (which likely contains the other FSMO roles as well).
• Don’t move FSMOs around regularly. The PDC is targeted for a number of operations and network connections. It is best to not force clients to rediscover the PDC on a regular basis.

This means, in a single domain environment, it makes sense to place all the FSMOs on a single DC. Pick one that is highly available and well-connected. You may decide that selecting a virtual DC is the way to go since it can usually be moved to different hosts for DR/COOP reasons. Note that if you do go virtual for this DC, consider disabling VM host time synchronization.Though, there may be valid reasons for not doing so.

In a multiple domain environment, place the Forest FSMOs on the forest root PDC (schema master & domain naming master) and select one DC per domain on which to place all of the FSMOs – the PDC is a good choice assuming they are all GCs or the AD Recycle Bin is enabled.

MSDN NOTE:

When the Recycle Bin optional feature is enabled, every DC is responsible for updating its cross-domain object references in the event that 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.

From MSDN: “6.1.5.5 Infrastructure FSMO Role“

FSMO Role Information:

Schema Master

The Schema Master FSMO role owner is the DC responsible for performing updates to the directory schema. 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 FSMO role owner to all other DCs in the directory. There is only one Schema Master FSMO role per forest.

Domain Naming Master

The Domain Naming Master FSMO role owner is the DC responsible for making changes to the forest-wide domain name space of the directory in the Partitions container. This DC is the only one that can add or remove a domain or application NC from the directory. It can also add or remove cross references to domains in external directories. Only the Domain Naming Master FSMO role owner can write to the Partitions container or its children. There is only one Domain Naming Master FSMO role per forest.

RID Master

The RID Master 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.

RIDs are allocated from a RID pool that is controlled by the RID Master FSMO. When a new domain is created, the rIDAvailablePool attribute on the RID Manager object is set to a value of 4611686014132421709. This value defines the minimum and maximum RIDs that will be allocated by the RID Master FSMO within the domain. See [MS-DRSR] section 4.1.10.5.12 for details on how this attribute is used by the RID Master FSMO. Each DC in the domain is then 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 (see [MS-DRSR] section 4.1.10.4.3, PerformExtendedOpRequestMsg with ulExtendedOp = EXOP_FSMO_RID_REQ_ROLE). 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 (see [MS-DRSR] section 4.1.10.5.12, ProcessFsmoRoleRequest with ulExtendedOp = EXOP_FSMO_RID_REQ_ROLE). There is one RID Master FSMO role per domain in a directory.

PDC Emulator

The PDC Emulator FSMO role owner performs the following functions:

Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.

If a logon authentication fails at a given DC in a domain due to a bad password, the DC will forward the authentication request to the PDC emulator to validate the request against the most current password. If the PDC reports an invalid password to the DC, the DC will send back a bad password failure message to the user.

Account lockout is processed on the PDC emulator.

The PDC emulator FSMO also fulfills the role of the PDC in the NetLogon Remote Protocol methods described in [MS-NRPC] section 3. Therefore, the PDC emulator FSMO MUST support and perform all PDC specific functionality specified in that section. Every DC, other than the PDC emulator FSMO, MUST NOT perform this functionality.

There is one PDC Emulator FSMO role per domain in a directory.

Infrastructure Master

When an object in one domain is referenced by another object in another domain, it represents the reference as a dsname. There is one Infrastructure FSMO role per domain and application NC in a directory.

If all the domain controllers in a domain also host the GC, then all the domain controllers have the current data, and it is not important which domain controller owns the Infrastructure Master (IM) role. See section 3.1.1.5 for more information about the Infrastructure Master.

When the Recycle Bin optional feature is not enabled, the Infrastructure FSMO role owner is the DC responsible for updating a cross-domain object reference in the event that the referenced object is moved, renamed, or deleted. In this case, the Infrastructure Master role should be held by a domain controller that is not a GC server. If the Infrastructure Master runs on a GC server, it will not update object information, because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest.

When the Recycle Bin optional feature is enabled, every DC is responsible for updating its cross-domain object references in the event that 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.

From the TechNet Article (kb223346): FSMO placement and optimization on Active Directory domain controllers

FSMO availability and placement

The Active Directory Installation Wizard performs the initial placement of roles on domain controllers. This placement is frequently correct for directories that have just a few domain controllers. In a directory that has many domain controllers, the default placement may not be the best match for your network.

Consider the following in your selection criteria:

• It’s easier to keep track of FSMO roles if you host them on fewer computers.
• Place roles on domain controllers that are can be accessed by the computers that need access to a given role, especially on networks that are not fully routed. For example, to obtain a current or standby RID pool, or perform pass-through authentication, all DCs need network access to the RID and PDC role holders in their respective domains.
• If a role has to be moved to a different domain controller, and the current role holder is online and available, you should transfer (not seize) the role to the new domain controller. FSMO roles should only be seized if the current role holder is not available. For more information, go to the following Microsoft website:
  http://technet.microsoft.com/en-us/library/cc816945(WS.10).aspx
• FSMO roles that are assigned to domain controllers that are offline or in an error state only have to be transferred or seized if role-dependent operations are being performed. If the role holder can be made operational before the role is needed, you may delay seizing the role. If role availability is critical, transfer or seize the role as required. The PDC role in each domain should online at all times.
• Select a direct intrasite replication partner for existing role holders to act as a standby role holder. If the primary owner goes offline or fails, transfer or seize the role to the designated standby FSMO domain controller as required.

General recommendations for FSMO placement

• Place the schema master on the PDC of the forest root domain.
  
• Place the domain naming master on the forest root PDC.
  • The addition or removal of domains should be a tightly controlled operation. Place this role on the forest root PDC. Certain operations that use the domain naming master, such as creating or removing domains and application partitions, fail if the domain naming master is not available. On a domain controller that runs Microsoft Windows 2000, the domain naming master must also be hosted on a global catalog server. On domain controllers that run Windows Server 2003 or later versions, the domain naming master does not have to be a global catalog server.
    
• Place the PDC on your best hardware in a reliable hub site that contains replica domain controllers in the same Active Directory site and domain.
  • In large or busy environments, the PDC frequently has the highest CPU utilization because it handles pass-thru authentication and password updates. If high CPU utilization becomes a problem, identify the source, and this includes applications or computers that may be performing too many operations (transitively) targeting the PDC. Techniques to reduce CPU include the following:
    • Adding more or faster CPUs
    • Adding additional replicas
    • Adding additional memory to cache Active Directory objects
    • Removing the global catalog to avoid global catalog lookups
    • Reducing the number of incoming and outgoing replication partners
    • Increasing the replication schedule
    • Reducing authentication visibility by using LDAPSRVWEIGHT and LDAPPRIORITY, and by using the Randomize1CList feature that’s described in 231305.
      All domain controllers in a particular domain, and computers that run applications and admin tools that target the PDC, must have network connectivity to the domain PDC.
      
• Place the RID master on the domain PDC in the same domain.
  • RID master overhead is light, especially in mature domains that have already created the bulk of their users, computers, and groups. The domain PDC typically receives the most attention from administrators. Therefore, co-locating this role on the PDC helps ensure reliable availability. Make sure that existing domain controllers and newly promoted domain controllers, especially those promoted in remote or staging sites, have network connectivity to obtain active and standby RID pools from the RID master.
    
• Legacy guidance suggests placing the infrastructure master on a non-global catalog server.
  There are two rules to consider:
  
  • Single domain forest: 
    • In a forest that contains a single Active Directory domain, there are no phantoms. Therefore, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not. 
  • Multidomain forest: 
    • If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain. In practical terms, most administrators host the global catalog on every domain controller in the forest.
    • If every domain controller in a given domain that is located in a multidomain forest does not host the global catalog, the infrastructure master must be placed on a domain controller that does not host the global catalog.