DSAccess partitions the available directory service servers into the following three (possibly overlapping) categories:

• Global catalog servers   Exchange Server 2003 must access global catalog servers to obtain complete address information for all recipient objects in the forest. Only global catalog servers contain a complete replica of all objects in the domain and a partial replica of all objects in the forest. Global catalog servers that an Exchange server currently uses are called working global catalog servers.
  Almost all Exchange Server 2003 user-context directory service transactions target global catalogs. Regardless of how many global catalog servers are located in the local Active Directory site, a maximum of 10 global catalog servers can be added to the working global catalog list. If there are no global catalog servers in the local site, or if none of the global catalog servers in the local site pass the suitability tests, DSAccess uses a maximum of 200 offsite global catalog servers with the lowest costs. 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.
  
• Domain controllers   Domain controllers are used for user-context requests when the requesting service has sufficient knowledge of the location of the requested user object in the issued search. These domain controllers are also called working domain controllers. Working domain controllers are domain controllers in the local domain that can accept domain naming-context queries. Regardless of how many domain controllers are located in the local Active Directory site, a maximum of 10 domain controllers can be added to the working domain controller list. If there are no domain controllers in the local site, or if none of the domain controllers in the local site pass the suitability tests, DSAccess uses offsite domain controllers with the lowest costs.
  Queries to working domain controllers are load balanced on a round robin basis to avoid overloading a single domain controller. If the working domain controllers are not hard-coded in the registry, the list of working domain controllers is re-evaluated and regenerated every 15 minutes using the topology discovery process and suitability tests.
  
• Configuration domain controllers   Exchange Server 2003 can read from multiple domain controllers. To avoid conflicts when applying configuration changes to Active Directory, Exchange Server 2003 writes its configuration information to a single domain controller, called the config domain controller. When selecting a config domain controller from the list of working domain controllers, DSAccess gives preference to a domain controller over a global catalog server. In addition, DSAccess gives preference to a directory server in the local site before using a directory server in a secondary site.
  If the config domain controller becomes unavailable to Exchange Server 2003 for any reason, DSAccess selects another working domain controller as its config domain controller. Every eight hours, DSAccess re-evaluates the config domain controller role by running a set of suitability tests. If the tests are successful, DSAccess continues to use the same config domain controller. If the tests fail, DSAccess chooses another domain controller from the list of working domain controllers as the config domain controller.
  

The core components of Exchange Server 2003 rely on DSAccess to provide a current list of Active Directory servers. For example, the MTA routes LDAP queries through the DSAccess layer to Active Directory. To connect to databases, the store process uses DSAccess to obtain configuration information from Active Directory. To route messages, the transport process uses DSAccess to obtain information about the connector arrangement.

DSAccess updates the list of available global catalogs and domain controllers as changes in the state of the directory service are detected. This list can be shared with other directory consumers that do not use DSAccess as their gateway for accessing the directory service, for example, DSProxy and other components in system attendant. The service that is requesting this list is responsible for the detection of subsequent directory service state changes.

Note:
Unless domain controllers and global catalog servers are hard-coded in the registry, the list of global catalog servers and domain controllers is re-evaluated and regenerated every 15 minutes using a topology discovery process and suitability tests.

In Exchange Server 2003, DSAccess determines the Active Directory topology, opens the appropriate LDAP connections, and works around server failures. For each available directory service server, DSAccess opens LDAP connections solely dedicated to each process that uses DSAccess. DSAccess updates these LDAP connections with directory service state information (Up, Slow, or Down) that it detects. DSAccess uses this state information to decide which LDAP connection to use to forward requests to Active Directory. The set of LDAP connections to available domain controllers and global catalog servers and their associated states forms the DSAccess profile.

DSAccess supports a load-balancing mechanism that distributes user context directory service requests in a round robin fashion among the LDAP connections in the DSAccess profile. Load balancing helps ensure reliability and scalability. You can statically configure all profiles in the registry to use only a specific set of directory service servers. However, the actual state and load balancing of these connections may differ from process to process or profile to profile. This is not the case for configuration context requests.

Note:
Because all Exchange Server 2003 and IIS services use the same security context (the LocalSystem account), it is possible for DSAccess to reuse the LDAP connections from one request to another. At startup or a topology change, DSAccess opens LDAP connections to all suitable domain controllers and global catalog servers in the topology.

