Directory Integration and Exchange Server 2003

 

Exchange Server 2003 information in Active Directory includes information about recipients and configuration information about the messaging organization. Active Directory helps provide the security subsystem for Exchange Server 2003. Active Directory security ensures that only authorized users can access mailboxes and only authorized administrators can modify the Exchange configuration in the organization.

The following three directory partitions in Active Directory contain Exchange-related data:

• Domain directory partition   Exchange recipient and system objects are stored in the domain directory partition in Active Directory. The domain directory partition is replicated to every domain controller in a particular domain.

• Configuration directory partition   Exchange configuration objects, such as administrative groups, global settings, recipient policies, system policies, and address list or address information are stored in the configuration directory partition. The configuration directory partition is replicated to all domain controllers in the forest.

• Schema directory partition   Exchange schema modifications (for example, classes and attributes) are stored in the schema directory partition. The schema directory partition is replicated to all domain controllers in the forest.

Exchange Classes and Attributes in Active Directory

The Active Directory schema defines the object classes that can be created in the directory and the attributes that can be assigned to each instantiation of an object. During installation of the first Exchange 2003 server in an Active Directory forest, Exchange must modify this schema so that Active Directory can store Exchange-specific recipient and configuration information. The ForestPrep process in the Exchange Setup program extends the Active Directory schema. You can also run this process explicitly by using the Setup/ForestPrep command line to add Exchange-specific classes and attributes to the Active Directory schema, without actually installing a server. This extra step is required if the person installing Exchange Server 2003 does not have schema administrator rights.

The Exchange Server 2003 Setup program extends the Active Directory schema by importing a series of .ldf files into Active Directory. Except for Exschema.ldf, all .ldf files are in the \Setup\i386\Exchange directory on the product CD. Exschema.ldf is in the \Setup\i386\Exchange\Bin directory.

The following table lists the various .ldf files that define the objects and attributes for Exchange Server 2003.

Exchange Server 2003 installation files with Active Directory schema extensions

File Name	Description
Schema0.ldf	Includes schema extensions for recipient objects, such as the definition of Exchange extension attributes, which you can use to assign information, not covered by any one of the standard attributes, to recipient objects.
Schema1.ldf	Includes schema extensions for Active Directory Connector, which you can use to integrate an Exchange Server 5.5 organization with Active Directory.
Schema2.ldf	Includes schema extensions for Internet access protocols, directory synchronization, and Exchange store configuration objects.
Schema3.ldf	Includes schema extensions for system monitoring, Connector for Lotus Notes configuration objects, offline address book settings, and settings that belong to X.400 connectors.
Schema4.ldf	Includes schema extensions for routing groups, bridgehead servers, protocol containers, messaging databases, address list services, and Microsoft Exchange MTA configuration objects.
Schema5.ldf	Includes schema extensions for protocol containers, routing group connectors, and parameters that pertain to Extensible Storage Engine (ESE).
Schema6.ldf	Includes schema extensions for protocol virtual servers, administrative groups, messaging connectors, and the Exchange store.
Schema7.ldf	Includes schema extensions for messaging databases and mailbox manager.
Schema8.ldf	Includes schema extensions for mailbox manager, system monitoring, public folders, and SMTP transport configuration objects.
Schema9.ldf	Includes schema extensions for Calendar Connector, Connector for Novell GroupWise, dynamic distribution lists, messaging folders, and Outlook Mobile Access. Note Schema1.ldf through Schema8.ldf are identical for Exchange 2000 Server and Exchange Server 2003. Schema9.ldf contains the schema extensions that are new in Exchange Server 2003.
Exschema.ldf	Adds the Object-GUID, Replication-Signature, Unmerged-Attributes, and ADC-Global-Names attributes to the schema to update a pre-Exchange 2000 Service Pack 1 schema with the information required for Exchange Server 2003.

Directory Service Access

Exchange 2003 services access information that is stored in Active Directory and write information to Active Directory. If this communication occurred directly between each service and Active Directory, Exchange 2003 could overwhelm an Active Directory domain controller with communication requests. A central component is required to streamline communication with Active Directory. This component is the DSAccess module.

