Microsoft KB Archive/216076

= Accessing information store folders may become slow in Exchange =

Article ID: 216076

Article Last Modified on 10/25/2007

-

APPLIES TO


 * Microsoft Exchange Server 2003 Enterprise Edition
 * Microsoft Exchange Server 2003 Standard Edition
 * Microsoft Exchange 2000 Enterprise Server
 * Microsoft Exchange 2000 Server Standard Edition
 * Microsoft Exchange Server 5.5 Standard Edition
 * Microsoft Exchange Server 5.0 Standard Edition
 * Microsoft Exchange Server 4.0 Standard Edition
 * Microsoft Messaging Application Programming Interface
 * Microsoft Collaboration Data Objects 1.21

-



This article was previously published under Q216076



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



SYMPTOMS
When you try to open one or more folders in either the private or public information store, the process may become very slow or unresponsive. This behavior may manifest itself in the following ways:
 * Client response is very slow if you access mail in a folder (for example, if you change the status of an item from read to unread, open an item, or delete an item).
 * You receive Messaging Application Programming Interface (MAPI) error messages that include the phrase "Client Operation Failed."
 * Log files in the Mdbdata folder grow at a steady rate and you observe very little change, if any, in the public folder resources or the mailbox resources.
 * If you create a new folder and move the contents of the folder with the behavior to the new folder, you can resolve the issue for a few days, but the behavior later reoccurs.
 * If you access particular folders, response is slow or problematic, but other folders in the same database respond as usual. This includes special folders such as gateway folders (for example, the Mts-in and Mts-out folders).



CAUSE
Too many cached restrictions, back links, and searches are being placed on an individual folder.

To determine if you are experiencing the behavior discussed in this article, perform either one of the following tests:

Important Before you perform Test 1, ensure that you have a full online backup of the information store, because Test 1 resets folder views on the server.

Test 1
 Add the Reset Views registry value for either the public or private information store.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To add this value, perform one of the following procedures, as applicable:  The Public Information Store: To modify the registry key to change the Reset Views value for the public information store, follow these steps:  Start Registry Editor (Regedt32.exe). For Exchange Server 5.5, locate the following key in the registry:

For Exchange 2000 Server and for Exchange Server 2003, locate the following key in the registry:

Note is the Globally Unique Identifier for the store. Add a Reset Views value of the REG_DWORD type. The default of the Reset Views value, without this registry entry, is 0. Set the value to 1.</li> Quit Registry Editor.</li></ol> </li> The Private Information Store: To modify the registry key to change the Reset Views value for the private information store, follow these follow steps: <ol style="list-style-type: lower-alpha;"> Start Registry Editor (Regedt32.exe).</li> For Exchange Server 5.5, locate the following key in the registry:

For Exchange 2000 Server and for Exchange Server 2003, locate the following key in the registry:

Note  is the Globally Unique Identifier for the store.</li> Add a Reset Views value of the REG_DWORD type.</li> The default of the Reset Views value, without this registry entry, is 0. Set the value to 1.</li> Quit Registry Editor.</li></ol> </li></ul> </li> Stop the information store service, and then restart it.</li></ol>

If this value exists and is set to a non-zero value, the information store deletes all of the cached restrictions on the next cleaning interval (during information store maintenance) and resets the value to zero. You can determine if this has occurred; check the registry key to see if the value has been reset to zero. After deletion of the cached restrictions occurs, if the performance of the folder is greatly improved, you are experiencing the behavior discussed in this article.

Test 2
<ol> Stop the information store.</li> At a command prompt, go to the Exchsrvr\Bin folder and run the Isinteg utility. In Exchange Server 5.5, type the following at the command prompt:

isinteg -pri|pub -dump -l

In Exchange 2000 Server and in Exchange Server 2003, type the following at the command prompt:

isinteg –s  -dump -l

Note  is the name of your Exchange computer, and   is the name of a file to write the output text to.

Warning This command dumps details of all of the folders in the specified database to the file that is specified by -l. Depending on the size of the database, the log file that is produced may be quite large.</li> Examine the log file and look for any folders with large numbers of entries under the following fields:

