Hello. I am planning an AD design (on my head at least). I have a DataCenter called DataCenter1. I have 3 offices: Office1 (500 users) (200Mb line to DataCenter1) / Office2 (200 users) (80Mb line to DataCenter1) / Office3 (200 users) (80Mb line to DataCenter1) My plan is to have all the Domain Controllers located in the DataCenters as the bandwidth (from my knowledge) is more than enough to cope with this. 1: Would there be any reason at all to consider additional Domain Controllers in the office locations (RODC's). 2: If I only locate Domain Controllers in the DataCenter then can I get away with one AD site (as opposed to a site per physical office).

Hi Bryan, The bandwidth is reasonable, but if you use Exchange - or any other application that makes use of global catalog servers, you'd still be wise to put at least one domain controller that's been marked as a global catalog at each site. I'd likely even put two at the 500 user site depending on your high availability (HA)/service level agreement (SLA) requirements (if there even are any). Personally, I'd put at least one at the Office1 site even if there aren't any HA/SLA obligations solely for performance reasons, but then we are using both Exchange and Lync, meaning we have ongoing medium quantity GC chatter. There's no categoric right or wrong here on the quantity of domain controllers, but you definitely should not use one site definition to cover them all as any outage to any of those links could wreak performance havoc (in user terms, as they'll complain about any kind of delay) as the clients will technically look for any domain controller you have. Instead, you should define separate sites and set the replication intervals to the minimum (15 minutes from memory). As an example, if you only create one site, then users in any office can be trying to log on via the domain controllers in any other office. So, if you then had an outage - let's say in Office3, that outage will still potentially have an impact on users in offices 1 and 2. This all assumes you place at least one domain controller locally. Even if you still choose not to do that, you should still create separate sites. The domain controllers will provide automatic coverage for those sites (though I prefer to maintain our list manually). Cheers, Lain

Hi Bryan, The bandwidth is reasonable, but if you use Exchange - or any other application that makes use of global catalog servers, you'd still be wise to put at least one domain controller that's been marked as a global catalog at each site. I'd likely even put two at the 500 user site depending on your high availability (HA)/service level agreement (SLA) requirements (if there even are any). Personally, I'd put at least one at the Office1 site even if there aren't any HA/SLA obligations solely for performance reasons, but then we are using both Exchange and Lync, meaning we have ongoing medium quantity GC chatter. There's no categoric right or wrong here on the quantity of domain controllers, but you definitely should not use one site definition to cover them all as any outage to any of those links could wreak performance havoc (in user terms, as they'll complain about any kind of delay) as the clients will technically look for any domain controller you have. Instead, you should define separate sites and set the replication intervals to the minimum (15 minutes from memory). As an example, if you only create one site, then users in any office can be trying to log on via the domain controllers in any other office. So, if you then had an outage - let's say in Office3, that outage will still potentially have an impact on users in offices 1 and 2. This all assumes you place at least one domain controller locally. Even if you still choose not to do that, you should still create separate sites. The domain controllers will provide automatic coverage for those sites (though I prefer to maintain our list manually). Cheers, Lain

Thanks for the reply Lain. If those bandwidth figures were increased - lets say doubled, would it then be ok to have DCs only in DataCenter. The reason for this is that the intention would be to have the DataCenter hosting every server in the future with nothing except clients in the offices. Exchange will be used with the plan being again that the DCs in the DataCenter would act as GCs

Hi Bryan, It's not so much a question of speed but availability. Actually, for the 500 user site, it's still potentially going to be about speed - particularly as you're factoring Exchange into the equation, where decisions such as whether or not to use offline cached mode and so on may have not yet been decided upon. The short answer is this: you could likely get away with the links you already have from a raw performance perspective (depends on what else is traversing the pipes), but from an availability perspective, I wouldn't recommend this model unless the business is willing to sign off on accepting the risk involved. Again, this also has not impact on what I said about the sites. You should still create individual sites for each of the three offices irrespective of the final domain controller topology. Cheers, Lain

Hi, Regarding the general recommendations for the design, deployment and management of an Active Directory environment, I suggest wed better refer to the following articles. They provide us the good guidance for AD design. Infrastructure Planning and Design http://technet.microsoft.com/en-us/library/cc196387.aspx AD DS Design Guide http://technet.microsoft.com/en-us/library/cc754678(v=ws.10).aspx Best Practice Active Directory Design for Managing Windows Networks http://technet.microsoft.com/en-us/library/bb727085.aspx Active Directory Design Guide http://www.microsoft.com/en-us/download/details.aspx?id=8133 Regards, Andy

Ok. but in terms of availability, let's say I had a second data center and used this for HA and DR, would this then be ok? again, my intention would be to eliminate the need for any servers in the offices. understand where you are coming from with the sites. the question is that should the data centers also be treated as sites? thanks again.

Ideally, yes. The fact that each of your offices are on the other side of a WAN link(s) means it really should be defined as being a separate site. It's better to start our with the "correct" approach and expand out later than to start with the "incorrect" approach and then have to re-architect the site topology if you do indeed end up with a requirement to do so. I am using those terms loosely. In short, you'd get the benefit of future proofing from defining them correctly with no drawbacks were you to indeed locate all your domain controllers exclusively in the data centre. Edited to add this one link as I just re-read your previous post and realised you now raised the concept of using a secondary data centre for HA and/or DR. This model needs to be planned carefully depending on whether it's DR or HA you're stiving for and should still use separate site definitions. If it's being used as a DR site, then you'd need to ensure the site link cost from each of the client sites to the DR site is higher than to the primary site. If it's more geared towards HA (and you're using identical hardware and WAN links, etc), then keep them the same cost. Cheers, Lain

just a last thought. in cases where businesses have moved their AD to a hosted cloud they obviosuly wouldn't have domain controllers remaining in their offices?

If they've moved completely to an IaaS model, then you are correct; they won't have anything in their branches. However, this is a business decision made at the executive level, not an IT decision, as the business has to figure out what kind of SLA structure they are happy with. This is a very big leap of faith to make, and I've seen and heard about some incredibly short-sighted moves here in Australia that have spelt disaster (measured in either cost or productivity - which ends up being the same thing) for the business on account of the poor connections we have to Singapore and Hong Kong. Part of that has come from the business not truly understanding the risks involved and the changes to their SLAs (i.e. what they can actually do about it when they're not happy with the service). I wouldn't use the fact that it can be done as the sole reason to do it. There's so much more to it than that. I work in the education sector, and all I can say is I'm glad we haven't moved to the cloud for our staff or core infrastructure services and applications. Some of the stories I've heard - and still hear, about places that have are shocking and clearly show the business wasn't aware of what the repurcussions might have been. Some of them are even pulling services back internally. Cheers, Lain

.

thanks again Lain. Fron your answer about IaaS. If a business moved to this model, surely then this would negate their need for AD sites as their branches would no longer have domain controllers. A site without a domain controller is impractical. So if a company moved to an IaaS model in a data center surely it would be a one-site topology. Even in the event of two data centers (primary and disaster recovery centers) this would likely still be treated as one active directory site, or what would be the benefit here of treating two centers as two sites.