Friday, March 14, 2008

Recommendations for FSMO Role Placement

I have recently posted some guidelines showing the best placement for distributing FSMO roles. Below article is straight taken from TechNet and it has great information. I am posting it as it is here in my blog..Although you can assign the operations master roles to any domain controller, follow these guidelines to minimize administrative overhead and ensure the performance of Active Directory. If a domain controller that is hosting operations master roles fails, following these guidelines also simplifies the recovery process. Guidelines for role placement include:

  • Leave the two forest-level roles on a domain controller in the forest root domain.
  • Place the three domain-level roles on the same domain controller.
  • Do not place the domain-level roles on a global catalog server.
  • Place the domain-level roles on a higher performance domain controller.
  • Adjust the workload of the operations master role holder, if necessary.

Choose an additional domain controller as the standby operations master for the forest-level roles and choose an additional domain controller as the standby for the domain-level roles.

Requirements for Infrastructure Master Placement

  • Do not place the infrastructure master on a domain controller that is also a global catalog server.

The infrastructure master updates the names of security principals for any domain-named linked attributes. For example, if a user from one domain is a member of a group in a second domain and the users name is changed in the first domain, then the second domain is not notified that the users name must be updated in the groups membership list. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never becomes aware of the change. The infrastructure master constantly monitors group memberships, looking for security principals from other domains. If it finds one, it checks with the security principals domain to verify that the information is updated. If the information is out of date, the infrastructure master performs the update and then replicates the change to the other domain controllers in its domain.

Two exceptions apply to this rule.

First, if all the domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalogs do replicate the updated information regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller that hosts the infrastructure master role is not needed because security principals from other domains do not exist.

Guidelines for Role Placement

By improperly placing operations master role holders, you might prevent clients from changing their passwords or being able to add domains and new objects, such as Users and Groups. You might also be unable to make changes to the schema. In addition, name changes might not properly appear within group memberships that are displayed in the user interface.

As your environment changes, you must avoid the problems associated with improperly placed operations master role holders. Eventually, you might need to reassign the roles to other domain controllers.

Although you can assign the forest-level and domain-level operations master roles to any domain controller in the forest and domain respectively, improperly placing the infrastructure master role can cause it to function improperly. Other improper configurations can increase administrative overhead.

Forest-level Role placement in the Forest Root Domain

  • The first domain controller created in the forest is assigned the schema master and domain naming master roles. To ease administration and backup and restore procedures, leave these roles on the original forest root domain controller. Moving the roles to other domain controllers does not improve performance. Separating the roles creates additional administrative overhead when you must identify the standby operations masters and when you implement a backup and restore policy.
  • Unlike the PDC emulator role, forest-level roles rarely place a significant burden on the domain controller. Keep these roles together to provide easy, predictable management.

Domain-level Role Placement on the Same Domain Controller

  • The three domain-level roles are assigned to the first domain controller created in a new domain. Except for the forest root domain, leave the roles at that location. Keep the roles together unless the workload on your operations master justifies the additional management burden of separating the roles.
  • Because all clients prior to Active Directory submit updates to the PDC emulator, the domain controller holding that role uses a higher number of RIDs. Place the PDC emulator and RID master roles on the same domain controller so that these two roles interact more efficiently.
  • If you must separate the roles, you can still use a single standby operations master for all three roles. However, you must ensure that the standby is a replication partner of all three of the role holders.
  • Backup and restore procedures also become more complex if you separate the roles. Special care must be taken to restore a domain controller that hosted an operations master role. By hosting the roles on a single computer, you minimize the steps that are required to restore a role holder.

Domain-level Role Placement on a Higher Performance Domain Controller

Host the PDC emulator role on a powerful and reliable domain controller to ensure that it is available and capable of handling the workload. Of all the operations master roles, the PDC emulator creates the most overhead on the server that is hosting the role. It has the most intensive daily interaction with other systems on the network. The PDC emulator has the greatest potential to affect daily operations of the


Oz ozugurlu,
Systems Engineer
Security Project+ Server+

No comments: