The Importance of the Global Catalog

GC placement and AD replication planning are crucial

By now, you probably know that the Global Catalog (GC) server is important to Exchange 2000 Server. The GC is a special form of a Windows 2000 domain controller (DC) that holds a complete set of objects (i.e., user accounts, contacts, distribution groups, and configuration data) from all domains in a Win2K forest. The GC stores read-only partial copies of objects from other domains alongside read/write full copies of objects from the GC's home domain. Partial copies include the important attributes of an Exchange mailbox (e.g., email address, phone numbers) but not all the mailbox attributes. In a single-domain implementation, all DCs are effectively GCs, but single-domain implementations are unusual in large, distributed enterprises. GCs come into their own in large enterprises.

Users, contacts, and distribution groups are obviously important to Exchange 2000, but the configuration data that the GC holds is equally vital. Exchange maintains a separate configuration container to store information about servers, administrative groups, routing groups, and other organizational data such as connectors. Unless a messaging system knows how to route messages between servers, across connectors, and to the outside world, you can't expect a messaging system to function properly. Therefore, you can see that the GC plays an important role in message routing. If Active Directory (AD) replication fails or is inconsistent, errors can creep into routing information and thus prevent messages from making their way to users. For example, if you create a new routing group and move some servers into the new group, that information must be published through AD replication before Exchange can route messages to mailboxes on those servers. Exchange 2000's SMTP routing engine ensures that routing decisions are as accurate as possible by referencing the GC when it categorizes messages to decide which route messages should follow.

Performance affects routing as much as replication problems affect routing. A busy Exchange server--one that supports many hundreds or thousands of active users--generates a substantial load for the GC as it responds to the requests from the routing engine. A local in-memory cache on the Exchange server can handle many of these requests, but Exchange must refer to the GC any lookup against a user, contact, or group that isn't in the cache. Therefore, Exchange 2000 servers must have access to GCs that can handle this load. One rule of thumb is to locate a GC near every Exchange 2000 server and to add an extra GC for every four Exchange 2000 servers. In this context, near every Exchange 2000 server means that the GC is on the same LAN. However, if you have a robust WAN environment, you can direct lookup traffic across the WAN to a GC in another location. (If firewalls protect part of the WAN, port 3268 must be open to allow the GC lookups.) You can justify this design decision when you want to place an Exchange server to support a small number of users (50 to 100 mailboxes) and don't want the expense of installing an extra GC.

Robust is the important word here. If the WAN connection between the Exchange 2000 server and the GC becomes unavailable, routing and many other operations stop dead. Management operations are also impossible because the Microsoft Management Console (MMC) Exchange System Manager or Active Directory Users and Computers snap-ins that you use for server and user management must connect to a GC (or a DC, in the case of AD management) to perform even simple tasks such as checking server status. Losing a connection to a GC can also require server reboots.

Unlike in Exchange Server 5.5, in Exchange 2000 the Message Transfer Agent (MTA) doesn't participate in routing decisions. However, the MTA still processes messages that Exchange must deliver to legacy Exchange servers or to other X.400 messaging systems. Microsoft made a late change in Exchange 2000 development to force the MTA to shut down if Exchange loses contact with a GC. The logic behind this decision was to stop processing to eliminate the possibility of losing any messages. Unfortunately, sometimes the MTA doesn't shut down cleanly and it hangs. The only resolution is to reboot the server--certainly not an optimal process in a situation in which the GC might come back online after a temporary network problem. Microsoft knows about the problem and is working on a fix, but the word is that the fix might require substantial work deep in the code that controls access to the GC. Therefore, the fix is unlikely to be in Service Pack 1 (SP1).

Being conservative about GC placement within your Win2K design and installing more GCs than you think are necessary can prevent your running into the problems with routing, management, and the MTA that I describe here. This approach has another major benefit: Clients depend on GCs for access to the Global Adress List (GAL), so if they can't contact a GC, clients can't validate addresses in email headers, browse the GAL, or check properties of other users or distribution groups. Indeed, the sudden disappearance of a GC affects any client currently connected to that GC and forces users to restart their client. If a GC is unavailable after the client restarts, you can't connect to your mailbox and the Help desk's phones will start ringing. The next release of Microsoft Outlook, due in mid-2001 as part of the next major version of the Microsoft Office suite, attempts to do a better job of detecting GC disconnects, but Outlook can't do anything if a GC isn't available as a result of network problems.

These problems aren't surprising. No one pretended that you could just replace the integrated directory that Exchange Server 5.5 uses with AD. Just as you had to learn to work with Exchange's older directory in versions 4.0 through 5.5, you're now in the learning curve for Exchange 2000. The best advice at this stage is to be cautious about GC placement. Think through the consequences of network failure before you decide where to put GCs. Also, pay attention to AD replication to ensure that AD publishes configuration data as quickly as possible to all GCs in the forest. These precautions will help keep messages flowing through your Exchange 2000 servers.