|
<LOL> Good question John…looking for something to do I guess. No, seriously I’m thinking more in terms of what is best as we grow. There have been rumblings of putting servers (members, not DCs) in a lot of our field locations. Currently only a couple of them have a server. But as we go to 2003, we can use GC caching and maybe some other interesting features that weren’t available before.
Mostly I am interested in maintaining a best practice AD infrastructure. Our development teams are learning and adopting LDAP into their apps and it’s my responsibility to give them guidance as well as provide a stable structure for everyone to use.
Thanks for taking the time for such a detailed and informative response! The catch-all subnet is an especially interesting tip I hadn’t thought of before.
<mc> -----Original Message-----
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
|
- [ActiveDir] Site Replication Topology Creamer, Mark
- RE: [ActiveDir] Site Replication Topology Mulnick, Al
- RE: [ActiveDir] Site Replication Topology John Reijnders
- RE: [ActiveDir] Site Replication Topology Creamer, Mark
- RE: [ActiveDir] Site Replication Topology John Reijnders
- RE: [ActiveDir] Site Replication Topology Creamer, Mark
