(Created page with "== Overview == FSMO Roles are critical components of Active Directory.<br> They can only exist on a single Domain Controller at any given time.<br> So the question often ari...") |
|||
| Line 3: | Line 3: | ||
FSMO Roles are critical components of Active Directory.<br> | FSMO Roles are critical components of Active Directory.<br> | ||
They can only exist on a single Domain Controller at any given time.<br> | They can only exist on a single Domain Controller at any given time.<br> | ||
| + | This makes them a 'Single Point of Failure' in many administrators eyes.<br> | ||
So the question often arises "Where should we place the FSMO's".<br> | So the question often arises "Where should we place the FSMO's".<br> | ||
The answers vary from admin to admin. | The answers vary from admin to admin. | ||
| − | In my experience | + | In my experience there are only 2 feasible answers to this question. |
# Place all the FSMO's on a single DC. | # Place all the FSMO's on a single DC. | ||
| Line 14: | Line 15: | ||
== All your eggs in one basket == | == All your eggs in one basket == | ||
| − | This approach makes sense in | + | This approach makes sense in most environments. |
You may be asking yourself "Why wouldn't you want to distribute these critical roles?"<br> | You may be asking yourself "Why wouldn't you want to distribute these critical roles?"<br> | ||
The answer is simple: It creates unnecessary complexity. FSMO roles are critical but they can be seized in the event of a catastrophe. | The answer is simple: It creates unnecessary complexity. FSMO roles are critical but they can be seized in the event of a catastrophe. | ||
| + | |||
| Line 24: | Line 26: | ||
I consider this a valid reason, but not one that is very practical as the time savings is probably measured in seconds. | I consider this a valid reason, but not one that is very practical as the time savings is probably measured in seconds. | ||
| − | Another example is for load | + | Another example is for load distribution. The PDC Emulator role is probably the most CPU intensive role, so the argument could be made that placing it on its own DC could improve performance. |
| + | |||
| + | |||
| + | == What about ... == | ||
| + | Some of you may be thinking, "What if you have more than 5 DC's, why not place a role on each DC, that way if you loose one, you only ever have to transfer one role." | ||
| + | While I like the logic in this approach, it really isn't that simple. | ||
| + | Microsoft recommends placing the Schema Master and Domain Naming Master on the forest root PDC. | ||
| + | Microsoft also recommends placing the RID Master on the Domain PDC. | ||
| + | |||
| + | In a Single Forest/Fomain environment you would be placing 4 of your 5 roles on the same DC. | ||
| + | Also note that Microsoft recommends a Single Forest/Domain environment, so if you're going for best practices, you may as well go with the [[FSMO Placement#All your eggs in one basket|All your eggs in one basket]] approach. In a Single Forest/Domain the Infrastructure Master has little to do because there are no phantoms (external references) so its placement may as well be on the same DC as the rest of the FSMO roles. | ||
| + | |||
== References == | == References == | ||
| + | http://support.microsoft.com/kb/223346 | ||
| + | |||
http://blogs.technet.com/b/bpuhl/archive/2005/12/07/415761.aspx | http://blogs.technet.com/b/bpuhl/archive/2005/12/07/415761.aspx | ||
Revision as of 00:57, 9 September 2013
Contents
Overview
FSMO Roles are critical components of Active Directory.
They can only exist on a single Domain Controller at any given time.
This makes them a 'Single Point of Failure' in many administrators eyes.
So the question often arises "Where should we place the FSMO's".
The answers vary from admin to admin.
In my experience there are only 2 feasible answers to this question.
- Place all the FSMO's on a single DC.
- Place the Schema Master and Domain Naming Master roles on one DC, and the remaining Roles, on another.
All your eggs in one basket
This approach makes sense in most environments.
You may be asking yourself "Why wouldn't you want to distribute these critical roles?"
The answer is simple: It creates unnecessary complexity. FSMO roles are critical but they can be seized in the event of a catastrophe.
Split between 2 Domain Controllers
This approach can makes sense in larger environments. For example, If you do have a catastrophic failure of a FSMO role holder, then you only have to seize a small portion of the roles. I consider this a valid reason, but not one that is very practical as the time savings is probably measured in seconds.
Another example is for load distribution. The PDC Emulator role is probably the most CPU intensive role, so the argument could be made that placing it on its own DC could improve performance.
What about ...
Some of you may be thinking, "What if you have more than 5 DC's, why not place a role on each DC, that way if you loose one, you only ever have to transfer one role." While I like the logic in this approach, it really isn't that simple. Microsoft recommends placing the Schema Master and Domain Naming Master on the forest root PDC. Microsoft also recommends placing the RID Master on the Domain PDC.
In a Single Forest/Fomain environment you would be placing 4 of your 5 roles on the same DC. Also note that Microsoft recommends a Single Forest/Domain environment, so if you're going for best practices, you may as well go with the All your eggs in one basket approach. In a Single Forest/Domain the Infrastructure Master has little to do because there are no phantoms (external references) so its placement may as well be on the same DC as the rest of the FSMO roles.
References
http://support.microsoft.com/kb/223346
http://blogs.technet.com/b/bpuhl/archive/2005/12/07/415761.aspx