One of the frequent issues we see when supporting Small to Medium businesses (SMB) is replication issues caused by problems with physical Active Directory design. When I say “physical design” I don’t mean forests, tree roots, domains, child domains, etc. Those are elements of logical design. Physical design, in a nutshell, is how you configure the various elements in Active Directory Sites & Services. When these elements work harmoniously, Active Directory will reward you with fast & efficient replication. If mistakes are made, they’ll be compounded by the amount of replication traffic and at worst (typically in coordination with some other misconfiguration) can bring replication grinding to a halt. So let’s go over physical Active Directory design at a basic level.
The first rule of physical design is “You do not talk about Fight Club.” Wait a minute……wrong topic; my mistake. The first rule of physical design is to let the network be your guide. Use your organization’s network topology to help in creating the 3 main elements of physical design: the site, the subnet, and the site link. Let’s stop and talk about these for a minute.
Subnets: These correspond to – you guessed it – the network subnets for your organization. A subnet is defined and then assigned to a site in Active Directory Sites & Services. This action configures all clients in that subnet to authenticate to a domain controller in the associated site. Since by definition (see the next section on Sites) a site is a group of well-connected computers, this ensures fast and efficient directory services for all. Staying on top of defining subnets means keeping in regular communication with your organization’s network team OR catching them red-handed by occasionally perusing netlogon.log on the DC’s. This second “red-handed” option is good fun when you have spare time and want the network team to think you’re spying on them. Netlogon.log is a log file on each domain controller that among other things reports clients from undefined subnets attempting to authenticate with the DC and the corresponding IP address for said client. You can then take this information to your friendly local network engineer to ask them where this particular subnet resides. Extra credit if you deliver the question with a bemused-yet-accusatory delivery.
Sites: A site is an area of “well-connected” computers. Seem a little….ambiguous? It is. Defining sites is part art, part science. A good rule of thumb for the whole well-connected criterion is “Do or do not: there is no try.”…..Wait, that’s Yoda from Empire Strikes back; not my day for analogies. One way to approach defining sites is if an area (floor/building/buildings plural) is LAN-connected then it’s probably a site. Once traffic is routed over a WAN this likely defines the end of one site and the beginning of another. This is not a hard-and-fast rule, mind you, but more of a guideline to help you zero in on what well-connected means for your organization. To give some examples: If each branch office is connected by vpn, then each office should probably have its own site. If each office in the same town is connected by fast connections, they might be considered to be in one site, and the offices in the next town would be another site. I’ve even grouped cities in the same region as a single-site before, so it all depends on connectivity and routing. By this point, I think you’re picking up what I’m puttin’ down.
Site-Links: Site links are the oft-forgotten piece that completes the physical topology puzzle. Site links let YOU the administrator/engineer/architect/grand-poobah-of-AD dictate the general flow of replication. There are a few different ways to set this up, but the tried-and-true rule of thumb is “time to make the donuts.” Dang it – why do I completely suck at catch phrases today??!!! Moving on…The default, go-to physical AD topology is called spoke-hub. This works for most organizations since there is typically one main office or datacenter, and everything else is essentially a branch off of that. This is particularly true in the SMB space. More on that later.
Having introduced all the players, one thing we see all too often in support is 15 defined sites, 52 defined subnets, (2/3 of the pieces in place and you’re nearly there)…..and 1 measly site link (ugh, so close). Odds are there would be a grand total of no site links but for Microsoft’s foresight in creating a default site link for us. By default then, without additional site links defined all sites are members in this default site link. The result is a grid topology where all sites have to replicate with all other sites. Does that seem efficient? (Jeopardy theme song plays…..) you’re right; it isn’t. Imagine having to tell everyone all the way up the chain of management right up to the CEO of your company every time you left your desk. Every bathroom break, cup of coffee, lunch, all of these things would need to be passed by your manager, the director, the VP, the President, and finally the CEO. From a communication perspective this is overkill, to say the least. That pretty much illustrates a grid topology. Unless the previous example sounds like a bang-up way to configure your AD replication, I recommend a spoke-hub topology. Spoke-hub is where the main datacenter/central office acts as the hub and the rest of the branches are individual spokes. Each branch replicates directly to the hub, which in turn takes care of replication to the other branches.
But doesn’t this create a single point of failure? In a word, no. AD has some default configurations in place such that if all DC’s in the hub go down, and there’s physical network connectivity between the branches, a branch can and will still replicate to another branch in times of emergency. We can thank Microsoft for that helpful bit of code. One thing, however, that you should consider when it comes to spoke-hub is you may want to allocate your beefier server hardware, or possibly an extra DC or two, to the hub site since it’s doing a little more work than the rest.
Point made, so how’s this done? Here’s the A-B-C of it:
- Define all of the sites: The decision-making process is easier said than done, but goes back to defining little islands of well-connectedness into sites. Once that decision is made, however, actually creating a site, is as easy as following the wizard.
- Define all of the subnets & assign subnets to the site in which they reside: To check for undefined subnets, crack open c:\windows\debug\netlogon.log and prepare to creep out your network engineer. Here’s a screenshot of creating a subnet and assigning to a site called “Site2.”
- Create a site link for each branch: The members of each site link should be the branch site itself and the hub site.
- Check the Default Site Link to ensure it isn’t a grid setup that could override all of your hard work. It would look like the following.
You can also rename and repurpose the Default Site link as one of the Branch-to-Hub site links.
- Sit back and watch the replication fly.
Hope you find this useful, and good luck setting up your physical topology.