This shared mailbox - how big is it? Hos much data, how many items, how many folders? Large numbers of items and folders can seriously impact the performance of a mailbox, especially when multiple people are opening it at the same time.

If you want to move this mailbox to another DB, and it has a large number of corrupt items in it (more than 50), you may need to move it with the shell:

New-MoveRequest -Identity [mailbox] -TargetDatabase [DBName] -BadItemLimit 99999 -AcceptLargeDataLoss

Select allOpen in new window

http://technet.microsoft.com/en-us/library/dd351123.aspx

And it might take a really long time to move, during which time you will just need to wait.

The mailbox is 14 GBytes with 288000 items in it. However I have larger mailboxes, e.g. 16 GBytes with 377000 items in them, in the same database on the same server so right now I don't think size is the problem.

What about folders? In my experience, very large numbers of folders have the most impact on mailbox performance. (We have a 20GB mailbox with over 2,000,000 items in it, spread over thousands of folders, and it's awful.)

The default limit for connected users on objFolder is 500, so if you've got about that many folders under Inbox, say, you're bumping into the limit, and Exchange is disconnecting the user connection. That limit (as well as objMessage and others) can be increased with a registry setting change, with the caveat that server performance may be impacted.

And even with the limits up, it'll still be slow enumerating all the folders. It just won't disconnect the users. So, if that's the issue, it might be time to think about rearranging data in that mailbox, archiving, using some other data collection point that isn't an Exchange mailbox.

---

But - if, as you suspect, that's not the issue, it's more than likely due to corrupt items in the mailbox. Moving it was the right instinct. Make sure you clear the previously canceled move request, and try it again with the -BadItemLimit and -AcceptLargeDataLoss switches.

It second the item count issues.

MS recommends that you only have about 5,000 items per folder. I have users that have up to 700,000 messages in their Inbox at a modest 9GB total.  Access is slow as molasses, especially if they have grouping enabled under "View>Arrange By> Show in Groups" in Outlook.  It takes CPU time to get it into those formats.

I was only successful in getting them to get it down to about 20,000 messages per folder.  That was a very decent improvement on their access time.

I would really recommend that you try to get the user(s) to get their folder system down to a manageable tree structure that don't have more than 5,000 messages with the overall size of the account at less than 2GB in size.

If these are VIPs that you are dealing with; at least get them to turn off the grouping in Outlook to improve on performance.  OWA is kinda SLO as they will have to contend with the added issues of x number of message headers being download to their machines to represent what is in the folder they are viewing.

sorry

That 5,000 item ceiling really only applies to the default folders, Inbox, Sent Items, etc. User-created folders you can put 100K items in.

There's a slight possibility that you're getting some database corruption somewhere. With having users disconnect, were you able to narrow it down to that one mailbox any more specifically?

I still really like the idea of moving that suspect mailbox to a new database (not a different one, a new one), and it wouldn't hurt to move the rest of the mailboxes in that database to that same new DB (or a second new one). That way, if the current DB is experiencing some corruption, you'll be rid of it, and get some white space recovery while you're at it.

Hello,

thanks again for the feedback. It's been a few days now and still no re-occurrance of the problem. It looks like the shutting down of the clients was the cure for this one. It's strange because the user desktops are really locked down so I don't think installing extra software is the cause (e.g. search/indexing). I see that Exmon has been updated for 2010, I'm not sure why that hasn't been included in the standard release. I'll install that and hopehully that will help if there is ever a next time.

Everyone else was stating database/mailbox corruption as the problem. They missed that I saw an increase in CPU utilisation as well as mailbox slowness. Once I asked staff to close their mailbox  the server CPU utilisation dropped and the mailbox was immediately returned to full speed. I assume that Exchange 2010 throttling was both the cause & saviour (i.e. I didn't have an entire estate complaining about speed) however I am happy to be corrected. I am also suprised that nobody suggested looking at client activity, which is why I mentioned that ExMon has been updated for 2010. I'd have thought that Microsoft would have included that in the standard product by now... Anyway, I am glad that people responded and offerred their experience. Thank you.