Ongoing Indexing Issues on DAG02 - Our fix!

This is an update to: Ongoing Indexing Issues On DAG02

After a few tries at getting this indexing issue fixed, even with the help of Microsoft, I came to believe there was mailbox corruption causing this problem. The only trick was how to find it. 

First thing we did was move the active databases to another server one by one to see if the problem moved. We isolated it to our 'ServiceAccount' mailbox database fairly quickly. Whatever server that database was active, the indexing would hang or fail.

The best way I know how to get rid of a mailbox with corruption is to move that mailbox to another database. But these were service account mailboxes and shared mailboxes. Some of which were high profile and very visible. We moved a few large mailboxes out to another database -- we told the user they would get better performance. And they did! 

We continued killing two birds with one stone moving very large mailboxes and shared mailbox to their own databases, But we never actually moved the right mail box. The problem remained.

One day, on a whim,  I ran a Get-MailboxFolderStatistics on that database to see if it triggered anything. One mailboxes reported this odd error consistently:

Unable to retrieve mailbox folder statistics for mailbox domain.com/ServiceAccounts/Application_Admin. Failure: Microsoft.Exchange.Data

.Storage.StorageTransientException: The process failed to get the correct properties. ---> Microsoft.Mapi.MapiException

NotEnoughMemory: MapiExceptionNotEnoughMemory: Unable to get properties on object. (hr=0x8007000e, ec=1008)

Diagnostic context:

    ......

A little research on "... MAPIExceptionNotEnoughtMemory ..." and I found this meant the folder structure was caught in an endless loop of some kind. I can't recall the exact answer, nor the link.

What I do recall is we moved this mailbox to another mailbox database on our public folder server by itself. And the problem followed it. Our indexing issue on DAG02 was solved.

After the move, we disabled the mailbox for that service account and then created a new mailbox. I ran the folder statistics command and it was good! I started up the app and the problem came back. Just to be sure, I did all that again. Still as soon as I started up the app, the mailbox indexing crapped out. So there is no real way of fixing this mailbox. The application is doing something to the mailbox it needs, but Exchange hates!

Of course this is not a real fix -- it's an 'ignore' at best. At least our users are not effected by the indexing suddenly crapping out anymore.

And I am not going to claim this work around will fix all indexing woes, but I will certainly check next time I see it.