XCON: Preloading and the DSAccess Cache (250572)


The information in this article applies to:

  • Microsoft Exchange 2000 Server
This article was previously published under Q250572
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SUMMARY

A number of Microsoft Exchange 2000 Server transactions require multiple searches of Active Directory. For example, POP and IMAP may search for user attributes based on the filter

(&(mailNickName = user1) (objectClass = user))

while the store may issue a request based on user1's objectGUID. Without preloading, both of these transactions result in searches on Active Directory even though DSAccess is designed to request the same attribute set for a given user.

By setting appropriate values for preload registry keys, you can enhance the performance of the Exchange server and reduce the load on Active Directory.

MORE INFORMATION

Directory Service Access Cache (DSAccess Cache)

The DSAccess cache resides on the Exchange server and fills up with 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 find the record in the cache. Unnecessary load on Active Directory is thus prevented for identical searches. Unfortunately, DSAccess does not prevent load on Active Directory when the search filter is different than that contained in the cache, even though DSAccess requests the same attribute set for the user object.

Preloading

Search preloading is a means of avoiding the multiple Active Directory search problem that can occur when various search filters are issued on the same user object. Preloading works by the previously mentioned key construction where a search entry is constructed by the scope, BaseDN, and the filter of the search. In the registry, a typical example of a preload search looks like the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\PreloadBaseDNs DC=mydom,DC=com

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\PreloadFilters legacyExchangeDN=%

DSAccess reads the registry and interprets the percent sign (%) as a fill-in parameter. When an actual search is issued, the returned record from the directory is parsed and the value of this attribute specified in the preload filter is inserted in the search entry. At this point, pointers are set to the applicable user record. Like all modifications to the registry, use extreme caution when you are updating the registry. Similar in behavior to 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 made here. Those values populated for preloading have been optimally set for the most common Exchange 2000 searches.

A number of Exchange transactions could trigger a preloading event, but certain criteria must be met. These events occur in the following order:
  • A search of Active Directory is performed. If the three conditions below are met on that search, the DSAccess cache is loaded.
    • The DN must have been returned from a user-naming context search.
    • The DN of the result must contain the BaseDN specified in the preload registry settings. Therefore, if the actual issued search specifies a BaseDN that is more general than what is specified in the preload BaseDN, preloading does not work.
    • The returned record at this point is parsed and the attributes specified in the preloaded search string are extracted out. The attributes required for constructing the search filter must exist. In the following example of a multiplexed search, at least one of the fill-in attributes must exist:

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

      Because of the ambiguity in the returned result, the attribute in the preload filter string must not be multivalued. For example, proxyAddresses = % is an invalid preload search filter because proxyAddresses is a multivalued attribute and DSAccess does not know which value to use for the fill-in.
  • A search entry is constructed from the scope, BaseDN, and the attributes and filter string, and is linked to this DN entry in the cache. For example:

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

  • Future Active Directory search requests on the preloaded filters and BaseDNs will hit the cache instead of searches on Active Directory itself.

Summary of Registry Settings

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadBaseDNs
This is a multistring setting. Each BaseDN must correlate to a single preload filter; that is, BaseDNs and filter fill-ins must match in a one-to-one fashion.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadFilters
This is also a multistring setting where you specify the filter string fill-ins.
Modification Type:MinorLast Reviewed:4/25/2005
Keywords:kbinfo KB250572
©2004 Microsoft Corporation. All rights reserved.