When the Microsoft Windows-based implementation of LDAP (WLDAP) returns an error on an LDAP operation, DSAccess analyzes it and determines if it indicates that the directory server is experiencing problems. If so, the directory server is immediately marked as unsuitable, and the user operation is automatically retried on a different server. If there is at least one working domain controller in the topology, DSAccess can continue with flawless operation.

To verify the suitability of a domain controller or global catalog server, DSAccess determines that the server is reachable over port 389 for a domain controller and port 3268 for a global catalog server, and that it resides in a domain that was prepared with DomainPrep. DomainPrep ensures that the group policy system access control list (ACL) is configured correctly to grant Exchange Server 2003 services access to Active Directory. Server suitability checks are covered later in this article.

Note:
To obtain suitability reports in the application event log, you can enable diagnostics logging for the topology category of the DSAccess service in Exchange System Manager.

The DSAccess topology always contains two lists, the in-site list and the out-of-site list. The in-site list contains servers from the local Active Directory site of the Exchange server. The out-of-site list contains servers from other Active Directory sites. Initially, DSAccess uses only servers from the local site, but when all local servers from a certain category, for example, global catalog servers, are not suitable, DSAccess immediately starts using the out-of-site list. DSAccess then keeps checking the local site every five minutes and fails back as soon as it is possible. User requests are retried on the out-of-site servers immediately and seamlessly for users.

Some Exchange Server 2003 components, such as the Microsoft Exchange Routing Engine service, also register with Active Directory to be automatically informed by Active Directory of any changes to configuration information. This notification mechanism eliminates polling, but the event registration is per target server. If DSAccess marks the target server as down, it reissues the event registration and informs the client process, such as the Routing Engine service, of a change, because the monitored values could have changed during the process of selecting a new domain controller or global catalog server.

At startup, DSAccess uses a discovery process to identify the Active Directory topology and assess the availability of domain controllers and global catalog servers. After startup is complete, and every 15 minutes thereafter, DSAccess uses an almost identical process to rediscover the topology and to check for any changes in server availability.

Note:
If you hard code the directory servers that are used by DSAccess, DSAccess bypasses the discovery process and checks for server suitability only.

The following sequential list outlines the discovery process and indicates differences between initial discovery and rediscovery:

1. The system attendant process (Mad.exe) instantiates and initializes DSAccess.dll during startup.
   
2. From the local domain, DSAccess opens an LDAP connection to a randomly chosen domain controller. This server is referred to as the bootstrap server.
   
3. DSAccess reads the local registry to determine if the topology is hard coded. If the topology is hard coded, the discovery process stops. If no hard coding is detected, DSAccess continues the discovery process.
   
4. DSAccess queries the bootstrap server to identify local domain controllers and global catalog servers. DSAccess then determines server suitability and assigns server roles.
   
5. DSAccess queries the bootstrap server to determine if one or more secondary sites are connected to the local site. If secondary sites exist, DSAccess sorts the siteLink objects for each site from lowest cost to highest cost. DSAccess places the lowest cost sites in a secondary topology list.
   
6. DSAccess queries the bootstrap server to identify the domain controllers and global catalog servers that are located in the secondary topology sites.
   
7. DSAccess identifies the full topology and compiles a list of working domain controllers, and a list of working global catalog servers.
   

By default, DSAccess initialization during startup must finish within one minute. Otherwise, DSAccess stops. One minute is usually long enough for DSAccess to initialize. If initialization takes longer than one minute, this might indicate a problem with the network or topology configuration. Although you can extend the time-out parameter by setting a registry key, you should first determine why initialization takes longer than expected. To configure the time-out, use the registry setting shown in the following table.

Note:
If you set the diagnostics logging level for all categories of the MSExchangeDSAccess service to Maximum, Exchange System Manager automatically obtains detailed information about the initialization of DSAccess and places that information in the application event log.

After DSAccess discovers the Active Directory topology, it determines whether the discovered list of working domain controllers and global catalog servers is suitable for use. During initial discovery and ongoing rediscovery, DSAccess determines server suitability by running a series of suitability tests. Suitability tests fall into two categories: hard tests and soft tests. Hard tests determine whether the domain controller or global catalog is a viable candidate for use. If the server fails the hard tests, it is considered unusable, removed from the list of discovered servers, and the soft tests are not run.

DSAccess runs the following hard suitability tests:

