DOCUMENT:Q216076 11-JUN-2002 [exchange] TITLE :XADM: Information Store Folders May Become Slow and Unresponsive PRODUCT :Microsoft Exchange PROD/VER::1.0,1.21,4.0,5.0,5.5 OPER/SYS: KEYWORDS:exc4 exc5 exc55 ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange Server, versions 4.0, 5.0, 5.5 - Microsoft Exchange 2000 Enterprise Server - Microsoft Exchange 2000 Server - Microsoft Extended Messaging Application Programming Interface (MAPI), version 1.0 - Collaboration Data Objects (CDO), version 1.21 ------------------------------------------------------------------------------- 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: Q256986 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 a 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 ------ 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, perform the following steps: a. Start the Registry Editor (Regedt32.exe). b. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic c. Add a Reset Views value of the REG_DWORD type. d. The default of the Reset Views value, without this registry entry, is 0. Set the value to 1. e. Quit the Registry Editor. - "The Private Information Store": To modify the registry key to change the Reset Views value for the private information store, perform the following steps: a. Start the Registry Editor (Regedt32.exe). b. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate c. Add a Reset Views value of the REG_DWORD type. d. The default of the Reset Views value, without this registry entry, is 0. Set the value to 1. e. Quit the Registry Editor. 2. Stop the information store service, and then restart it. 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 ------ 1. Stop the information store. 2. At a command prompt, go to the Exchsrvr\Bin folder and run the following command: isinteg -pri|pub -dump -l logfilename WARNING: This command dumps details of all of the folders in the specified database. Depending on the size of the database, the log file that is produced may be quite large. 3. 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. WORKAROUND ========== To work around this behavior, decrease the "Aging Keep Time" value for the affected database (either the public or private information store) from the default of 8 days to 1 day. Aging Keep Time --------------- To decrease this value, perform one of the following procedures, as applicable: - Public Information Store: To modify the registry key to change the Aging Keep Time value for the public information store: 1. Start the Registry Editor (Regedt32.exe). 2. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic 3. Add an Aging Keep Time value of the REG_DWORD type. 4. The default for the Aging Keep Time value, without this registry entry, is 8 days. Exchange Server 4.0 and 5.0 store this value in milliseconds (8 days in milliseconds is 691,200,000: 1000*60*60*24*8 = 691,200,000), and Exchange Server 5.5 stores this value in seconds (8 days in seconds is 691,200: 60*60*24*8 = 691,200). To set the new "Aging Keep Time" value to 1 day, set the value to either 86,400,000 for Exchange Server 4.0 and 5.0, or 86,400 for Exchange Server 5.5. If you require a lower value, be sure you remember that Exchange Server 4.0 and 5.0 use milliseconds, and Exchange Server 5.5 uses seconds. NOTE: This value is entered as decimal. 5. Quit the Registry Editor. - Private Information Store: To modify the registry key to change the Aging Keep Time value for the private information store: 1. Start the Registry Editor (Regedt32.exe). 2. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate 3. Add an Aging Keep Time value of the REG_DWORD type. 4. The default for the "Aging Keep Time" value, without this registry entry, is 8 days. Exchange Server 4.0 and 5.0 store this value in milliseconds (8 days in milliseconds is 691,200,000: 1000*60*60*24*8 = 691,200,000), and Exchange Server 5.5 stores this value in seconds (8 days in seconds is 691,200: 60*60*24*8 = 691,200). To set the new "Aging Keep Time" value to 1 day, set the value to either 86,400,000 for Exchange Server 4.0 and 5.0, or 86,400 for Exchange Server 5.5. If you require a lower value, be sure you remember that Exchange Server 4.0 and 5.0 use milliseconds, and Exchange Server 5.5 uses seconds. NOTE: This value is entered as decimal. 5. Quit the Registry Editor. 6. Stop the information store service, and then restart it. If this value is still not low enough, then decrease the values until you reach an acceptable level of performance. However, you also need 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 needs to be removed from the cache. The default value is 24 hours (or 86,400 seconds). To decrease the "Aging Clean Interval" value for either the public or private information store, use one of the following methods, as applicable: - "Public Information Store": To modify the registry key to decrease the Aging Clean Interval value for the public information store: 1. Start the Registry Editor (Regedt32.exe). 2. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic 3. Add an "Aging Clean Interval" value of the REG_DWORD type. 4. The default of the "Aging Clean Interval" value, without this registry entry, is 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 entered as decimal. 5. Quit the Registry Editor. - "Private Information Store": To modify this registry key to change the "Aging Clean Interval" value for the private information store: 1. Start the Registry Editor (Regedt32.exe). 2. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate 3. Add an Aging Clean Interval value of the REG_DWORD type. 4. The default of the Aging Clean Interval value, if this registry entry is absent, is 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 entered as decimal. 5. Quit the Registry Editor. 6. Stop the information store service, and then restart it. For example, to clear the cache twice a day, perform the following steps: 1. Set the "Aging Keep Time" value to a low setting (1 hour = 3,600 seconds). 2. Set the "Aging Clean Interval" value to 43200. 3. The cache is cleared during information store maintenance, so run information store maintenance every 12 hours. For additional information about information store maintenance, click the article number below to view the article in the Microsoft Knowledge Base: Q159196 XADM: Tasks Controlled by the Information Store Maintenance Schedule 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. isinteg -fix -pri -test morefld 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 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 controlling folder index aging, click the article number below to view the article in the Microsoft Knowledge Base: Q159197 XADM: 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 reevalutated to see if the number of different MessageFilters can be reduced. Additional query words: poor slow outlook filter blackberry bes restrict ====================================================================== Keywords : exc4 exc5 exc55 Technology : kbAudDeveloper kbCDOsearch kbMAPISearch kbExchangeSearch kbExchange500 kbExchange550 kbExchange400 kbZNotKeyword kbZNotKeyword2 kbExchange2000Search kbCDO121 kbExchange2000Serv kbExchange2000EntServ kbMAPIExt Version : :1.0,1.21,4.0,5.0,5.5 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.