Directory service server detection and DSAccess usage

DSAccess is an internal process in Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003 that is used for accessing and for storing directory information. This article provides information on how you can configure DSAccess to either statically or dynamically detect directory service servers that may exist in the topology where the Exchange Server computer resides. All information discussed here pertains to a single Exchange Server computer. Any configurations made to the registry must be made to all Exchange Server computers in the topology. Finally, the list of dynamically-detected directory service servers also applies to the particular Exchange Server computer being considered. This dynamic list is not guaranteed to be unique in a multi-Exchange 2000 environment or a multi-Exchange 2003 environment.

For additional information about the latest service pack for Microsoft Exchange 2000 Server, click the following article number to view the article in the Microsoft Knowledge Base:

DSAccess partitions the set of available directory service servers into the following three (possibly overlapping) categories: global catalog servers, domain controllers, and the configuration domain controller.

Almost all Exchange Server user-context directory service transactions target global catalogs. However, domain controllers can be used for user context requests when the requesting service has sufficient knowledge of the locality of the requested user object in the issued search. Because the directory service server used for a global catalog is also itself a domain controller, this server may be used as both types of directories. DSAccess generates a list of available global catalogs and domain controllers, which it periodically updates as directory service state changes are detected. This list can be shared out to other directory consumers that do not necessarily use DSAccess as their gateway for accessing the directory service (for example, Categorizer, DSProxy, and the System Attendant service). However, subsequent directory service state changes are left to the detection of the service that is requesting this list.

For each available directory service server, DSAccess opens LDAP connections dedicated solely on behalf of each process that is using DSAccess. DSAccess updates these LDAP connections with directory service state information (Up, Slow, or Down) that it detects, and channels requests based on this state information. The set of LDAP connections to those available domain controllers and global catalogs and their associated states forms the profile of the process. For reliability and scalability, DSAccess supports a load-balancing mechanism to distribute user context directory service requests in a round-robin fashion among these LDAP connections. You can statically configure all profiles in the registry to only use a specific set of directory service servers. However, the actual state and load balancing on these connections may differ from process to process (profile to profile). This is not the case for configuration context requests.

DSAccess uses only a single domain controller for all configuration context requests to reduce issues of replication latency (because of a multi-master directory service environment that exists with the architecture of Microsoft Windows 2000), and to avoid partial directory additions or modifications being made to different domain controllers. This single configuration domain controller is shared by all profiles.

DSAccess Static Directory Service Server Usage

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
DSAccess can be statically configured to channel directory service loads to a specified set of directory service servers. This is accomplished in the registry. Like all modifications, extreme caution must be made when updating the registry. Similar in behavior to other Exchange Server services, DSAccess does not check the validity of those directory service servers that are specified in the registry and does not recognize misspellings or other mistakes made here. Upon initialization, DSAccess first reads the registry to determine if any domain controllers or global catalogs have been statically configured. If any domain controllers or global catalogs are statically configured, then no dynamic domain controller detection is performed. Conversely, if no static configurations are made to the registry, DSAccess dynamically detects those directory service servers in the topology (discussed in the "Dynamic Server Detection and Usage" section). The registry keys mentioned in this article are not present by default.

When DSAccess has been statically configured, DSAccess will never fall back and use any other domain controller or global catalog that might otherwise be dynamically detected. As a result, if all the statically configured domain controllers or global catalogs are down, then no DSAccess operations will succeed. If global catalogs are statically configured but no domain controllers are specified in the registry, any available domain controller will be dynamically detected and used. Similarly, if domain controllers are statically configured but no global catalogs are specified in the registry, any available global catalogs will be dynamically detected and used. If the configuration domain controller is not statically configured, the configuration domain controller will be taken from the list of available domain controllers (whether this list is found dynamically or statically configured). As mentioned previously, the domain controllers and global catalogs used for user context requests are profile-dependent. For this reason, the location in the registry for these settings is specified under the Profiles\Default subkey. The following registry keys are required to statically configure domain controller and global catalog servers for use by DSAccess: The configuration domain controller used by DSAccess can be set in one of the following three ways:

• Statically configured in the registry
• Dynamically detected
• By the Microsoft Exchange System Attendant when that service starts.

