MAPI Client Directory Access in Exchange 2000

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.