Number of Domain Controllers needed?

Question

In the process of migrating 7 school site network from Server 2003/XP to Server 2012/7 and wanted to get some feedback on how many domain controllers would be optimal.

Currently we have 4 DCs. All 7 sites are connected by a 10 GB fibre link, so we are completely centralized (all servers are at the main office) We support roughly 1800 PCs/3000 users. We currently run exchange 2007 but will be migrating off to Office 365.

Thanks!

Solution 1

One DC should be able to handle the authentication load from that just fine. If you have all authentication traffic centralized at a single location, I'd start with just two and make both Global Catalogs (for redundancy) and only add more if you need it.

Solution 2

You only need one DC but it is by far preferred to have at least two DCs for redundancy. One or two DCs per geographical location will be fine.

With modern hardware, 3000 users shouldn't strain a DC. (Though Exchange can certainly pound a DC with ambiguous name resolutions.) Since you're well-connected to your remote sites, you could have your domain controllers all in one location, but I'd still recommend a DC at the remote locations in case the network connection goes down. (You could use RODCs at the remote locations, then you'd be a real IT pro!)

Solution 3

Before you get too wrapped up with how many DC's are needed and whether or not they're needed in remote locations, take a look at the bigger picture:

Are there local resources (Exchange, file and print, etc.) at each remote location that users need to authenticate to the domain in order to access?

If the answer is yes then it behooves you to place at least one DC in each remote location so that in the event that the network connection is down users will still be able to authenticate to the domain and access those local resources.

If the answer is no, then having a DC at each remote location is pointless as the users won't have access to the main office resources if the network is down. Being able to log on to the domain via the local DC does them no good. Users will be able to log on with cached domain credentials, possibly browse the internet (depending on the nature of the network problem and on which side it is occurring) but that's about it. So what good will having a local DC do?

Comments

[Zoredache]

My suggestions is that you start collecting performance metrics. Are the DCs idle? How is the memory/cpu/io stats? Once you have collected a baseline, try shutting one down. How is the load of the other DCs changed? The only way you can be 100% certain is if you have data. I believe you have more then you need, but only data can prove it.

[Greg Askew]

Along the lines of the baseline, may want to determine if you have periods of high activity. E.g., do half of the computers startup and logon between 7:30 and 9 AM? The period of highest activity could be a significant factor.

[R3b0rN]

Yes. That would be helpful to do. That is one other thing i want to address in the migration. Right now all the domain controllers do other tasks (file sharing, print sharing, etc.) It is hard to really see what is using resources. That being said... from casual observation, none of the DCs seem overwhelmed at any point of the day, and yes most logins for staff occur in the morining. Students login all day long.

[Pam K]

It should be noted that if you have a lot of Group Policy processing, having a domain controller at each end is helpful for speeding up the login process.

[hookenz]

A DC at each remote location makes perfect sense. Networks can and do go down and just a 1/2 day of downtime could be biggie! Not doing that would be asking for trouble.

[joeqwerty]

@Matt - I disagree. The OP states that "all servers are at the main office" and I'm assuming that means all of the servers that offer services to the clients (Exchange, file, print). Having a DC at each location to handle authentication is pointless if the network is down and the users can't access the resources at the main office that they actually need to use. If the network is down the users will log on with cached credentials and since they won't have access to anything they actually need anyway then having a local DC to handle authentication is moot.

[Ryan Ries]

There are other benefits to having a distributed DC design as well, such as handling logons and group policies on the same network instead of having thousands of users saturating those fancy 10Gb links with things like logging on and refreshing policy. I'm not saying that you have to have a DC at every site; of course you don't. But there are benefits that should be weighed in the design phase.

[R3b0rN]

I really do not want to have a DC at each site... even with RODCs. We are in the process of getting an MPLS setup configured, so the network down should not be an issue (in theory). And yes, EVERYTHING is at the main office. Only switching/routing is done at the site locations. All file/print/dhcp/dns/mail/authentication is done at the central site.

[R3b0rN]

I think that is what i will do :)

[Ryan Ries]

@user155929 Fair enough. Like I said, you don't have to. Just a consideration. Good luck!

[Bryan Mills]

@RyanRies Is AD really that network intensive?