The first two methods for setting the configuration domain controller are explained after the next registry reference. In Exchange 2000 Server and Exchange 2000 Server SP1, the Microsoft Exchange System Attendant will choose a Configuration Domain Controller when it starts. That choice will be honored by DSAccess for up to 10 hours. In Exchange 2000 Server SP2 and later, the Microsoft Exchange System Attendant will choose the Configuration Domain Controller only on the first service start which occurs during setup or upgrade. In all cases, the choice by the System Attendant is ignored if the configuration domain controller is statically configured in the registry. Static configuration domain controller configuration is taken by DSAccess as a suggestion. This means that if the configuration domain controller is statically configured, DSAccess prefers this domain controller for configuration context requests. If this domain controller becomes unavailable, an alternative domain controller is chosen from the list of available domain controllers. In this event, DSAccess fails over the configuration domain controller by choosing an available User domain controller, behaving as if the configuration domain controller registry keys were not set. As mentioned previously, the configuration domain controller is shared among all profiles. For this reason, the registry settings for the configuration domain controller are specified under the \Instance0 subkey as shown in the following example.

DSAccess Dynamic DS Server Detection and Usage in Exchange 2000 Server and Exchange 2000 Server SP1

Upon initialization, if DSAccess does not find a set of statically configured domain controllers or global catalogs in the registry, it dynamically detects those available directory service servers in the topology. The detection algorithm differs whether DSAccess is sensing domain controllers or global catalog, and is dependent on the locality of the Exchange 2000 server. The following description applies to Exchange 2000 Server and Exchange 2000 Server SP1. The method DSAccess uses in Exchange 2000 SP2 and later differs and is not documented here.

After the initial examination of the registry, DSAccess issues a DsBind to any domain controller in the domain local to the Exchange 2000 server (or a particular domain controller if one is passed in by the caller on a DsctxGetContextEx2() call) by means of the Win32 API call to DsGetDCName(). DSAccess then issues the Win32 API call to DsListServersForDomainInSite() to this domain controller. This call provides a list of all the domain controllers in the local domain and site. DSAccess saves up to ten domain controllers in its profile that it load balances across in a round robin fashion (for each process). The algorithm for global catalog detection is slightly different.

DSAccess uses the same domain controller connection as above for global catalog detection. DsListServersInSite() is the DSAccess internal API that is called to list all "servers" in the site.

NOTE: "Server" has a different meaning for this call than the Win32 API call to DsListServersInSite--this is a bug/quirk in the API definition. Currently, all Win32 APIs for directory service detection are domain-specific. Because Exchange 2000 relies heavily on global catalogs, and to avoid latency issues that may occur because a domain is spread across multiple sites connected by slow links, DSAccess has created its own site-specific directory service detection mechanism.

Using the LDAP connection to the current domain controller that DSAccess is still bound to, it then reads the Options attribute for the NTDS Settings object for each directory service server (if any) in the site local to the Exchange 2000 server. A server is only considered to be a global catalog if the Options attribute exists and has the global catalog flag set. If DSAccess does not find any global catalog in the current site, it calls the Win32 API DsGetDCName() to return any single available global catalog. It only picks a single "remote" global catalog because it assumes that this global catalog may be at the end of a slow link. You will not achieve the scalability of load balancing that you want in this scenario.

DSAccess performs a full network redetection either when the Kerberos ticket times out (default period of 10 hours), any time a configuration change is made (new global catalogs or domain controllers are added to the topology), or if all global catalogs or domain controllers go down. In normal operations, a global catalog or domain controller may go down. In this event, DSAccess does not redetect the network if there are other servers available. It simply flags that particular directory service as "Down," and pings it every five minutes thereafter. If this downed directory service comes back online, it will once again be used.

The configuration domain controller used by DSAccess is by default set to the same domain controller that DSAccess first bound to in the initial dynamic detection of the domain controllers and global catalogs. If any domain controllers or global catalogs are statically configured and no configuration domain controller is explicitly configured, DSAccess uses the first domain controller in the domain controller configured list as the configuration domain controller. If the configuration domain controller used by DSAccess is or becomes unavailable, another configuration domain controller is chosen from the set of available domain controllers. Any change in the configuration domain controller is propagated to all the processes using DSAccess on the same computer.

DSAccess Dynamic DS Server Detection and Usage in Exchange 2000 Server SP2 and later

In Exchange Server 2000 SP2 and later versions, it is no longer necessary to edit the registry to statically assign DSAccess roles to directory service servers. This option is now available in the graphical user interface.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base: