FSMO roles for 5 domain controllers-Best way to place them

One domain controller holds all FSMO domain roles
-Infrastructure master
-RID Master
-PDC Emulator

The same domain controller holds all FSMO forest roles as well
-Domain Naming Master
-Schema Master

There are 5 domain controllers think there is a better way to separate this,


What would be the best way to organise this?

I would think the forest roles and domain roles should be on different domain controllers? Correct?
Who is Participating?
in recent years FSMO placement is not an issue nor you need to micro manage FSMO roles as long as

- you're able to seize roles
- all DCs are GCs
Best practice:
- perform regular backups of at least 2 DC per domain

Time sync:
PDC emulator of forest root should be able to reach a NTP server for time sync.
Schema updates:
If you are managing Exchange/Lync, schema master FSMO role would need to be moved in the domain where you install/apply updates since they sometimes need to extend AD schema.

Some example powershell code to find all FSMO roles in a forest - can be used to schedule reports
import-module ActiveDirectory
# retrieve all Forests DCs
$AllDCs = (Get-ADForest).Domains | % { Get-ADDomainController -Filter * -Server $_ } 
# show FSMO roles
$AllDCs | ft -AutoSize OperationMasterRoles,Name,IP,Domain,operatingsystem

Open in new window

No need to distribute FSMO when your all domain controllers are global catalog server in case you have single domain single forest
put all fsmo on any one dc in site where at least two dcs are available
in case server hosting fsmo gone down, u can seize all roles to other working dc in same site
distributing FSMO roles across multiple server unnecessarily increase setup complexity and dependency
if any dc is without GC role in same site as infrastructure master role, move infrastructure master on that dc to avoid non replicating delta changes, in reality there is no reason to not make server as GC in  today's environment where network links have pretty much good badwidth, in old days people use to keep dc in branch office without GC and enable UGMC on that dc
in case you have child domains, keep all child domain wide roles on single dc as long as all DC's are GC
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. See KB 223787 and KB 255504 for how to transfer roles. KB 321469 also has information on how to transfer roles using scripts.

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.

reference : http://www.windowsdevcenter.com/pub/a/windows/2004/06/15/fsmo.html
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Indie101Author Commented:
Hi admin I would like to amend this and add mahesh to the list to get points? I was accessing on my phone and didnt fully see the list of contributors so would like to amend and split 3 ways if possible
You cannot move schema master role to dc in other domains such as child or tree root domain
Schema master starts with forest root domain and ends with root domain only it can be moved to dcs in root domain only
Thank you for pointing it out. You can perform schema updates as long as the host you're updating from is in the same domain/site of the schema master FSMO role holder.
You can transfer FSMO role actually, as per


NOTE:  The Schema container (cn=schema,cn=configuration,dc=< forest root domainName >) contains all of the class and attribute definitions that are required to locate objects in Active Directory and to create new objects. It is the topmost object of the schema directory partition.
The schema is replicated on ALL DCs of the forest. FSMO schema master role can reside on any DC. Just test it in lab.
1st of all, no matter where u install apps in child / parent, schema modification always done in root domain and as part of replication it replicated to other domains
Show me any article where it states that u can or need to move schema master to child domain when you install exchange in child domain
I also did exchange installations in child domain, always did schema modification in root domain once for All, u do need to prepare child domain
The reason u cannot do this because you cannot change root domain, when u 1st create active directory, the 1st domain become root domain and this remains *root*, child domain cannot be converted to root domain. Hence schema master cannot be transferred or seized to child domain, if parent domain dies, u need to restore it from backup and seize operations master. The same thing is true in case of naming master
Check below just for reference
Schema object is replicated forestwide, so you can update it forestwide. That means on all DCs of the forest. I just confirmed on a windows 2008 r2 FFL forest that the role can be transferred via ntdsutil and schema management mmc. Will provide screenshots later. Moreover, Microsoft technet says that schema master fsmo role can be moved to any DC. Since we are unable to find an agreement on this and since I just confirmed this in my lab, I invite readers to test for themselves and we continue via PM and getback to this question when we are able to converge on an answer.
Let me also test and will get back on same thread though question is closed
From Active Directory, 5th Ed.:
It is a common misunderstanding that the schema and domain naming masters cannot be hosted outside of the root domain. Any domain controller in the forest (from any domain) can host the schema and domain naming master FSMO roles. In general, we recommend that these FSMOs be kept on a domain controller in the forest root unless you have a reason to place them elsewhere.”
You are right
I have also tested in lab and working as expected
This thread can be used by others as reference

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.