FSMO Placement - Revision history

Ledhed at 01:11, 9 September 2013

2013-09-09T01:11:43Z

Ledhed: /* What about ... */

2013-09-09T01:11:32Z

‎What about ...

Ledhed: /* What about ... */

2013-09-09T01:09:38Z

‎What about ...

Ledhed: /* Split between 2 Domain Controllers */

2013-09-09T01:08:58Z

‎Split between 2 Domain Controllers

Ledhed at 01:08, 9 September 2013

2013-09-09T01:08:18Z

Ledhed at 00:57, 9 September 2013

2013-09-09T00:57:53Z

Ledhed: Created page with "== Overview == FSMO Roles are critical components of Active Directory.
They can only exist on a single Domain Controller at any given time.
So the question often ari..."

2013-09-09T00:38:36Z

Created page with "== Overview == FSMO Roles are critical components of Active Directory. They can only exist on a single Domain Controller at any given time. So the question often ari..."

New page

== Overview ==

FSMO Roles are critical components of Active Directory. 
They can only exist on a single Domain Controller at any given time. 

So the question often arises "Where should we place the FSMO's". 
The answers vary from admin to admin.

In my experience (ranging from small mom & pop businesses to large scale Enterprise) 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 small environments. For example, you run a version of SBS (which only allows one DC). Or you're in a small single forest environment. 
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 balancing. 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.

== References ==
http://blogs.technet.com/b/bpuhl/archive/2005/12/07/415761.aspx

[[Category:FSMO]]

← Older revision		Revision as of 01:11, 9 September 2013
Line 51:		Line 51:

	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.		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.
		+
		+

	== References ==		== References ==

@@ Line 46: / Line 46: @@
 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.
+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.
-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 ==

@@ Line 42: / Line 42: @@
 == 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."
+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."<br>
 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.
@@ Line 49: / Line 49: @@
 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 ==

@@ Line 37: / Line 37: @@
   Sub Domain:   Females
-  Humans FSMO:  SM, DNM, IR, RID, PDC
+  Humans FSMO:  SM, DNM, IM, RID, PDC
-  Males FSMO:            IR, RID, PDC
+  Males FSMO:            IM, RID, PDC
-  Females FSMO:          IR, RID, PDC
+  Females FSMO:          IM, RID, PDC
-−
 == What about ... ==

@@ Line 10: / Line 10: @@
 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. (Single Forest/Domain)
-# Place the Schema Master and Domain Naming Master roles on one DC, and the remaining Roles, on another.
+# Place the Schema Master and Domain Naming Master roles on one DC, and the remaining roles, on another. (Single Forest/Multi Domain)
@@ Line 22: / Line 22: @@
 == Split between 2 Domain Controllers ==
-This approach can makes sense in larger environments.
+This approach can makes sense in larger environments where you have multiple domains within your forest.
 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.
+I consider this a valid reason, but not 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.

@@ Line 3: / Line 3: @@
 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 arises "Where should we place the FSMO's".<br>
 The answers vary from admin to admin.
-In my experience (ranging from small mom & pop businesses to large scale Enterprise) there are only 2 feasible answers to this question.
+In my experience there are only 2 feasible answers to this question.
 # Place all the FSMO's on a single DC.
@@ Line 14: / Line 15: @@
 == All your eggs in one basket ==
-This approach makes sense in small environments. For example, you run a version of SBS (which only allows one DC). Or you're in a small single forest environment.<br>
+This approach makes sense in most environments.
 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.
@@ 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.
-Another example is for load balancing. 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.
+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.
 == References ==
 http://blogs.technet.com/b/bpuhl/archive/2005/12/07/415761.aspx

FSMO Placement - Revision history

Ledhed at 01:11, 9 September 2013

Ledhed: /* What about ... */

Ledhed: /* What about ... */

Ledhed: /* Split between 2 Domain Controllers */

Ledhed at 01:08, 9 September 2013

Ledhed at 00:57, 9 September 2013

Ledhed: Created page with "== Overview == FSMO Roles are critical components of Active Directory. They can only exist on a single Domain Controller at any given time. So the question often ari..."

Ledhed: Created page with "== Overview == FSMO Roles are critical components of Active Directory.
They can only exist on a single Domain Controller at any given time.
So the question often ari..."