Microsoft designed preOutlook 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_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Profile Name\dca740c8c042101ab4b908002b2fe182 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 SP3 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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters 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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters 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 SP3. Specify the FQDN of the GC you want to use in the HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange 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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters 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