Best practices for FSMO roles placement

These five roles which we are going to cover best practices for their placement are:

  1. Schema master
  2. Domain naming
  3. PDC emulator
  4. RID
  5. Infrastructure Master


Schema master and Domain naming

These two roles are rarely used. Domain naming is only used when we are planning to add a new domain to our forest. Schema master is used on rare conditions also. Deploying Exchange server in your organization is a case in point. So you see if these two roles fail in your organization, domain controllers and environment will carry on servicing to the clients unless there is a need to change the Schema or create a child domain. Provided that this information Microsoft recommends keeping these two roles on a single server. Since every time we want to add a child domain to the forest, Domain naming query the Global Catalog to check the naming, it is also highly recommend to place Global Catalog on the server which holds Domain naming and Schema master roles.


Primary Domain Controller (PDC Emulator)

One of the responsibilities of PDC is handling Password requests. It is highly recommend to place PDC emulator on a segment where has more users. The reason behind this recommendation is that with more users there will be more logon requests and as a result the password requests will be increased. So it is considered a wise move to keep PDC on segment which has more password requests.


Relative Identifier Role (RID)

Relative identifier allocates pools consisting RID’s to domain controllers. Since PDC uses more RID’s, in most cases administrators prefer to place RID and PDC in a single server.


Infrastructure Master Role

Due to creation of phantom objects, it is recommended by Microsoft to place Infrastructure Master role on a server where is not a global catalog server. Keep in mind that if all domain controllers in your environment are Global Catalog or your network is not a multi-domain structure there is no need to obey this rule, Because there will be no phantom objects in such scenarios.


Global Catalog

If you are insisting on not making all the domain controllers a global catalog, placement of global catalog should be considered. As a recommendation place the global catalog on a segment where is near to the application which needs global catalog direct contact. It is also recommended to keep a global catalog where more than hundred user accounts exist or there are plenty of Roaming Profiles.