Cached Restricted Views Default

Not open for further replies.


I believe that Exchange 2010 still defaults to 11 cached restricted views like our current EX2003.

Anybody got any views on increasing this when I put 2010 in to say 15-20.

We have a lot of shared mailboxes, shared calendars and high numbers of users for each on EX2003.
They get a lot of the waiting on server pop-ups currently with OL2003 even with low item count folders - We are moving to OL2007 presently however.

So question is does the assembly think that the 2010 search index being enabled unlike 2003 and generally faster servers will make enough difference that I won't need to update the cached views level or that I should go ahead and bump it up anyway in the new environment to save mucking around later?


Milind Naphade


What I understand from your description is you are worried about the end user experience that may get hampered due to slow view updates. Views is the store functionality maintained per mailbox accessing a shared folder(s).

Exchange 2003 store had little troubles with this functionality due to its random way to handle IOs. However, larger and sequential IOs of Exchange 2010 store architecture can certainly improve the performance.

If you do not have many items in the folder which are shared (this also includes Public Folders) then I would suggest not changing anything or not to worry about it much. To the best of my understanding about cached views, they are generated and vanished as per the requirement. If the store is optimized to handle these transations then I would not really worry about it. However, if you see any issues even after moving to Exchange 2010 then you can perhaps change the values between 11-20 anywhere.

Milind Naphade | MCTS:M (Exchange 2007 and 2010) |


Related reference:

“When a user has gone beyond the number of indexes that Exchange will store, which for Exchange 2010 is 11 indexes. When the user chooses to sort a new way, thereby creating a twelfth index, it causes additional disk I/O. Because the index is not stored, this disk I/O cost occurs every time that sort is done. Because of the high I/O that can be generated in this scenario, we strongly recommend storing no more than 100,000 items in core folders”

James Luo

Not open for further replies.