Maximum cached views has been modified

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2010-07-21

The Microsoft® Exchange Best Practices Analyzer Tool queries the Active Directory® directory service to determine whether the maximum number of cached views per database has been modified. If the Exchange Server Analyzer finds that the msExchMaxCachedViews attribute has been changed from its default of 11, the Exchange Server Analyzer displays a non-default configuration message. The number of cached views that you have configured per database is included with the Analyzer tool output. It is a best practice to have between 5 and 20 cached views.

The msExchMaxCachedViews is an attribute of the msExchangePrivateMDB object class. Therefore, each mailbox database store object in Active Directory has an msExchMaxCachedViews attribute value. The msExchMaxCachedViews attribute value specifies the maximum number of views that are cached for a specific folder in a mailbox. In this context, "view" refers to the folders that are displayed when a user accesses another user's Microsoft Office Outlook mailbox. When users share access to an Outlook folder with other users, Exchange Server generates a view that hides private items.

When an Outlook user first views someone else's calendar, contact folder, or other data, the user may experience delays. After the user has viewed the folder, the user may experience quicker views on subsequent attempts, but after a period of time, the user may experience delays when the user tries to access the folder again. This delay is generally most noticeable when the folder contains a large number of items. In Exchange Server 2007 or in an earlier version, a large number is 5,000 items or more.

In Exchange Server 2010, a large number is 100,000 items or more.

The act of applying a view to a folder creates search folders in the Exchange store for each unique user who accesses the Outlook folder. When a search folder is created, it is cached for later use. Before Exchange Server creates a new search folder, it determines whether that search folder already exists. If the search folder exists, Exchange Server uses the cached search folder to accelerate subsequent viewings.

The msExchMaxCachedViews attribute defines how many search folders are cached in a specific folder. For example, the msExchMaxCachedViews attribute can define how many search folders are cached in the Calendar folder.

If you have many users who share Outlook folders, you must decide how to balance server resourcing and acceptable client performance. When a search folder is cached, a search folder is kept up-to-date as the data in the search folder changes. Such updates use CPU and disk resources. If multiple caches of the search folder are being maintained, CPU performance and disk performance are further impacted.

On the other hand, when Exchange Server creates a search folder for the first time, the user who accesses the Outlook folder may experience a delay as the search folder is built.

For example, consider an Exchange Server that is configured with 11 search folders. Eleven is the default number of search folders. UserA shares her Calendar folder with 15 other users. UserB accesses the folder and experiences a delay while his search folder is built. After the search folder for UserB is created, access to UserA's Calendar folder is quick. Assume UserB does not access the folder for the rest of the day. In the meantime, if 11 other users access the folder, unique search folders are created for them. Because only 11 search folders are cached, the next time UserB accesses UserA's Calendar, UserB again experiences a delay while a new search folder is built for him.

The best practice is to limit the maximum number of search folder caches to 20 or less. When you exceed this number, especially for folders that have more than 5,000 items in them, you may overload the server as the server tries to maintain the cached folders.

Additionally, it is a best practice to have no less than five caches. If users are sharing Outlook folders with multiple users, caching only four search folders negatively affects client experience and causes the server to use more resources on creating new caches more often.

The msExchMaxCachedViews attribute also can be set on public folder databases. Search folders also are built for public folders. By default, public folders are shared resources that many users may access. If public folders receive many posts, you should minimize search folders because the Exchange Server may experience heavy CPU and disk use as it updates the search folders. Additionally, it is not a best practice to try to optimize the client experience by providing many search folder caches if many different users access a public folder. It is likely that these caches will be discarded as new search folders are created for new users.

Warning

If you modify the attributes of Active Directory objects incorrectly when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To complete this procedure, you must have the ADSI Edit tool. For more information about ADSI Edit, see ADSI Edit (adsiedit.msc).

To modify the msExchMaxCachedViews attribute

  1. Start ADSI Edit.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

    • InformationStore

    • Storage_Group_Name

  3. In the details pane, right-click Database_Name, and then click Properties.

  4. In the Attributes box, double-click msExchMaxCachedViews.

  5. In the Integer Attribute Editor dialog box, enter an integer between 5 and 20 in the Value field, and then click OK.

  6. Click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication, and then restart the Microsoft Exchange Information Store service on the Exchange Server where you made the modification.