Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

Windows Server 2003 on HP ProLiant Servers : Server Placement (part 3) - Flexible Single Master Operations (FSMO) Placement

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/22/2013 5:30:26 PM

5. Flexible Single Master Operations (FSMO) Placement

The placement of FSMO role holders, sometimes referred to as operations masters, is an important design consideration. Although FSMO placement is important to ensure high accessibility by clients, DCs, and GCs for such things as password changes, new account creations, Group Policy modifications, and Time Services, recovery of FSMO role holders is equally critical.

A brief review of FSMO roles will help determine where the DCs hosting those roles should be placed. The sections following describe the potential impact to the environment at the loss of each FSMO role holder. This helps determine the importance of availability of that DC; what kind of support effort needs to be expended to keep it online in case of a failure (that is, does it require immediate attention or can it be handled on a lower severity level.) This also helps determine whether another DC should seize the role, and if so, when that should be done.


When demoting a DC that is an FSMO role holder, the roles should be transferred to another DC first. However, the demotion process identifies any FSMO roles held by the DC and transfers them to another DC. This usually works successfully, but the DC that DCPromo chooses to receive the roles might not be the one you want. Make sure to transfer the roles before demoting a DC if possible. If the DC has to be forcefully demoted, or if the DC can never be brought back online, then seizure is the solution to making the roles available again.

Forest-Wide Roles

These roles relate to operations in the schema and configuration naming contexts (NCs), and apply to every DC in the forest. As such, any DC in any domain in the forest can hold these roles. The two forest-wide roles are schema master and domain naming master.

Schema Master

Availability of the schema master is required only when modifications to the schema take place. This could include execution of Exchange's ForestPrep utility, which adds classes and attributes to the schema in preparation for installing Exchange; execution of the ADPrep utility to prepare a Windows 2000 forest to be upgraded to 2003; execution of Windows 2003's Domain Rename operation; and installation of third-party applications that modify the schema. However, on a day-to-day operational level, loss of this role holder will not affect the user population.

If the original role holder can come back online before any schema modifications must take place, don't move the role to another DC. In most cases, the schema master can be left offline until the original is restored.

Domain Naming Master

Contact with the domain naming master is required to create or delete domains (during DCPromo) and for the Domain Rename process as well as other operations that require modifications of the domain structure. Loss of the domain naming master role holder does not have an immediate impact on the forest and usually does not require seizing the role to another DC that has good network connectivity to the other DCs as well as the server resources to handle the extra load. The domain naming master role must be held by a GC server.


If you have a mixed Windows 2000 and 2003 domain in the forest (that is, Windows 2000 and Windows Server 2003 DCs are in the domain), you must put the domain-naming master on a Windows Server 2003 DC so it can support application partitions.

Domain-Wide Roles

The Relative IDentifier (RID) master, Primary Domain Controller (PDC) Emulator, and infrastructure master are the three operation master roles whose scope is the domain. Thus, each domain contains DCs with these roles.

RID Master

Each security principal (user, computer, or group) is identified in AD by a unique Security IDentifier (SID). The SID consists of two parts: a domain SID (SID that is unique for the domain) and an RID. All security principals in the domain contain the same domain SID and the unique RID, which forms the object's unique SID.

RIDs are assigned by a DC in the domain in which the security principal resides. Because RIDs must be unique, a single DC holds the FSMO “RID master” role. The RID master is a single source of generating RIDS and handing them out to the DCs, thus ensuring that two DCs don't give out the same RID to an object.

The RID master allocates blocks of RIDs to DCs to allow them to create new accounts (user and computer) and groups, and assign a unique SID to each account. The RID master allocates blocks of 500 RIDs at a time to each DC and when that block is 50% depleted, another block is allocated to the DC. Thus, the DC has a considerable buffer to allow it to create accounts even if connectivity to the RID master is broken. Loss of this role holder is not critical unless a large number of accounts are created, such as during a migration, or an application is run that creates large numbers of accounts. The size of the RID pool allocated to each DC can be modified in the Registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values\by setting the RID Block Size (REG_DWORD) to a value greater than 500. Setting it to less than 500 leaves the default setting of 500 in place. Microsoft recommends leaving this at the default, but if you do modify it, note that setting it abnormally high can have “adverse effects on the domain longevity,” although the reasoning for these recommendations is not given (see Microsoft KB article 316201, “RID Pool Allocation and Sizing Changes in Windows 2000 SP4”).


Windows 2000 preSP4 reallocated the RID pool to a DC when it was 80% depleted, or contained about 100 RIDs. When performing migrations or other automated tasks in which large numbers of users, groups, or computer accounts were created, this could deplete the RID pool quickly. Lowering the threshold for a refresh of the pool is intended to minimize the probability of exhausting the RID pool and prevent creating accounts on a DC if the RID master cannot be contacted or the RID pool cannot be refreshed in time.

