MAPI Client Directory Access in Exchange 2000

Understanding how Exchange uses Global Catalog servers

As you know by now, Exchange 2000 Server has a huge dependency on Active Directory (AD). Exchange Server 5.5 has its own built-in Directory Service (DS) for storing mailbox attributes and other information, but the DS must coexist with the Windows NT 4.0 SAM database, which provides the security principals that let you set permissions on DS objects. Exchange 2000 discards the built-in DS in favor of using AD to hold user accounts (security principals) and mailbox attributes.

The way in which Exchange 2000 uses AD affects the correct placement of the Global Catalog (GC) servers, which provide a complete view of an organization's address book. In the Exchange 5.5 world, the DS is always on the same system as the message store. As a result, you have no deployment considerations for the DS. However, with Exchange 2000 you must decide on the relative positioning of Exchange 2000 servers and AD servers. Let's look at how Exchange 2000 Messaging API (MAPI) clients and servers use AD and the implications for designing your messaging network.

GC Servers
GC servers provide a partial attribute list of all objects from all domains within a forest and full information about every object in the GC's domain. Specifically, the GC holds the appropriate information for users, groups, and contacts that's relevant to Exchange 2000 and MAPI clients such as Microsoft Outlook. This information makes up the Global Address List (GAL). Access to the GAL is available only from a GC, not from a domain controller (DC), which typically holds only a subset of the GAL information. (The exception is a single-domain forest, in which effectively all DCs hold the same information as a GC.)

Although you can access GAL information from GCs over Lightweight Directory Access Protocol (LDAP) for IMAP, POP, and HTTP clients on port 3268, MAPI clients don't use this mechanism. MAPI uses the Name Service Provider Interface (NSPI) on a dynamically assigned port higher than 1024 to perform client-directory lookup. (The Microsoft article "XCLN: Exchange 2000 Static Port Mappings" at http://support.microsoft.com/support/kb/articles/q270/8/36.asp provides information about how to lock down NSPI to a specific port number.) NSPI is available only on GCs, never on DCs.

By default, only one GC is available in a forest. However, having multiple GCs—and thus eliminating a single point of failure—is good practice. (I discuss the placement of GCs relative to Exchange 2000 servers and clients later in this article.) To provide multiple GCs, you must create new DCs, then promote them to GCs. You create DCs by running Dcpromo against a Windows 2000 member server. To promote DCs to GCs, open the Microsoft Management Console (MMC) Active Directory Sites and Computers snap-in, then navigate to the server you want to promote. Select the Global Catalog check box on the NTDS Settings tab of the server's Properties dialog box. However, to activate NSPI, you must reboot the newly created GC. Now that I've described the requirements for client access to GCs, let's take a look at how Exchange 2000 implements access to GC information.

DSAccess and DSProxy
DSAccess (instantiated as dsaccess.dll) is an Exchange 2000 server component that provides an in-memory volatile cache of up to 50MB of directory data. This directory data relates to user mailbox information that Exchange 2000 server components, including the Store and the Message Categorizer, have recently accessed. Exchange doesn't use the cache for client-initiated GAL lookups. Among other tasks, DSAccess keeps a list of available, unavailable, and slow DCs and GCs. The sidebar "How DSAccess Builds the List of Cached Servers" describes how Exchange creates this list, and the sidebar "Using DSADiag to Display the DSAccess Cached Servers List" describes how you can use the DSADiag utility to view the list of cached servers that DSAccess holds.

The DSProxy component (instantiated as dsproxy.dll) is an Exchange component that lets MAPI clients communicate with AD for directory lookups. DSProxy uses the cached list of GC servers (with GCs from remote domains filtered out) that DSAccess maintains and either performs directory lookups to GCs on behalf of MAPI clients or refers certain MAPI clients directly to GCs to perform their own lookups. DSAccess updates the list of servers that DSProxy maintains as the state of servers in its cached list changes. If you want to monitor the list of GCs that DSProxy is using for either proxies or referrals, you can use the event log. Enable at least minimum diagnostics logging on the NSPI Proxy and the RFR Interface—the referral service—categories of the Exchange System Attendant (SA) on the appropriate Exchange 2000 server. (To enable logging, select the server Properties under the appropriate administrative group in Exchange System Manager—ESM.) GC list changes generate event ID 9141 for proxy changes, as Figure 1 shows, and event ID 9148 for referral changes.

