Basic guidelines can clear up the confusion
Planning and deploying Global Catalog (GC) servers can be confusing. Neglecting GC server placement when you make changes to Active Directory (AD), such as after you add a new domain or install Microsoft Exchange 2000 Server (or later), is easy to do. Although the Microsoft Knowledge Base, the Microsoft Windows Server 2003 Resource Kit, and the Microsoft Windows 2000 Server Resource Kit provide valuable information about the GC, that information is usually fragmented. Let's consider some simple guidelines for GC server placement in various scenarios and clarify some of the confusion that might arise as a result of changes to AD.
GCs contain all the objects in the forest but only some of those objects' attributes. The GC holds attributes that are commonly queried and are referred to as the partial attribute set. GCs make information about these objects available through Lightweight Directory Access Protocol (LDAP) and use replication to share this partial replica from each domain with all other GCs. GC queries can offer an advantage over domain controller (DC) queries in that DCs hold information about their own domains only, whereas GCs hold information about all domains in the forest.
Changing the Partial Attribute Set
You can use the procedure that follows to control which attributes the GC includes. You'll need the Microsoft Management Console (MMC) Schema snap-in, and you must register the snap-in before you can use it. To do so, open a command window and type
at the prompt. A pop-up message will let you know that the registration was successful.
As a further protection, the DC that holds the Flexible Single-Master Operation (FSMO) role requires a new registry value before you can write to the schema. The usual warnings concerning registry changes apply. Create the value Schema Update Allowed (of type REG_DWORD) with a data value of 1 in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry subkey. The change takes effect immediately without a reboot. When the updates are complete, disable schema updates on the DC by changing the data value to 0.
On your machine, open MMC and select Add/Remove Snap-in from the Console menu options. Open the Schema snap-in. If you're not logged on to the DC that holds the Schema Master FSMO role, right-click Active Directory Schema, choose Change Domain Controller, enter the name of the Schema Master FSMO role holder, and click OK. Then, in the right-hand pane, select the attribute in which you're interested and double-click to bring up the properties. On the General tab, which Figure 1 shows, select or clear the Replicate this attribute to the Global Catalog check box, as desired. This check box will be shaded unless the account you're using is a member of the Schema Administrators group. The default membership of this group is limited to the root domain's Administrator account. To avoid potentially catastrophic mistakes and improve security, keep the membership of the Schema Administrators group empty and populate it only when changes to the schema are required.
Don't change the defaults without good reason. Adding an attribute to the partial attribute set can have a significant replication impact on your network because of what is known as a GC full sync. Each GC reacts to an attribute's addition by using replication to fully refresh the read-only information it holds about other domains in the forest. The more domains you have in your forest, the greater the impact will be. Clearly, you don't want to make any changes to a partial attribute set in a production environment without careful scheduling. If you have a single-domain forest, you don't have to be concerned about the impact of the GC full sync because the GCs don't contain information about other domains and therefore don't replicate any additional information. Don't remove attributes from the GC without good reason; doing so can affect system efficiency.
Microsoft generally recommends that you use scripts to perform schema changes. This tactic avoids poor "mouse work" and lets you thoroughly test the change in a lab environment. Microsoft has modified the replication protocol to improve handling of the partial attribute set in Windows 2003, which no longer performs the GC full sync; Windows 2003 replicates only the added attribute.
Enabling GCs
Under AD Sites and Services, expand Sites. Select a site, expand it, and select a DC. Right-click NTDS Settings, and the General properties page will display a GC check box, which lets you enable (select) or disable (clear) the GC. Simply selecting the check box doesn't mean that the GC is now available and ready for use. Don't forget that replication still needs to take place. The Directory Services event log will contain event ID 1119 when replication is complete and the GC is available to service queries.
Determining GCs
You can use a variety of GUI, command-line, and scripting methods to determine which of your DCs are currently configured as GCs. In addition to the Sites and Services snap-in, you can also use Repadmin, a command-line tool in the Support Tools folder on the Win2K CD-ROM. To launch Repadmin, use the command
where domain_controller is the DC you want to query to determine whether it's a GC. The output will include the text DSA Options: IS_GC if the DC is a GC.
If you want a listing of all GCs in the forest, the simplest method is to use the Dsquery tool found in the %systemroot%\system32 folder. To launch Dsquery, use the command
You can run Dsquery on only Windows 2003 or Windows XP platforms. If you don't have access to Dsquery, you can use the Active Directory Replication Monitor (replmon.exe). After you launch the application, choose any of the DCs under Monitored Servers in the left pane. (You might need to add a DC first.) Right-click the DC and select Show Global Catalog Servers in Enterprise, as Figure 2 shows. In the Show Global Catalog Servers dialog box, which Figure 3 shows, select the DC and click OK. A new window, which displays the GCs, will give you the option to log the results to a text file. Identify the port that the GC listens on for LDAP queries. The GC uses port 3268/TCP for incoming LDAP queries and port 3269/TCP for LDAP Secure Sockets Layer (SSL) connections.
Placing the Infrastructure Master on a GC Server
Make sure that the DC that's holding the Infrastructure Master FSMO role isn't configured as a GC. To determine which DCs hold FSMO roles for a particular domain, I like to use Netdom, a command-line tool that you'll find in the Support Tools folder on the Win2K CD-ROM. To launch Netdom, use the command
Designating the Infrastructure Master as a GC isn't a good idea. The Infrastructure Master maintains references from objects in its own domain to objects in other domains. Group membership is an example of this scenario. A group in Domain A can contain members from Domain B. If one of the group members in Domain B is renamed, the updated information (i.e., the distinguished name—DN) somehow needs to be passed to the DCs in Domain A so that they can display the accurate group membership information. The Infrastructure Master holds records, known as phantoms, in its directory database that represent these objects from other domains. Periodically, the Infrastructure Master queries a nearby GC to determine whether any changes have been made to the objects for which it holds phantom records. If the Infrastructure Master detects changes, it will remove the old phantom and create a new record that contains the updated information. The Infrastructure Master then replicates the updates to the other DCs in the domain. Don't enable the Infrastructure Master as a GC because the GCs already have information about objects in other domains and therefore won't create the required phantom records. In other words, the Infrastructure Master won't be able to fulfill its role.
When you install your first AD DC, the system automatically configures it as a GC server. The system also assigns the first DC in the forest all five FSMO roles. This action appears to go against the rule for GCs and the Infrastructure Master role, but the rule has two important exceptions. If you have only one domain, the Infrastructure Master has no need to update object references to other domains because no other domains exist. The second exception occurs if all the DCs in a single domain in a multidomain forest are also GC servers, which means they're all up-to-date and don't need updates from the Infrastructure Master. In these scenarios, which DC holds the Infrastructure Master role isn't important.
Placing the Domain Naming Master on a GC Server
The Domain Naming Master FSMO role holder makes changes to the forest's domain namespace, such as when you add or delete a domain. When you create new domains, the Domain Naming Master must ensure that no other domain (or any other domain object) has the same name. It does so by checking the local (i.e., collocated) GC server. If the GC isn't local, the change will fail. To avoid this scenario, collocate the Schema Master FSMO role with the Domain Naming Master role holder.
One Site, At Least One GC
In native-mode domains, the GC plays an important role during user logon. The Key Distribution Center (KDC) on the authenticating DC will contact a GC to enumerate universal group membership and will add to the user's token the SIDs of the universal groups to which the user belongs. If a client can't contact a GC to access this universal group information, the logon will fail. The logon isn't required in mixed-mode domains because universal groups are enabled only in Win2K native mode. Windows 2003 removes the requirement for GC availability during logon by introducing universal group membership caching. The cache is populated at first logon, and subsequent logons use the cached information. DCs refresh the cache periodically from the nearest GC.
People sometimes ask whether each domain should have its own GC. Because all GCs in the forest hold the same information irrespective of domain, the answer is clearly no. Each AD site should have at least one GC, however. GCs are located through DNS SRV records. As a result, site-aware clients will contact "close" GCs (i.e., those within the same site) in preference to those in other sites. If no GC is available within a site, any queries will be directed to GCs in other sites that might be on the other end of a slow WAN link, which is clearly undesirable.
Should all DCs be configured as GCs? This approach has the advantage of ensuring maximum GC redundancy, as well as providing a simple solution to the Infrastructure Master FSMO role question. The downside is the performance hit to both the network and the DCs as a result of the increased replication traffic. Obviously, this performance overhead increases with the number of domains, DCs, and GCs. The trick is to strike a balance between achieving a good level of redundancy and reducing the performance overhead. In a single-domain environment, you should configure all GCs as DCs because there's no overhead in doing so.
You might argue that a single-domain environment doesn't need GCs because the DCs already contain all the information relating to objects in the forest. This statement might be true, but I recommend that you have GCs available to service applications that specifically look for a GC. Exchange 2000 is an obvious example of such an application. And client logons still require a GC (at least in Win2K AD) regardless of how many domains you have.
Deploying GCs for Exchange 2000
The GC requirements for Exchange 2000 have been covered elsewhere, particularly in "The Importance of the Global Catalog," February 2001, http://www.exchange
admin.com, InstantDoc ID 16374. The point I'd like to stress is that both Exchange 2000 and the Microsoft Outlook client make heavy use of the GC. Exchange 2000 references the GC for information about users, contacts, and distribution lists (DLs), as well as for essential configuration data. Without access to a GC, most Exchange operations won't function. The Outlook client requires access to a GC to perform Global Address List (GAL) lookups.
I strongly recommend that you have at least one GC available in every AD site in which an Exchange 2000 server is located. Another general recommendation is to add an additional GC for every four Exchange servers. Basically, if you want a reliable messaging network, have the available budget, and your network can cope with additional replication data, consider deploying a few more GCs.
Points to Remember
Although some hard and fast rules govern GC placement, ultimately you have a great deal of flexibility about how you deploy GC servers. Remember that each AD environment is unique and that what works for you might not be suitable for another organization.
Being overly enthusiastic with GC deployment has some disadvantages, such as increased network and DC performance hits, but being too miserly doesn't pay, either. Make sure that you have at least some redundancy, and remember that if you miscalculate, you can easily enable or disable GC servers on the fly.
The final and most important point is that GC placement is not a "fire-and-forget" activity. You'll need to regularly revisit placement decisions as your forest changes and evolves. Monitoring your DC and network infrastructure resources will help with this decision-making process.