• Global catalog capabilities   DSAccess determines if the directory server is specifying itself as a global catalog server by determining if the isGlobalCatalogReady attribute on the RootDSE object of the server is set to TRUE. If the attribute is set to TRUE, the directory server is determined to be a valid and usable global controller.
  
• Reachability   DSAccess uses Internet Control Message Protocol (ICMP) to contact each server to verify that the server is available. DSAccess also verifies that the directory server is reachable over port 389 for domain controllers and port 3268 for global catalog servers.
  If you use ICMP to determine if a server is available, you might create a problem if all connections in your network do not support ICMP. For example, an Exchange server might reside in a perimeter network, which has no ICMP connectivity between the Exchange server and the domain controllers. In this situation, you should disable the ICMP check and set registry parameter in the following table to zero.
  

  Location	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\MSExchangeDSAccess
  Value	LdapKeepAliveSecs
  Type	REG_DWORD
  Value Data	0x0
  Description	If the registry key does not exist or is not set to 0, DSAccess uses the PING protocol.

  For more information about the LdapKeepAliveSecs registry key, see Microsoft Knowledge Base article 320529, "XADM: Using DSAccess in a Perimeter Network Firewall Scenario Requires a Registry Key Setting."
  
• Group policy SACL permission   Together with the regular access control list (ACL) permissions, Setup grants all servers running Exchange Server 2003 security access control list (SACL) permission to view ntSecurityDescriptor attributes. Permission is granted through the SeSecurityPrivilege privilege. DSAccess reads the security descriptor of the configuration directory partition object on the server, to verify that the SACL is readable. If the SACL cannot be read, DSAccess considers the server not suitable.
  
• Critical data   The directory server must be located in a domain in which DomainPrep was run. The domain must contain the Exchange Server 2003 server object in the Exchange configuration container.
  
• Synchronization   DSAccess verifies that the server is synchronized by determining if the isSynchronized attribute on the rootDSE object of the server is set to TRUE.
  
• Netlogon   DSAccess sends a DSGetDcName remote procedure call (RPC) to the directory server to test its general suitability. If the directory server is not synchronized, is out of disk space, or is experiencing other problems, it will not identify itself as a directory server.
  In a perimeter network, in which RPC traffic is not allowed, the Netlogon check cannot occur. However, the Netlogon check continues to issue RPCs until it fails, which can take a long time. Because repeated Netlogon checks decrease performance, you should stop DSAccess from issuing Netlogon checks by creating the following registry key.
  

  Location	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\MSExchangeDSAccess
  Value	DisableNetLogonCheck
  Type	REG_DWORD
  Value Data	0x0
  Description	If the registry key does not exist or is not set to 0, DSAccess performs the Netlogon check.

For more information, see Microsoft Knowledge Base article 320228, "XGEN: The "DisableNetLogonCheck" Registry Value and How to Use It."

• Version of the operating system   Exchange Server 2003 can use only domain controllers and global catalog servers running Microsoft Windows Server™ 2003 or Windows 2000 Server Service Pack 3 or later. DSAccess determines whether the directory server meets these requirements.
  After hard tests are complete, DSAccess runs a series of soft tests to determine which directory servers can accommodate the additional load placed on them by Exchange Server 2003. To make this determination, DSAccess runs the following soft suitability tests:
  
  • DNS weight   DSAccess uses the weight value of the domain controllers and global catalog servers, as specified in each server's (SRV) resource records in Domain Name System (DNS) to determine which server the client should prefer. A higher weight results in a higher probability that DSAccess will choose a server. If DSAccess cannot read the weight, it uses a default weight of 100. 
    
  • FSMO primary domain controller role owner   If your topology contains servers running Windows NT® Server 4.0, the directory server with the Flexible Single Master Operations (FSMO) primary domain controller (PDC) role will experience heavy loads, making it a less than ideal candidate for use by Exchange Server 2003. For this reason, DSAccess performs a soft suitability test to locate the PDC FSMO role owner, so that it can remove it from the list of suitable directory servers.
    
  • Response time   DSAccess performs an LDAP query against the directory server to check its response time. Response time greater than two seconds is considered a soft suitability test failure.
    

Note:
DSAccess includes support for full round robin load balancing and failover to another directory server, if a currently used server becomes unavailable. These features are disabled when Exchange Server 2003 is running on a domain controller or global catalog server.