The threshold for Windows 2000 SP4 and Windows Server 2003 RID masters to refresh the DCs' RID pool is now 50%.

One issue that surfaced in Windows 2000 was the case of an RID master being brought back online when the role had been seized. This sometimes caused duplicate SIDs to be assigned because the old RID master had not replicated to find out that it wasn't the RID master anymore. Windows 2000 postSP2 and Windows 2003 changed this behavior by requiring the RID master to do one full synch with its NC (domain) before advertising itself as a RID master and handing out RIDs.

PDC Emulator

The PDC Emulator has a number of critical roles, many of which affect users. These functions include

  • Password changes: Password changes are recorded on the PDC Emulator as well as the authenticating DC to ensure the new password can be used until it is fully replicated to all DCs.

  • Group Policy editing: Group Policy Objects (GPOs) are modified preferentially on the PDC to permit a single source for changes and reduce the probability of losing changes to the “last writer.”

  • Time Services: The PDC in each domain is responsible for time synchronization of all DCs, who in turn are authoritative time sources for all clients in the domain. In a multiple-domain forest, the root domain PDC is the time source for PDCs in other domains in the forest.

  • Account lockouts: Processing account lockouts prevents security attacks that attempt to guess accounts and passwords on multiple DCs before the account lockout could otherwise be processed in normal replication. 

  • Acting as the domain master browser: This is a role that has been associated with the PDC since Windows NT 4.0.

The PDC Emulator plays a number of roles, and the list is growing. You will probably note additional functions given to the PDC Emulator as Microsoft develops the operating system (OS) and finds additional need for a single source for functions.

Thus, the PDC Emulator failure is immediately visible to users in a mixed-mode domain or in a domain supporting downlevel clients because it has security implications, can cause browsing failures, and could cause time sync failures, possibly resulting in authentication failures and security breakdowns. The PDC Emulator is perhaps the most critical of all role holders and should be brought back online via transfer or seizure if it will be offline for an extended period of time. Each organization must define this period.

Infrastructure Master

The infrastructure master is responsible for resolving interdomain lookups. If a user from the Americas domain is added to a group in the Europe domain, the infrastructure master compares the user-group references that it knows about for objects in its domain with what a GC knows about those objects. If the GC has different information, the infrastructure master updates its data.

Loss of the infrastructure master is not serious and won't affect users. For example, suppose an account was created for Abigail Witbeck in the North America domain, was added to the LondonUsers security group in the Europe domain, and replicated to other DCs in the domain as well as GCs in the forest. Abigail sends a request that her username be changed to Shanna Witbeck (as she prefers using her middle name), so you change the account to Shanna Witbeck. If the infrastructure master is unavailable in the North America domain, the LondonUsers group still contains the object “Abigail Witbeck.” This poses no security risk, and would cause confusion only if an Administrator was observing the group membership before the infrastructure master came back online to make the change. Note that the infrastructure master in the domain that the group lives in (Europe domain in this example) is responsible for updating the name change in the group membership.

The infrastructure master should not be on a GC. This would cause the infrastructure master to fail to update other DCs, because it updates only data that differs from the GC. If the infrastructure master is a GC, there is no difference and the domain DCs don't get the update. 

In two instances, the infrastructure master role is irrelevant:

  • A single domain in which there are no cross-domain references and each DC is essentially a GC.

  • A multiple domain forest in which every DC is designated as a GC; thus there is no difference between what a DC has and what a GC has.

With the FSMO roles defined, let's examine how to determine where to place the FSMO role holder DCs to make sure they are able to efficiently serve their purposes.

Placement of FSMO Role Holders

In general, the placement of DCs holding FSMO roles should

  • Have sufficient resources (memory, processor, disk space, and so on) to handle the load. The PDC Emulator demands more resources, typically, than the other role holders, and generally is the only FSMO that requires special consideration for hardware resources.

  • Have sufficient network connectivity to be accessible to clients, servers, and DCs in the domain or forest. Placing FSMO role holders at the well-connected hub sites is a common practice. Remember that there is only one PDC Emulator in the domain. If you have a single-domain model and have clients all over the world, connectivity to the PDC could be an issue. Make certain the PDC is located in a well-connected site.

  • Have sufficient security to protect role holders against malicious physical attacks. Just like any DC, an FSMO role holder must be protected against the possibility of thieves stealing the server or the disk. There have been a number of instances of thieves stealing the disk drive out of a DC or GC server, and thus a copy of all usernames and other sensitive data. Don't overlook this security measure.

  • Have sufficient support resources—personnel and hardware replacements—to mitigate outages. Make sure the after-hours support team has the training and information they need to resolve problems should they occur over nights and weekends. Make sure you have good coordination between shifts.

  • Define FSMO outage in the SLA (Service Level Agreement) so everyone knows how to handle outages (this is related to the previous item). Determine what conditions should be present for each FSMO role holder to justify a seizure of the role to another machine. Make sure your staff understands these rules.

  • Define and maintain one or more “standby” DCs to transfer FSMO roles to in case of an outage that requires transfer or seizure of the role(s). These DCs should have the resources and network connectivity required to handle the load that the role carries.

