When you go through the Active Directory (AD) design process for your company, you quickly realize that the toughest job isn't designing the large, well-connected locations where most of the employees are. It's designing the fringes of your enterprise the satellite offices that have 10 to 100 employees sharing a slow WAN link. These branch offices are often your company's most direct interface with its customers. How do you get Windows Server services to these offices in a cost-effective manner? You might need some help deciding in which branch offices to create sites and place domain controllers (DCs) and Global Catalog (GC) servers.
The only way to keep your sanity during a branch-office AD design is to abide by a set of design principles. A well-defined set of principles makes the design process more logical and reproducible and gives you a way to defend yourself against a site manager who demands to know why his or her location didn't merit a DC. For the purposes of this article, a branch office, or small office, is a location that's connected to the rest of the organization by a WAN circuit with bandwidth of less than 11Mbps, has 400 or fewer users, and has only a few subnets.
Understand Your WAN
Before you start drawing circles around office locations, you need to do some homework. Microsoft defines an AD site as a collection of well-connected TCP/IP subnets. Typically, you design sites after you've settled on a design for your forests and domains. However, the first principle of branch office design is that the most important influence on a site topology is the physical network infrastructure rather than the domains that will be available at that location. Therefore, you must review and understand your company's LAN and WAN topology. Find out about the WAN circuits' bandwidth, reliability, latency, and congestion level. Learn whether the WAN design has failover capability, and if so, how it works. If you see parallels with Windows 2000 Server DNS setup, you aren't imagining things. Similarly to the way you need to work with your network engineering group to set up DNS for Win2K, you must consult with these folks to gather WAN information.
You also need a list of every IP subnet in your company. Inputting the subnets into the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in is a tedious task that someone must perform after you design and create sites. Someone also must be included in network engineering's subnet change process so that he or she can update the subnets in this snap-in if and when changes to the network's IP subnet configuration occur. Otherwise, whole groups of computers might fall out of the site topology, causing tens or hundreds of users to suffer significantly slower logon and response times.
Justifying a Site and DC
When you understand your WAN, you're ready to begin the branch-office design process. Start with the entire enterprise as one site, then look at each office location to decide whether to separate it from the main site. You make the decision based on a branch office's physical security and AD requirements, tempered by your hardware budget and IT management capabilities.
A key principle of branch office design is that you should place a DC in a branch office only when you can guarantee that the DC will be physically secure. The DC should be in a locked room to which only one or two employees have a key. Every DC contains the IDs and passwords of every employee in the company, from the CEO on down. If an unauthorized person gains physical access to a DC, he or she can bypass network security and extract crucial AD information. If you can't guarantee security at a branch office, don't land a DC there. This principle leads to another: If a location doesn't have a DC, it probably doesn't need a site. AD intersite replication is highly compressed to minimize WAN traffic, but if a branch office has no DC, you have nothing to replicate to.
For branch offices in which you can physically secure a DC, your next step is to perform a traffic analysis. Examine the network traffic that various server-and-client interactions generate so that you know the kind of domain services the offices need. DCs authenticate client computers, user accounts, and member servers so that they can log on to the domain. DCs can also host the GC, which both clients and servers query, host the Netlogon share for users' logon scripts, and act as database servers for applications that use AD data. The volume of these services is an important factor in determining whether an office should have its own site, its own DC, or its own GC.
An important goal of branch-office design is to minimize WAN traffic. If the branch-office users generate more WAN traffic by authenticating with DCs in other locations than a local branch-office DC would generate replicating with other DCs, put a check mark in the Land a DC column. According to Chapter 2, "Structural Planning for Branch Office Environments," in Active Directory Branch Office Deployment Guide (http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp), as few as 10 users can generate logon-authentication traffic that outpaces replication traffic.
Previous
Register
