Two important "tasks" that sites have to deal with is optimizing replication traffic on one hand and authentication traffic on the other. At the moment you have a couple hundred physical sites in terms of individual subnets. By default you start designing your site topology by doing a one-to-one mapping of the "subnets connected at LAN speed"-to-sites. Once you've got this structure in place you should look at the locations that really need a DC/GC to be present on-site. After having taken this step, the next decision to take is whether or not to "collapse" sites that do not contain a DC into a nearby site with a DC or to keep the one-on-one mapping.
 
Having a one-to-one mapping means that your infrastructure will contain a lot of sites that do not contain DCs, thereby causing DCs to register site coverage records in DNS. These records are published in DNS to make sure that clients that live inside "DC less" sites are able to locate a DC nearby. This could potentially lead to a a large number of site coverage records. You'll have to make sure your DNS infra can handle this. I've seen non-MS DNS infrastructures having trouble with handling huge amounts of service records. Just a little point of attention. In most cases this shouldn't be something you should worry about a lot.
 
Next aspect is the famous design guideline "keep IT simple". Now this is interesting food for thought, because ... what is simple? Is a consistent 1-to-1 mapping between sites and subnets simple or is a minimum number of sites simple? It's all a matter of taste. Both options can/will work! The best fit depends on your network topology. I've seen a lot of organizations preferring the "minimum number of sites" option. The main reason is for keeping the sites and sitelink structure as simple as possible. And it also forces the organization to think about the linking of subnets to the right sites. Especially in a spaghetti like network topology this could be an important aspect. However, I've also seen organizations with a "clean" hub and spoke topology to choose for the "homogeneous" solution. Meaning, that the would create a site for every hub and every spoke, even if no DC was placed in the hubs.
 
Another thing that is wise to do is to define a "catch-all" subnet that contains the complete IP space you have and couple it to a central - well connected site. This will help you direct "badly-defined" subnet/site structures within AD to get redirected to this site. It will not prevent clients to go to the nearest DC that is in it's own site in the case the subnet/site definition is well defined. The reason that the catch-all subnet will not interfer with a well defined subnet-site mapping is that the most nearest/specific match will be tried. So a "narrow" subnet coupled to a site will get preference over a "not so narrow" subnet that also contains the IP address of the client.
 
In your case, I'm curious why you're looking at redesigning your site structure? Are your faced with problems/challenges/whatever that force you to make a move from one model to another ... or is your infrastructure too stable and are you looking for a new challenge ;-)?
 
Cheers!
John


From: Creamer, Mark [mailto:[EMAIL PROTECTED]
Sent: dinsdag 18 november 2003 20:37
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Site Replication Topology

I’d like to revisit our site design, and am looking for some advice if possible. Right now we have a couple hundred physical sites in terms of individual IP subnets, but only a few sites defined in AD. The ones defined are the sites that actually have a domain controller located there. The greatest volume of traffic over our WAN is AS/400 emulation, so we have mostly slow links, 56-256K.

 

Reviewing Robbie’s book #1, I see he suggests a one-to-one site topology between sites defined in AD and physical sites where a subnet is located. Can I get an explanation why I would or might not want to set things up this way? My limited understanding of the sites was to associate the various subnets with a specific site, but I suspect there’s a lot more to it than that. Thanks!

 

Mark Creamer

 

Reply via email to