FSMO roles should be separated across DCs in the domain?

[tosca925]

After getting advise in a previous post about FSMO roles i just wondered how many of you do split the roles across your DC's?

 

I presume a lot of people are like us and that they are on the first server that was installed and have never been moved. I know after advice and reading that Microsoft recommend that you do not put them all on one DC so this is what i intend to do when i configure or new DC.

[Ric_]

The magical wizard known as dcpromo will do this automagically for you as you promote 2nd and subsequent DCs.

 

There are also many articles available on the net.

[tosca925]

So does DCPROMO move FSMO roles from one DC to another as part of the process?

[OverWorked]

Unless your network is huge (bigger than most schools) I don't see the point. I suppose if your FSMO DC has not much else to do, then then it won't be overburdened.

[tosca925]

What do you class as Huge?

[john]

I class 300+ workstations and or 20+ servers as huge

[OverWorked]

Mmmm ... I'm not sure really. Sorry, it's late at night.

 

I meant dozens or hundreds or DCs across multiple sites. 'Enterprise' level stuff.

[Guest Guest]

I class 300+ workstations and or 20+ servers as huge

 

Thats the majority of schools round here then...

 

300ish WS'shere with 5 servers. We just have them all on one DC. Dont realy see the point of changing this s they both experiance near enough the same loads.

[Guest Guest]

I class 300+ workstations and or 20+ servers as huge

 

Thats the majority of schools round here then...

 

300ish WS'shere with 5 servers. We just have them all on one DC. Dont realy see the point of changing this s they both experiance near enough the same loads.

[sidewinder]

I seperate them, I doubt it has any major benefit but as its recommended to do so I just do it

 

From what I remember though only the RID Master and PDC Emulator are actually critical on a day to day basis in a single domain forest, so probably those would be the ones to seperate?

 

Something like the schema master role which is very rarely required will make no difference to performance whatever DC it is on

[GrumbleDook]

I listened in to a webcast around 2 years ago from the master himself, Mr Minasi ... a rough estimate of requirements (and it varies from setup to setup) for a company that has a high frequency of users that constantly log on and off can be 1 x DC for every 250 clients, separate File Server / Storage to the DCs, all roles on a single DC but GC on each DC, 80:20 rule on DHCP, keep DB services seperate and update services seperate.

 

I can't remember what else he said ... these are the only notes I made. TechRepublic have had similar suggestions ... but noone ever seems to leave things like this on their website.

 

One recommendation is to put in the bare minimum and then monitor the needs ... there are a few things that people say you should or should not do ... for Exchange places like Swinc.com help ... and when I was looking at FSMO roles recently this page was found to be helpful when I didn't have the Minasi books to hand.

[tosca925]

I class 300+ workstations and or 20+ servers as huge

 

Well.............whats that make us then with 760 clients and 14 severs?

[eejit]

I had a Microsoft Engineer remote into one of our DCs last week due to a failure and he did an audible gasp when he saw that one DC held all 5 roles and was the GC too. After a bit of a chat with him about best practices, this is what he recommended:

PDC - your most powerful DC

Infrastructure - not the same machine as the GC

other 3 roles location is not important.

Must only be one GC. the whole Global Catalogue thing is one that has always puzzled me as there are some websites that tell you that another GC is important, but others say you should only have one. The MS guy said that you should only have multiple GCs if you have a different physical network at another location (london/new york offices for example)

[sidewinder]

Hmm...I always make every DC a GC, purely for the reason if theres only one and it goes belly up you will then not be able to create new objects and apparantly (this is not something ive tested) no-one can log in apart from the domain admin .

Which isnt exactly fault tolerant, which is part of the point of having multiple DC's

[timbo343]

we have nearly 400 machines and 10 servers on our network, have 3 dcs and 2 of the fumos are on one dc and 3 are on the other. ive got RID PCD on one server and Infrastructure, schema and domain naming on another server

this seems to work fine for us

[eejit]

Hmm...I always make every DC a GC, purely for the reason if theres only one and it goes belly up you will then not be able to create new objects and apparantly (this is not something ive tested) no-one can log in apart from the domain admin .

Which isnt exactly fault tolerant, which is part of the point of having multiple DC's

 

I know that that definitely isn't right as our GC was down for a few days last year and none of the end users really noticed any problems on the network.

 

Multiple GCs on one physical local network will cause large amounts of unnescessary traffic as the GCs keep synchronizing. You may need more GCs in a large org with many exchange servers. One GC for every 4 Exchange servers.

[Geoff]

Logins still work with the GC down. You just can't add or delete objects in AD. For a small network, one GC is fine. Unless you have a split site.

[ChrisH]

You just can't add or delete objects in AD.

 

Im not sure that is neccesarily true as the GC holds a copy of all objects in the domain and a subset of other objects in a multi domain environment.

The behaviour you describe is probably as an indirect result of other mischief elswhere.

[Geoff]

I was describing what happens when the GC is down.

[Netman]

Redmond says:

 

General recommendations for FSMO placement

• Place the RID and PDC emulator roles on the same domain controller. Good communication from the PDC to the RID master is desirable as downlevel clients and applications target the PDC, making it a large consumer of RIDs. It is also easier to keep track of FSMO roles if you cluster them on fewer machines.

 

If the load on the primary FSMO load justifies a move, place the RID and primary domain controller emulator roles on separate domain controllers in the same domain and active directory site that are direct replication partners of each other.

• As a general rule, the infrastructure master should be located on a nonglobal catalog server that has a direct connection object to some global catalog in the forest, preferably in the same Active Directory site. Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold. Two exceptions to the "do not place the infrastructure master on a global catalog server" rule are: • Single domain forest:

 

In a forest that contains a single Active Directory domain, there are no phantoms, and so the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

• Multidomain forest where every domain controller in a domain holds the global catalog:

 

If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain.

 

• At the forest level, the schema master and domain naming master roles should be placed on the same domain controller as they are rarely used and should be tightly controlled. Additionally, the domain naming master FSMO should also be a global catalog server. Certain operations that use the domain naming master, such as creating grand-child domains, will fail if this is not the case.

 

Most importantly, confirm that all FSMO roles are available using one of the management consoles (such as Dsa.msc or Ntdsutil.exe).

 

More info here... http://support.microsoft.com/default.aspx?scid=kb;en-us;223346

 

In short.... if you only have one domain then don't worry about it too much... as long as you know what needs to be done if (when) your PDC goes walkies!!

[sidewinder]

OK, about the GC's

So it wouldnt be such a huge problem is everyone could still log in

But not being able to create objects is still a pretty big problem

 

How easy would it be if your GC went down, to promote another DC to it?

Would it be as easy as going into sites and services and making another one a GC?

[ChrisH]

Would it be as easy as going into sites and services and making another one a GC?

 

Yes It *should* be as easy as that.

[sidewinder]

Excellent

Ill do some testing and then maybe go back to one GC if all goes well

Anything to cut down on replication traffic is welcome

[HodgeHi]

If i have installed an additional DC into a single forest and single domain environment when i dcpromo the main dc will this then transfer the fsmo's or would i need to sieze the roles first. I ask this as i need to do this soon, and i have no room for downtime.

 

Will downing the first DC cause a problem of no one able to log in as i will need to re-install server 2003?

 

Sorry for jumping on this post but it came up just at the time i started thinking about this.

[ChrisH]

You should always try and do everything gracefully and transfer the roles nicely first.