All GC lookups either by DSProxy directly or by referred clients use NSPI on the GC. The lookups don't use LDAP because the overhead of conversion between LDAP and NSPI has too great an effect on performance. DSProxy provides no caching to MAPI clients, despite the DSAccess cache, which only server components such as the Store or the Message Categorizer use. GCs directly service all NSPI lookups. However, as DSProxy processes new requests for proxies or referrals, it uses round-robin load balancing over the list of available GCs. If your Exchange 2000 server is running on a GC, DSProxy detects this configuration during startup and doesn't offer access to AD by way of another server, as the event in Figure 2 shows. DSProxy directs directory lookups of clients connected directly to that Exchange 2000 server for mailbox access to NSPI on the same server.

Client Access to the DS
In addition to providing access to message stores, MAPI clients offer access to DSs that serve as a GAL. From Exchange 2000's perspective, MAPI clients come in two forms: pre­Outlook 2000 clients (i.e., the Exchange 5.0 client, the Exchange 4.0 client, Outlook 98, and Outlook 97) and post­Outlook 2000 clients (i.e., Outlook XP) and Outlook 2000.

Microsoft designed pre­Outlook 2000 clients to work with Exchange 5.5. Accordingly, when these clients connect to the Exchange 2000 server that hosts a user's mailbox, they expect a DS to be available on the same server because a DS was always on the same server in Exchange 5.5. Because no DS is present on the Exchange 2000 server, DSProxy handles directory lookup requests from such clients. Figure 3 shows how DSProxy proxies directory lookups to a "nearby" GC and returns directory information to the client. In this case, nearby means near to the Exchange 2000 server, not necessarily near to the client.

The situation is different for Outlook XP and Outlook 2000 clients. Microsoft engineered these smart clients while it was designing Exchange 2000. As a result, these clients don't expect to access a DS only on the Exchange 2000 mailbox server. (Outlook 98 Service Pack 2—SP2—version 8.5.6204.0 or later—lets that version behave as a smart client.)

Figure 4 shows the interaction between the smart clients and the Exchange 2000 and GC servers. When a smart client such as Outlook 2000 initially connects to an Exchange 2000 server, the client requests a referral from DSProxy. DSProxy returns referral information that specifies a GC near the Exchange 2000 server to which Outlook 2000 should directly connect in the future. Outlook 2000 persists this GC referral by writing the information to its MAPI profile. The client writes the GC's Fully Qualified Domain Name (FQDN) into the HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows Messaging SubsystemProfilesProfile Namedca740c8c042101ab4b908002b2fe182 registry subkey and adds the user's MAPI profile.

All directory lookup requests from this point on, even during the initial session, go directly to the GC without any reference to the Exchange 2000 server. Subsequently, when Outlook 2000 next starts, it immediately attempts to access the GC specified in the MAPI profile. If this GC is unavailable, Outlook requests a new referral from DSProxy.

This mechanism lets Outlook 2000 request a new GC only if its preferred choice is unavailable. To force Outlook 2000 to choose a new GC, you must delete the MAPI profile registry subkey I specified. Additionally, Outlook XP and Outlook 2000 SP2 clients implement a mechanism that allows a new GC request every time the client starts. When these clients start, they ignore the GC specified in the MAPI profile, request a new referral from Exchange 2000, then write this value to the MAPI profile that the clients will use for the duration of the session. This dynamic allocation of GCs offers improved support for load balancing; no such support is available with the persistent MAPI profile cache.