DSAccess is a shared API that is used by multiple components in Exchange 2003 to query Active Directory and obtain both configuration and recipient information. DSAccess is implemented in DSAccess.dll, which is loaded by both Exchange and non-Exchange components, including System Attendant, message transfer agent, Microsoft Exchange Information Store service, Exchange Management Service, Internet Information Services (IIS) and Windows Management Instrumentation (WMI). DSAccess discovers the Active Directory topology, detects domain controllers and global catalog servers, and maintains a list of valid directory servers that are suitable for use by Exchange components. In addition, DSAccess maintains a cache that is used to minimize the load on Active Directory by reducing the number of Lightweight Directory Access Protocol (LDAP) requests that individual components send to Active Directory servers.

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 how many global catalog servers are located in the local Active Directory site, a maximum of ten 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 off-site 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 ten 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, then DSAccess uses off-site 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 re-generated 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 preferences 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 message transfer agent (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.

LDAP Connection Load-Balancing and Failover

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 (profile to profile). This is not the case for configuration context requests.

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 (domain controller) and port 3268 (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 section.

The DSAccess topology always contains two lists, the in-site list and the out-of-site list. One list (in-site) contains servers from the local Active Directory site of the Exchange server and the other list (out-of-site) 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 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.

DSAccess Topology Discovery

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.

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 following registry setting.

Location	HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess
Value	TopoCreateTimeoutSecs
Type	REG_DWORD
Description	Sets the timeout value for DSAccess initialization in seconds, such as 0x200. The default is 0x3C seconds (1 minute).

Initial Discovery and Ongoing Rediscovery

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, then the directory server is determined to be a valid and usable global controller.

• Reachability   DSAccess uses Internet Control Message Protocol (ICMP) to ping 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 the following registry parameter to zero.

  Location	HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess
  Value	LdapKeepAliveSecs
  Type	REG_DWORD
  Value Data	0x0
  Description	DSAccess uses the ping protocol if there is no registry key does or it is not set to 0,

  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."

  Warning

  Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

• Group policy SACL permission   Together with the regular access control list (ACL) permissions, Setup grants all servers running Exchange 2003 Server 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 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, the directory server with the flexible single master operation (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.

Hard-Coding DSAccess Servers

DSAccess allows an administrator to statically configure specific domain controllers and global catalogs for use by DSAccess, and to disable the automatic topology discovery process. These hard-coding entries are configured using the DSAccess user interface in Exchange System Manager, as illustrated in the following figure.

Directory Access tab in Exchange System Manager

On initialization, DSAccess reads the registry to determine if any domain controllers or global catalog servers are statically configured. If any domain controllers or global catalog servers are statically configured, the dynamic topology detection is not performed. If no static directory servers are identified, DSAccess dynamically detects the directory service servers in the topology.

When DSAccess is statically configured, the load-balancing and failover features in DSAccess do not engage, and no other domain catalog or global catalog is used or detected. As a result, if all of the statically configured domain catalogs or global catalogs are offline or otherwise unreachable, DSAccess operations fail. If global catalogs are statically configured, but no domain catalogs are specified in the registry, any available domain controller is dynamically detected and used. Similarly, if domain catalogs are statically configured, but no global catalogs are specified in the registry, any available global catalogs are dynamically detected and used. If the config domain controller is not statically configured, it is removed from the list of available domain controllers (whether this list is dynamically or statically configured).

DSAccess Profiles

Domain controllers and global catalogs used for user-context requests are profile-dependent. Therefore, the values in the registry for these settings are located under a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default subkey. The following registry keys are required to statically configure domain controllers and global catalog servers for use by DSAccess.

Location	MSExchangeDSAccess\Profiles\Default\<Name of DC>
Value	IsGC
Type	REG_DWORD
Value Data	0x0

Location	MSExchangeDSAccess\Profiles\Default\<Name of DC>
Value	HostName
Type	REG_SZ
Value Data	<name of DC>

Location	MSExchangeDSAccess\Profiles\Default\<Name of DC>
Value	DSType
Type	REG_SZ
Value Data	0

Location	MSExchangeDSAccess\Profiles\Default\<Name of DC>
Value	PortNumber
Type	REG_DWORD
Value Data	0x00000185 (389)

Location	MSExchangeDSAccess\Profiles\Default\<Name of GC>
Value	IsGC
Type	REG_DWORD
Value Data	0x1

Location	MSExchangeDSAccess\Profiles\Default\<Name of GC>
Value	HostName
Type	REG_SZ
Value Data	<name of GC>

Location	MSExchangeDSAccess\Profiles\Default\<Name of GC>
Value	DSType
Type	REG_SZ
Value Data	0

Location	MSExchangeDSAccess\Profiles\Default\<Name of GC>
Value	PortNumber
Type	REG_DWORD
Value Data	0x00000cc4 (3268)

Specifying the Configuration Domain Controller

The config domain controller that is used by DSAccess can be set in one of the following three ways:

• Statically configured in the registry   The config 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 follows.

  Location	MSExchangeDSAccess\Instance0
  Value	ConfigDCHostName
  Type	REG_SZ
  Value Data	<Name of config DC>

  Location	MSExchangeDSAccess\Instance0
  Value	ConfigDCPortNumber
  Type	REG_DWORD
  Value Data	0x00000185 (389)

• Dynamically detected   If a config domain controller is not specified statically, DSAccess uses dynamic topology discovery to locate a config domain controller. DSAccess uses the selected config domain controller for eight hours, after which it randomly chooses a new config domain controller. DSAccess chooses a new config domain controller before then if System Attendant is restarted or if the currently selected config domain controller fails or shuts down.

• By System Attendant on startup   In Exchange Server 2003, the System Attendant process chooses the config domain controller only on the first service start, which occurs during setup or upgrade. In all cases, the choice by System Attendant is ignored if the config domain controller is statically configured in the registry. DSAccess takes a static config domain controller entry as a suggestion. Thus, if the config domain controller is statically configured, DSAccess prefers it for configuration context requests. If that domain controller becomes unavailable, an alternative domain controller is chosen from the list of working domain controllers. In this case, DSAccess fails over the config domain controller by choosing an available domain controller and behaving as if the config domain controller registry information is not present.

How DSAccess Assigns Server Roles

The following examples depict different Active Directory configurations and show how DSAccess assigns server roles in each case. In these examples, it is assumed that all domain controllers and global catalogs are running Windows 2000 Server with Service Pack 3 or later, that all suitability tests are passed equally, and that no static domain controllers are hard-coded (that is, DSAccess performs dynamic topology discovery).

Example 1 – Simple Single Domain Topology

The following figure depicts a single forest with a single domain that is made up of two sites. Site A contains a single domain controller and a single global catalog, and Site B contains three domain controllers and two global catalogs.

One domain with two sites

DSAccess running on Exchange Server 2003 servers in Site A will detect the topology shown in the following table.

Topology for Site A

Domain Controller Type	Server
Config domain controller	Domain controller 1 or global catalog 1
Working domain controllers	Domain controller 1 and global catalog 1
Working global catalogs	Global catalog 1

DSAccess running on Exchange Server 2003 servers in Site B will detect the topology shown in the following table.

Topology for Site B

Domain Controller Type	Server
Config domain controllers	Domain controllers 2, 3, and 4 Global catalog 2 or 3
Working domain controllers	Domain controllers 2, 3, and 4 Global catalogs 2 and 3
Working global catalogs	Global catalogs 2 and 3

In each case, the order of the listed servers is important. The servers are listed and used in the order in which they are discovered by DSAccess and determined to be suitable.

Example 2 – Complex Domain Topology

The following figure depicts a more complex topology, which includes two domains and two sites, with Site A spanning both domains.

Two domains with a site spanning both domains

DSAccess running on Exchange Server 2003 servers in Domain 1 and Site A will detect the topology shown in the following table.

Topology for Domain 1 and Site A

Domain Controller Type	Server
Config domain controller	Domain controllers 1, 2, 3, and 4 Global catalogs 1, 2, or 3
Working domain controllers	Domain controllers 1, 2, 3, and 4 Global catalogs 1, 2, and 3
Working global catalogs	Global catalogs 1, 3, and 2

DSAccess running on Exchange Server 2003 servers in Domain 2 and Site A will detect the topology shown in the following table

Topology for Domain 2 and Site A

Domain Controller Type	Server
Config domain controller	Domain controllers 1, 2, 3, 4 Global catalogs 1, 2, or 3
Working domain controllers	Domain controllers 1, 2, 3, and 4, Global catalogs 1, 2, and 3
Working global catalogs	Global catalogs 2, 1, and 3

DSAccess running on Exchange Server 2003 servers in Domain 2 and Site B will detect the topology as shown in the following table.

Topology for Domain 2 and Site B

Domain Controller Type	Server
Config domain controller	Domain controller 5 Global catalog 4
Working domain controller	Domain controller 5 Global catalog 4
Working global catalogs	Global catalog 4

Once again the servers are listed and used in the order in which they are discovered and determined to be suitable.

Directory Access Cache

The DSAccess cache is an in-memory cache on the Exchange server that contains configuration and user records retrieved from Active Directory. Records in the cache are accessed through the object's Distinguished Name (DN), Globally Unique Identifier (GUID), or a key constructed from the scope, BaseDN, and the filter used to find this object in Active Directory. Subsequent accesses using the same DN, GUID, or key will find the record in the cache. As previously mentioned, DSAccess is a shared API that is used by several processes on an Exchange Server 2003 computer. The following table lists the processes that load DSAccess.dll into their heap and benefit from Active Directory information caching.

Processes that load DSAccess.dll

Process	Description
Mad.exe	Microsoft Exchange System Attendant service
Store.exe	Microsoft Exchange Information Store service
EMSMTA.exe	Microsoft Exchange MTA Stacks service
ExMgmt.exe	Exchange Management service
RESvc.exe	Exchange Routing Engine service
Inetinfo.exe or W3WP.exe	IIS and worker processes
Winmgmt.exe	Windows Management Instrumentation service

The following table lists the various Exchange components that use DSAccess to acquire user and configuration information.

Exchange component use of DSAccess

Component	Uses DSAccess for
Metabase update service (DS2MB)	Directory changes tracked by update sequence number (USN)
Exchange Routing Engine (RESVC)	User and configuration lookups
SMTP categorizer (SMTP CAT)	List of global catalog servers in the topology
Directory Service Proxy (DSProxy)	List of global catalog servers in the topology
Exchange store	User and configuration lookups
WebDAV	User and configuration lookups
Message transfer agent (MTA)	User and configuration lookups

The DSAccess cache enables the directory lookups performed by these components to be cached for a period of time. During that time, if another process requests the same information, it can be retrieved from the DSAccess cache, instead of repeating the same query against a working global catalog. All directory access, except Address Book lookups from MAPI clients and certain portions of SMTP inbound and outbound routing, goes through the DSAccess process and is cached.

By default, directory entries are cached for 15 minutes for configuration data and five minutes for user data. The default size of the user cache is 140 megabytes (MB), and the configuration cache is 5 MB. The number of users, the maximum number of entries, the maximum cache size (memory), and the cache expiration time are all parameters that can affect the optimal size and performance of the DSAccess cache.

The following registry keys (none of which are present by default) provide low-level control of the DSAccess cache for configuration data.

Location	MSExchangeDSAccess\Instance0
Value	CacheTTLConfig
Type	REG_DWORD
Value Data	0x384 (900 seconds)
Description	Used to specify the time-to-live (TTL) for configuration data in the cache

Location	MSExchangeDSAccess\Instance0
Value	MaxEntriesConfig
Type	REG_DWORD
Value Data	0 (no limit)
Description	Used to specify the maximum number of configuration data entries in the cache

The following registry keys (none of which are present by default) provide low-level control of the DSAccess cache for user data.

Location	MSExchangeDSAccess\Instance0
Value	CacheTTLUser
Type	REG_DWORD
Value Data	0x12c (300 seconds)
Description	Used to specify the time-to-live (TTL) for user data in the cache

Location	MSExchangeDSAccess\Instance0
Value	MaxEntriesUser
Type	REG_DWORD
Value Data	0 (no limit)
Description	Used to specify the maximum number of user data entries in the cache

Preloading DSAccess

You should preload search filters to avoid the problem of running multiple search instances against Active Directory concurrently, which occurs when various search filters are issued on the same user object. You can enable preloading through the following registry keys, which define the scope, the base distinguished name (BaseDN), and the filter of the search.

The following registry values can be used to preload the DSAccess cache.

Location	MSExchangeDSAccess
Value	PreloadBaseDNs
Type	REG_MULTI_SZ
Value Data	BaseDN value (for example, DC=contoso,DC=com)
Description	Identifies the container object that is used as the root for the query. This is a multi-string setting. Each BaseDN must correlate to a single preloaded filter. This means that BaseDNs and filter string must match each other exactly.

Location	MSExchangeDSAccess\
Value	PreloadFilters
Type	REG_MULTI_SZ
Value Data	A filter string, for example, legacyExchangeDN=%
Description	DSAccess reads the registry and interprets the percent sign (%) as an open parameter, which will be determined. When an actual search is issued, the returned record from the directory is parsed, and the value of this attribute, which is specified in the preloaded filter, is inserted in the search entry. Next, pointers are set to the applicable user record. As with all modifications to the registry, use extreme caution when you are updating the registry. In the same manner as other Exchange services, DSAccess does not check the validity of the Active Directory servers that are specified in the registry and does not recognize misspellings or other possible mistakes there. Those values that are populated for preloading are optimally set for the most common Exchange searches.

A number of Exchange transactions could trigger a preloading event, but specific criteria must be met. These preloading events occur in the following order:

1. A search of Active Directory is performed. If the following three conditions are met in that search, the DSAccess cache is loaded:

   • The distinguished name must be returned from a user-directory partition search.

   • The resulting distinguished name must contain the BaseDN specified in the preloaded registry settings. For example, if the actual search specifies a BaseDN that is more general than the preloaded BaseDN, preloading does not occur.

   • At this point, the returned record is parsed, and the attributes specified in the preloaded search string are extracted. The attributes required for constructing the search filter must exist. In the following example of a multiplexed search, at least one of the attributes must exist:

     (|(objectGuid=%) (msExchMailboxGuid=%))

     Because of the ambiguity in the returned result, the attribute in the preloaded filter string must not be multivalued. For example, proxyAddresses = % is not a valid preloaded search filter, because proxyAddresses is a multivalued attribute, and DSAccess does not know which value to use for the open value.

2. A search entry is constructed from the scope, BaseDN, attributes, and filter string— and is linked to this distinguished name entry in the cache. For example:

   [scope = Whole Subtree] / [baseDN = DC=mydom,DC=com] / [filter = (objectClass=myclass)]

DSAccess processes future Active Directory search requests on the preloaded filters and BaseDNs using the cache instead of Active Directory.