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.
I'll use an example to illustrate the authentication and query requirements that a small-to-midsized branch office might have and how they affect branch-office design. Bigtex.net has one branch office in the town of Dripping Springs in the Texas Hill Country. That office is connected to the corporate office in Fort Worth by a 512Kbps WAN circuit. The company has one domain and 200 employees, 150 of whom are in Fort Worth. The branch office has a file and print server to service its 50 employees, who make sales calls.
If the Dripping Springs office has no DC and is part of another site, all authentications must go over the WAN circuit. How would this balance with AD replication traffic if a DC were on site? The entire company has only 200 employees, so the amount of AD traffic to replicate across the WAN is small. Traffic analysis favors landing a DC in the Dripping Springs office.
This example reveals another principle: Smaller companies with large branch offices more quickly get benefits from a branch office DC because authentication traffic will always outweigh replication traffic. A small company's WAN circuits are more likely to have smaller bandwidth than a larger company's WAN circuits for cost reasons, further tilting the balance toward local DCs for a small company with large branch offices.
In fact, placing a DC locally at a branch office has a lot of advantages. Replication traffic is more static and predictable than authentication traffic, which varies according to the time of day and number of users at the branch. Some network applications, whether onsite or offsite, require speedy access to the GC for example, Exchange 2000 Server needs access to the GC for email address lookups. Without an onsite DC, clients can't log on to the network and access resources even local resources if your WAN links are down (something to think about if your links are unreliable). With so many advantages to landing DCs at your branch offices, why wouldn't you choose this option?
I already mentioned one reason lack of physical security. The other big reason is cost. Companies typically have many more small offices than large offices. If a company has three main locations with 2 DCs each and 30 field sales offices across the country, landing a DC in each field sales office increases the DC population from 6 to 36, a 600 percent increase in the hardware cost of your AD infrastructure. The hardware increase is accompanied by equal increases in support-contract costs.
Another reason is management. You've increased the number of sites, site links, and especially subnets that you must maintain from 3 to 33 an 1100 percent increase. You have six times as many DCs to secure physically. How will you manage all these DCs? Administrative access to a DC requires administrative rights to the domain. Are you willing to grant one or two people in every field sales office administrative rights to the entire domain? Let's hope not! Are you going to manage the DCs remotely, then? What will you do if a DC's network card has a problem?
These are all strong arguments for a Keep It Simple, Stupid (KISS) approach and Sean's Maxim of Minimum: Just because you can, doesn't mean you should. AD is powerful, with thousands of individual settings. Unless you have a specific reason to make your site topology more complicated and are willing to keep track of those complications leave it alone.
Figure 1 summarizes much of the DC placement decision process and the different aspects of the process. If you can guarantee that a potential DC would be physically safe in a location (security analysis), you then need to determine whether the location really needs a DC (traffic analysis). If your company has multiple locations in the same mold as the sample office, they probably need the same configuration as this office, and you next must determine whether you can afford a DC for each of the similar offices (cost analysis). Note that costs include hardware, vendor support, and management costs. If the costs are acceptable, place the DCs according to your traffic-analysis results. If the costs are too high, review your analysis to see whether some smaller locations can do without DCs. If you can't stretch your DC budget any thinner without compromising performance or fault tolerance, you need to revisit the budget or begin planning now for trouble in the future.
Another alternative to landing a DC and GC at every branch office is to investigate upgrading the WAN circuits to some of the branch offices. An upgraded WAN circuit to a site might be a more cost-effective approach than landing a DC.
When to Land a GC
Now that you have your DCs in place, you must decide which DCs should host the GC. As when you analyzed the DC traffic, think about the functions the GC performs. First, in a native-mode domain, the GC contains the universal groups. Second, the GC provides a forestwide set of AD objects. So, who needs these services?
The first function storing universal groups affects everyone who logs on to the domain. When a user logs on, the Netlogon service creates his or her access token, which among other things contains the user's group memberships. Because only the GC stores universal groups, Netlogon contacts it as part of the logon process to enumerate the user's universal group membership. By default, if a user can't access a GC server, he or she can't log on. You can get around this restriction with a registry change in Win2K (a security breach) or by using Windows 2003's universal group caching feature. At a user's first logon at a site that has universal group caching turned on, Windows 2003 DCs at that site will cache your universal group membership and refresh it periodically from GCs at another site.
The second function serving as a forestwide AD reference has by far the biggest impact on GC server placement. Messaging applications (i.e., Exchange 2000 and later on the server and Microsoft Outlook on the client) are the heaviest users of the GC. Windows 2003 and Win2K store email addresses as attributes of AD user objects, and Exchange 2000 and later servers and Outlook clients use the GC for name-to-email-address translation; which platform performs more lookups depends on the Outlook version. (For more information about Exchange 2000 and the GC, see "The Importance of the Global Catalog," February 2001, InstantDoc ID 16374.) Universal group caching doesn't help when it comes to messaging because email users aren't looking up universal groups they need email address attributes from the GC. If you have Exchange 2000 or later users at a branch office with a DC, strongly consider making that DC a GC server, or the users will need to go over the WAN to look up email addresses. If you have an Exchange 2000 or later server on site, you must have at least one GC server on site. I would argue that if you've deployed Exchange 2000 or later throughout your enterprise, all your DCs should also be GCs.
As you'd expect, having a lot of GC servers in your enterprise can have consequences. The GC contains all the objects in the forest, but because objects from the local domain partition don't have duplicates in the GC, its size varies from domain to domain. If your company is international, you probably have fewer employees and thus smaller domains in foreign countries. If your domains are of very different sizes, the GC on a DC in a small domain will be proportionately larger than the GC on a DC in the largest domain. Therefore, GC replication in small domains will have a much larger impact than in large domains. To compound the problem, WAN circuits in smaller domains tend to be of lower bandwidth than those in larger domains, and the increased replication will affect them more.
Another factor that will affect your GC activity is the number and size of your universal groups. Because universal groups live in the GC, Windows replicates any changes to them to GC servers across the entire forest. Win2K stores a universal group as a single multivalued attribute, so if the universal group membership changes, Win2K replicates the entire group. If you have large or active universal groups (e.g., groups that serve as Exchange 2000 distribution lists DLs), the GC will be the largest component of your AD replication. This behavior has been changed in Windows 2003, which replicates only the membership changes to a universal group, not the entire group.
Other Considerations
Earlier, I wrote, "If a location doesn't have a DC, it probably doesn't need a site." I said "probably" because there's one exception. If you've deployed a site-aware application such as DFS, you might need to create sites for your branch offices that don't have DCs because clients using such applications first attempt to find a host server in their site. For example, suppose you deploy DFS (e.g., for software distribution) in several branch offices that are part of a larger AD site. Windows clients looking for a DFS server could end up trying to connect to a server on the other end of a 256Kbps WAN circuit, even when a DFS server exists at the branch office. The solution is to create a site for each branch office. Any local DFS server will become part of that office's new site, local users will select that server first for DFS access, and the AD site coverage feature will ensure that nearby offsite DCs will authenticate the branch office's users. (Remember that this feature requires you to register your IP subnets to a site. Clients on an unregistered subnet end up in the Default-First-Site-Name site, which probably doesn't have any DCs. The clients must then perform a domainwide DC location search and probably won't choose the closest DC.)
If you're landing a combined DC and GC server locally, another infrastructure service that should be on it is AD-integrated DNS. This service is highly efficient, contributes little overhead to the DC or to replication, and is constantly used by clients.
Windows 2003 Changes
Windows 2003 makes branch-office deployment and management easier, thanks to several new features. Dcpromo now lets you promote from media, so you can create a new DC without being forced to replicate a large AD and GC database over a small-bandwidth WAN circuit. Simply copy a highly compressed backup of another Windows 2003 DC's system state to the local server, restore it to a temporary location, type
dcpromo /adv
at a command prompt, and restore the system state from the temporary location. (For more information about promoting from media, see "Windows 2003 Dcpromo," September 2003, InstantDoc ID 39767.)
Remote Desktop, which provides terminal services in Windows 2003, offers the ability to connect to the system console (session 0) with the /c option, so you can truly see what you'd see if you were standing in front of the server. And if you have a lot of sites or are contemplating a large DFS implementation, Windows 2003 handles large numbers of sites more gracefully than Win2K does. Windows 2003's Intersite Topology Generator (ISTG) and Knowledge Consistency Checker (KCC) improvements let the largest branch office deployments proceed without any restrictions from AD.
In this article, I've assumed a simple situation with only one domain because a branch office's users are usually in the same domain unlike large offices, which often have multiple domains. However, if one of your branch offices has users in more than one domain, you must analyze the location's requirements separately for each domain.
No article about branch-office deployment would be complete without a reference to Microsoft's Windows 2000 and Windows 2003 guides for the subject. The aforementioned Active Directory Branch Office Deployment Guide is the original, thorough reference on branch office deployment for Win2K. The draft document I have of the Windows 2003 guide has the same name. I also highly recommend the Microsoft Windows Server 2003 Deployment Kit (http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx), even if you don't plan to deploy Windows 2003 in the near future. This exhaustive (4000-page) treatise benefits from Microsoft's 3 years of experience with Win2K. Pay special attention to the deployment kit's Designing and Deploying Directory and Security Services book. Branch-office deployment can be much trickier than large-office deployment, but the guidelines I've presented and the two Microsoft resources can make you an expert.