Search FIDs=

Recursive FIDs=

Search Backlinks=

Categ FIDs=

For example:

Search FIDs=0001-000000000418,0001-00000000041B,0001-000000000421, 0001-000000000423,0001-000000000424,0001-000000000428,0001-00000000042D

If this continues for several hundred entries, you are experiencing the behavior discussed in this article.</li></ol>

<div class="workaround_section">

WORKAROUND
To work around this behavior, decrease the Aging Keep Time value for the affected database (either the public or private information store).

Aging Keep Time
The Aging Keep Time value indicates the length of time that an unused index will exist before being deleted. To decrease this value, perform one of the following procedures, as applicable:
 * Exchange 2000 Server and Exchange Server 2003

The Aging Keep Time value can be set in two locations: the Active Directory directory service and the registry. If the Active Directory attribute has a value set, it overrides the corresponding registry value.
 * To set the Aging Keep Time value in Active Directory, follow these steps:

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

Note The ADSI Edit snap-in (AdsiEdit.msc) is included with the Microsoft Windows Support Tools. To install the Windows Support Tools in Windows 2000, double-click Setup.exe in the Support\Tools folder on the Windows 2000 CD. To install the Windows Support Tools in Windows Server 2003, double-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD.
 * Click Start, click Run, type adsiedit.msc, and then click OK.
 * Expand Configuration Container [ ], where  is the name of your domain controller, and   is the name of your domain.
 * Expand CN=Configuration,DC= ,DC=.
 * Expand CN=Services,CN=Microsoft Exchange,CN=, where  is the name of your Exchange organization.
 * Expand CN=Administrative Groups,CN= ,CN=Servers, CN= ,CN=InformationStore,CN=, where  is the name of your administrative group,   the name of your Exchange server, and   the name of the storage group that hosts the public or private information store.
 * In the right pane, right-click the private store or the public store, and then click Properties.
 * In the Attributes list, click msExchAgingKeepTime.
 * Set the attribute to the decimal value in seconds that you want.

Note Without this registry entry, the default setting for the Aging Keep Time value is 40 days for Exchange 2000 Server and for Exchange Server 2003. Exchange 2000 Server and Exchange Server 2003 store the value in seconds. Forty days is equal to 3,456,000 seconds. To set the new Aging Keep Time value to four days, type 345,600.
 * Stop the Microsoft Exchange Information Store service, and then restart it.
 * To change this setting in the Windows Registry, follow these steps:
 * Start Registry Editor (Regedt32.exe).
 * For Exchange 2000 Server or for Exchange Server 2003, locate the following key in the registry:

Note  is the Globally Unique Identifier for the store. Replace "Public- " with "Private- " to change the setting for a private mailbox store.
 * Add an Aging Keep Time value of the REG_DWORD type.
 * Enter the decimal value in seconds that you want.

Note Without this registry entry, the default setting for the Aging Keep Time value is 40 days for Exchange 2000 Server and for Exchange Server 2003. Exchange 2000 Server and Exchange Server 2003 store the value in seconds. Forty days is equal to 3,456,000 seconds. To set the new Aging Keep Time value to four days, type 345,600.
 * Quit Registry Editor.
 * Stop the Microsoft Exchange Information Store service, and then restart it.

<ul> Exchange Server 4.0, Exchange Server 5.0, or Exchange Server 5.5

The Aging Keep Time value is set by using a registry value. To decrease the Aging Keep Time value, follow these steps: <ol> Start Registry Editor (Regedt32.exe).</li> For Exchange Server 5.5, locate the following key in the registry:

Note Replace "ParametersPublic" with "ParametersPrivate" to change the value for a private mailbox store.</li> Add an Aging Keep Time value of the REG_DWORD type.</li> Without this registry entry, the default setting for the Aging Keep Time value is eight days for Exchange Server 4.0, for Exchange Server 5.0, and for Exchange Server 5.5. Exchange Server 4.0 and Exchange Server 5.0 store this value in milliseconds. Eight days is equal to 691,200,000 milliseconds because 1000*60*60*24*8 = 691,200,000.Exchange Server 5.5 stores this value in seconds. Eight days is equal to 691,200 seconds because 60*60*24*8 = 691,200. To set the new Aging Keep Time value to one day, set the value either to 86,400,000 for Exchange Server 4.0 and for Exchange Server 5.0 or to 86,400 for Exchange Server 5.5.

