Difference between revisions of "Microsoft KB Archive/250572"
(importing KB archive)
m (Text replacement - "&" to "&")
|Line 58:||Line 58:|
(&(mailNickName = user1) (objectClass = user))
Latest revision as of 11:35, 21 July 2020
Article ID: 250572
Article Last Modified on 2/27/2007
- Microsoft Exchange 2000 Server Standard Edition
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
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.
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:
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:
- 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
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.
Keywords: kbinfo KB250572