Transfer and Seizure of Roles

To move roles from one DC to another, they should be “transferred.” This is accomplished via the Active Directory Users and Computers snap-in for domain-wide roles, the Active Directory Domains and Trusts snap-in for the domain naming master role, or the Schema Manager snap-in for the schema master role. The bad thing about using these snap-ins is that there are three different snap-ins to change the five roles. The NTDSUtil.exe tool, available in the Windows 2003 support tools, is my personal favorite because it displays all current role holders and permits easier recognition of role holders and transfer or seizure to new DCs. Another tool, Replication Monitor, available in the Windows 2000 and 2003 support tools, not only allows you to see who the role holders are for all five roles and transfer the roles, but it also allows you to see whether the current role holders can be contacted. In the Replication Monitor application, you can add a server using the Add Monitored Server menu option. Once added, right-click on the server icon, go to Properties, and then select the FSMO tab. The role holders are listed along with a Query button. Clicking this button causes that server to query the FSMO role holder to see whether it can be contacted.


The fastest way to find who the role holders are for the five FSMO roles is using the Netdom command:

C:\>netdom /query fsmo
Schema owner                  qtest-dc22.Qtest.cpqcorp.net
Domain role owner             qtest-dc22.Qtest.cpqcorp.net
PDC role                      qtest-dc22.Qtest.cpqcorp.net
RID pool manager              qtest-dc22.Qtest.cpqcorp.net
Infrastructure owner          qtest-dc5.Qtest.cpqcorp.net
The command completed successfully.

Transferring roles requires that the existing role holder be online and accessible during the transfer process. The role is moved to another DC and the original DC relinquishes the role. However, in the case of a DC that is unavailable because of hardware failure, network failure, and so forth, transferring the role is not possible.

Seizure of roles can be executed via the snap-in or NTDSUtil, which simply assigns a particular DC to be the new role holder and advertises that fact to the other DCs in the domain or forest as needed. The danger, of course, is when the original comes back online and it doesn't know of the role change. This scenario has been modified somewhat in Windows 2003 to reduce problems that occurred in Windows 2000, such as duplicate RIDs being assigned.

Whenever a seizure is attempted via the snap-in or NTDSUtil, a transfer is always attempted first. If the transfer fails, the seizure proceeds. A seizure should only be used when it's critical that the role holder comes back online without waiting for the original.


Since the early days of Windows 2000, Microsoft has always recommended that FSMO role holders never come back online after their role has been seized. Although Windows 2003 and Windows 2000 SP3+ has made the AD more tolerant of this situation, it's best to be safe and just wipe and reload the machine, cleaning the objects out of the AD. (See Microsoft KB article 216498, “How to Remove Active Directory objects after an unsuccessful DC demotion,” for more information.) Thus, in determining whether a role should be seized, assess the impact to the environment by going without that role as opposed to wiping and reloading a DC or GC and cleaning up the AD.

The policy of FSMO role seizure should be defined in an SLA. This definition will vary from environment to environment.

Other -----------------
- Managing SharePoint 2010 with Windows PowerShell : Managing SharePoint 2010 Sites (part 2)
- Managing SharePoint 2010 with Windows PowerShell : Managing SharePoint 2010 Sites (part 1)
- System Center Configuration Manager 2007 : Reporting Configuration (part 3) - Console Reporting Links, Relational Database Concepts
- System Center Configuration Manager 2007 : Reporting Configuration (part 2) - Copying ConfigMgr Classic Reports to SQL Reporting Services, Report Categories
- System Center Configuration Manager 2007 : Reporting Configuration (part 1) - Configuring the Reporting Point for Classic Reporting, SRS Reporting
- System Center Configuration Manager 2007 : ConfigMgr Classic Reports Versus SQL Reporting Services
- Deploying the Client for Microsoft Exchange Server 2007 : Deploying with Microsoft Systems Management Server, Managing Postdeployment Tasks
- Deploying the Client for Microsoft Exchange Server 2007 : Installing the Exchange Client, Pushing Client Software with Windows Server 2003 Group Policies
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from Dynamics CRM to BizTalk Server (part 3) - Registering the plugin, Testing the plugin
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from Dynamics CRM to BizTalk Server (part 2) - Writing the Dynamics CRM plugin
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server