Note This value is entered as decimal.</li> <li>Quit Registry Editor.</li> <li>Stop the Microsoft Exchange Information Store service, and then restart it.</li></ol> </li></ul>

If this value is still not low enough, then decrease the values until you reach an acceptable level of performance. However, you may also have to decrease the Aging Clean Interval value from its default value of 1 day, as outlined in the "Aging Clean Interval" section in this article.

Aging Clean Interval
The Aging Clean Interval value is the interval (in seconds for Exchange Server 4.0, 5.0, and 5.5) at which the information store checks for anything that must be removed from the cache. The default value is 24 hours (or 86,400 seconds). To decrease the Aging Clean Interval value for information store, modify the registry to decrease the Aging Clean Interval value for the information store: <ol> <li>Start Registry Editor (Regedt32.exe).</li> <li>Locate the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

</li> <li>Add an Aging Clean Interval value of the REG_DWORD type.</li> <li>By default the Aging Clean Interval value without this registry entry is set to 86,400 (or 1 day in seconds, 60*60*24). Set the new Aging Clean Interval value to a number less than 86,400.

Note This value is decimal.</li> <li>Quit Registry Editor.</li> <li>Stop the information store service, and then restart it.</li></ol>

Running Isinteg
You can run the Isinteg utility to force cleanup of the cached restrictions immediately. The following occurs:
 * Your backlinks are purged.
 * The restriction tables are deleted.

If there are a large amount of restrictions against a folder and you run the isinteg -fix command, these cached searches are all cleared and your folder performs normally. In Exchange Server 5.5, use the following command:

isinteg -fix -pri -test morefld

In Exchange 2000 Server and in Exchange Server 2003, use the following command:

isinteg –s  –fix –test morefld –l  

Note  is the name of your Exchange computer, and   is the name of a file to write the output text to.

Microsoft Exchange Information Store Integrity Checker v5.5.265

Copyright (c) 1986-1997 Microsoft Corp. All rights reserved.

Started: 04/28/00 19:06:08

Server name: Server.domain.com

Store path: D:\exchsrvr\MDBDATA\PRIV.EDB

Store size: 1510031360 bytes

Output log: isinteg.pri

Check mode: check and fix

Options: -fix -pri -test morefld

Starting test 1 of 3, 'Categorization Tables'

Finished Categorization Tables. Time: 0h:0m:0s

Starting test 2 of 3, 'Restriction Tables'

Finished Restriction Tables. Time: 0h:0m:0s

Starting test 3 of 3, 'Search Folder Links'

Finished Search Folder Links. Time: 0h:0m:23s

No reference count tests

<div class="moreinformation_section">

MORE INFORMATION
There are two methods you can use to search on a folder with Extended MAPI, the Restrict method and the FindRow method. The Restrict method caches the restriction on that folder and is not removed for several days. If the view, filter, or search is using an ever-changing primary index, a new restriction is added each time that the folder is called. This can lead to a severe decrease in the performance of the folder, because every time a change is applied, all the back links have to be accessed.

For additional information about how to control folder index aging, click the following article number to view the article in the Microsoft Knowledge Base:

159197 Controlling folder index aging

Collaboration Data Objects (CDO) 1.21 can also cause the problem. CDOs MessageFilter object is implemented as a MAPI Restrict. If possible, CDO code which relies on MessageFilter should be replaced with equivalent Extended MAPI code using FindRow. This is not always possible though. For instance, CDO code which searches appointments cannot be replaced with Extended MAPI because Extended MAPI does not understand appointment items. In this case, the CDO code should be reevaluated to see if the number of different MessageFilters can be reduced.

<div class="references_section">