Article ID: 250572 - View products that this article applies to.
This article was previously published under Q250572
This article has been archived. It is offered "as is" and will no longer be updated.
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:
(http://support.microsoft.com/kb/256986/EN-US/ )Description of the Microsoft Windows Registry
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.
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.
PreloadingSearch 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\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:
Summary of Registry SettingsHKEY_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.
This is also a multistring setting where you specify the filter string fill-ins.
Contact us for more help
Connect with Answer Desk for expert help.