Exchange 2007, Windows 2008, Outlook 2007 environment. Multiple Exchange servers, each hosting dedicated role (mailbox, HT, CAS). On one server, we have users of SHARED mailboxes saying that access to these shared mailboxes is slow. Basically, their Outlook client is hanging. OWA is the same when accessing the shared mailboxes. If they access OWA to their personal mailboxes (which are on the same server) or remove the shared mailboxes from their Outlook profile, then everything is ok. Thus, the problem is with the shared mailboxes. There are a group of these that are affected. Very strange. But I don't know what the cause would be? These shared mailboxes are around 3GB in size. Is there a maximum recommended size for Exch 2007 mailboxes? How about item count or number of folders etc before this sort of problem may occur? In terms of troubleshooting, can I find out if a particular client is causing this slowness by carrying out large amounts of work? Is it possible that one client is perhaps moving a large number of emails within the mailbox to another folder and that is causing the hang?

Item count is the key. The size doesn't really matter, other than the fact that by default shared mailboxes are coming across the wire live, whereas personal mailboxes will be cached. You should try and keep the inbox and other key folders below 5000 items. Above that and things will start to struggle. That is an Outlook issue, not Exchange. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Sambee is correct you can investigate whether increasing the msExchMaxCachedViews will help. Always understand that when upping values you may actually be placing more load on your server than the benefit. However, I would start out by reducing the per folder item count to less then 5000. Restricted Views and Shared Calendars When you view someone else's Calendar, Contacts folder, and so on, there may be delays before the folder can be viewed. When the folder has been viewed, switching away and back is fairly quick. But after a time, accessing the folder will become slow. The delay will be especially long if the number of items in the calendar is over 5000. When Outlook accesses someone else's folders, it applies a view which restricts the user from viewing private items. The act of applying a view to a folder creates search folders in the store. When a search folder is created, it is cached for later use. If a user tries to create a search folder which already exists, the cached search folder is used. This allows future viewings to be fairly quick. By default, Exchange does not cache all search folders indefinitely. Caching too many search folders would cause server-side delays associated with updating the search folders. Conversely, if a sufficient number of search folders are not cached, a similar problem will occur as search folders must be generated and updated. To illustrate the issue, consider the scenario where an Exchange server has been configured to keep 11 search folders (views) per folder. Suppose Frank has a calendar folder that he shares out to 15 other users. Sally accesses the folder and sees a delay while her search folder is built. After it is built, access is quick. Then Sally does not view the folder for a day and 11 other users access the folder. A new search folder will be built for each of them. Because only 11 search folders are cached, when the twelfth user hits the folder, Exchange will delete the search folder that was built for Sally. Now, the next time Sally hits the folder, she'll have to wait while Exchange builds her search folder. Suppose we configure Frank's Mailbox server to cache 20 views instead. Then Sally and the other 14 users can all hit Frank's calendar folder, and only 15 search folders will be created. Because 15 is less than 20, we never have to cycle out a view, so access is quick for everyone after the initial hit to create the search folders. The default number of cached search folders is 11. This configuration is set at the database level. The configured value can be viewed by using ADSIEdit. Use ADSIEdit to view the Store object, and then examine the msExchMaxCachedViews attribute. The distinguished name is as follows: CN=Database, CN=Storage Group,CN=InformationStore,CN=Server NAME,CN=Servers,CN=AG Name,CN=Administrative Groups,CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com. In some cases, modification to increase the value greater than 11 can be useful to tune the performance impact on an environment. Understanding the Performance Impact of High Item Counts and Restricted Views http://technet.microsoft.com/en-us/library/cc535025(EXCHG.80).aspx James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com