Step B3: Determine Global Catalog Placement
Published: February 25, 2008
Global catalog services facilitate the lookup of information to all domains in the forest, specifically to domains outside of the current domain. The catalog is a subset of information from each domain that is replicated to every global catalog server in the forest. Applications such as Exchange Server rely heavily on the global catalog for relevant information. The global catalog is also used during the logon process to enumerate universal group memberships.
All global catalog services physically reside on one or more domain controllers. There is no way to separate global catalog functionality from a domain controller.
The decision needs to be made as to which domain controllers in the forest will host global catalog services.
Task 1: Determine Global Catalog Locations and Counts
If a forest consists of only one domain, then all domain controllers should be configured as global catalog servers. The subset of data that would be replicated to all global catalogs will already be replicated through the normal domain replication process. There will be no additional requirements for disk space usage, CPU usage, or replication traffic.
If a forest contains multiple domains, then typically each domain controller should not be a global catalog server because of the increase in storage requirements and the additional replication overhead.
In a multi-domain forest environment, a subset of the domain controllers in the environment will be configured to run as global catalog servers. Because all global catalogs replicate a subset of all objects in each domain, placement of the global catalog needs to be carefully considered with respect to the increased bandwidth overhead introduced by the additional traffic. In addition, there are increased hardware requirements for storing global catalog data. Figure 3 illustrates the decision tree flow for deciding where to place global catalogs in the environment.
Figure 3. Decision tree flow for placement of global catalog servers in the environment
Are There Any Applications That Need a Global Catalog Server Running at the Location?
Certain applications, such as Exchange Server, Microsoft Message Queuing (MSMQ), and applications that use distributed COM (DCOM), rely heavily on global catalog servers. These applications tend to perform better when they have a local global catalog available to improve query times.
There may be some application restrictions around whether a RODC can be used as a global catalog. Exchange Server does not support global catalogs running on an RODC; however, Microsoft Outlook® messaging and collaboration clients can use an RODC global catalog for Address Book lookups.
Is the Number of Users at the Location Greater Than 100?
Global catalog servers should be placed at any location that has more than 100 users in order to reduce WAN traffic and to prevent productivity loss in case of WAN link failures.
Is the WAN Link 100 Percent Available?
Consider placing a global catalog server in a location in which the WAN link is not sufficiently reliable to ensure user authentication, or else configure universal group membership caching.
Do Many Roaming Users Work at the Location?
Roaming users need to contact a global catalog server whenever they log on for the first time at any location. Therefore, a global catalog server should be placed at locations that include many roaming users. Often, too many logons over the WAN link can cause significant WAN traffic and cause performance degradation and production loss.
Can Universal Group Membership Caching Suffice?
Universal group membership caching is an option for locations that include fewer than 100 users and do not include many roaming users or applications that require a global catalog server. Universal group membership caching can be enabled on domain controllers that are running Windows Server 2003 or Windows Server 2008.
When a user logs on to the network, the global catalog server is contacted to enumerate universal group membership for that user. Over slow links, this process can take a significant amount of time or, in the event of a failure to contact the global catalog server, can result in denial in the logon process. Universal group membership caching can be used to address this problem. Universal group membership caching is available by default on domain controllers that are running Windows Server 2003 or Windows Server 2008. The feature must be enabled on a per-site basis.
How Many Global Catalogs?
Once it has been determined that global catalog servers are required in a location, the next question is how many global catalog servers are required. In most cases, one or two global catalog servers will suffice in each location. Application requirements, such as Exchange Server requirements, may increase the number of global catalog servers required.
Record which domain controllers will be configured as global catalogs.
Validating with the Business
In addition to evaluating the decision in this step against IT-related criteria, the effect of the decision on the business should also be validated. The following question has been known to affect global catalog placement decisions:
Configure domain controllers as global catalog servers only when there is a technical reason to do so. Exceptions may be made when a population of traveling users requires high-performance global catalog services in sites outside the users’ domains.
Keep the number of global catalog servers to a minimum to reduce cost, management, and complexity of configuration and maintenance.
The design of the global catalog servers must be repeated for every forest.
“Planning Domain Controller Placement” at https://technet2.microsoft.com/windowsserver/en/library/c0834916-4166-4f81-894a-acd1276f8c6d1033.mspx?mfr=true