GC Placement
The nature of the clients that you use determines the placement of GCs. Proxy clients (e.g., Outlook 98, Outlook 97) have little requirement for local GCs. Rather, you need to place adequate numbers of GCs near the Exchange 2000 servers. A good rule of thumb you can use is one GC to every four Exchange 2000 servers. However, even when you've deployed fewer than four Exchange 2000 servers, you need at least two GCs for redundancy. You must place the GCs on the same network segments as the Exchange 2000 servers and preferably in the same domain or site. This placement doesn't mean that users of proxy clients don't need to have GCs nearby. On the contrary, they need GCs near so that Win2K logon can occur cleanly and efficiently. Therefore, you need to place GCs near user workstations and near Exchange 2000 servers as well.

The general rules apply to smart clients. When Exchange 2000 provides a referral back to the client, it's referring the client to a GC that's near the Exchange 2000 server. This action isn't ideal because the referred GCs might be available to the clients over a WAN connection. In this case, the referral is inefficient because GCs nearer to the clients could better service directory lookups. Because GCs local to the client are available to service logons, in an ideal world Exchange 2000 would refer the client to one of these GCs. Although the type of GC referral that Exchange 2000 uses for smart clients isn't optimal, it's no worse than the proxy behavior or, indeed, the behavior associated with Exchange 5.5.

You can explicitly define GCs for clients rather than relying on DSProxy to arbitrarily assign a GC. For proxying, you specify the GC's FQDN in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeSAParameters registry subkey on the Exchange 2000 server. Add the NSPI Target Server string-type value, and enter the GC's FQDN as the value's data.

Similarly, for smart clients that use the referral mechanism, you can override DSProxy's GC selection and specify a particular GC's FQDN in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeSAParameters registry subkey on the Exchange 2000 server. Add the RFR Target Server string-type value, and enter the GC server name as the value's data.

If you don't want to specify an explicit GC for all clients that will receive referrals from this Exchange 2000 server, you can customize individual clients that are running Outlook XP or Outlook 2000 SP2. Specify the FQDN of the GC you want to use in the HKEY_CURRENT_USERSoftwareMicrosoftExchangeExchange Provider registry subkey on the Outlook client. Add the DS Server string-type registry value, and enter the GC server name as the value's data.

You can disable referrals altogether and force smart clients to use proxying. To do so, add the No RFR Service REG_DWORD value to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeSAParameters registry subkey on the Exchange 2000 server and set the value to 0x1.

GC Failure
Neither proxy clients nor referral clients deal gracefully with the loss of a GC. Although the client maintains access to the mailbox, that client doesn't have directory lookup functionality. In the case of proxy clients, although the client maintains a connection to the Exchange 2000 server that proxies the request to a specific GC, the client address book provider (emsabp32.dll) caches the GC details locally. The caching occurs so that the Exchange 2000 server always proxies the lookup request to the same GC, thus maintaining consistency in the GAL presented to the client. However, if the GC becomes unavailable, the client must restart (and accordingly clear the dynamic cache) before it can use a new GC for the proxy requests.

A similar scenario holds true for the smart clients. While the GC is available, a smart client communicates directly with it. However, if the GC becomes unavailable, you must restart the Outlook client to request a new GC. Under most circumstances, DSProxy provides the client with a new and available GC because DSAccess informs DSProxy that the original GC is down. However, experience has shown that occasionally DSAccess doesn't update DSProxy correctly, and DSProxy might well refer the client to the GC that's unavailable. Because DSProxy load-balances its referrals, you can try restarting Outlook a few times to obtain a referral to an active GC.

An Important Component
I can't overstate the importance of the GC to Exchange 2000. Both server and client rely on the GC's availability for normal operation. Think carefully about how you'll deploy your GCs in support of your server and client populations, because the method you choose is crucial. For the most part, you can rely on DSAccess and DSProxy to direct you to the most appropriate GC. However, in some cases, you might want to override their choice. For example, Outlook clients connecting across a slow link to their Exchange 2000 mailboxes might be better suited to a hard-coded GC local to them rather than a GC colocated with the Exchange 2000 servers. Trying to outsmart DSProxy means using one server name, which obviously affects redundancy. Some fancy footwork with DNS round-robin load balancing, NT Load Balancing Service (WLBS), or preferably hardware-based load balancing will adequately compensate.

The author thanks Paul Bowden, Ian Burgess, and Martin Simpson for their help in preparing this article.