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.
Register
