The Bad Item Conundrum (or, How much data would you like MRS to drop?)

My recent article “Corrupted Items and Mailbox Moves in Exchange 2010” provoked some comments about the number of corrupt items that are met when administrators attempt to move mailboxes as well as some suggestions as to how you might reduce the problem.

A “bad item” to Exchange 2010 is an item that the Mailbox Replication Service (MRS) considers to be corrupt in some form when it attempts to process the item. The most common scenario is when MRS moves a mailbox, but bad items also come into play when MRS imports or exports mailbox data from or to a PST.

The default bad item threshold for MRS is zero. In other words, unless you explicitly tell MRS otherwise, it will attempt to process every single item, and if corruption is met in any item, MRS will halt the operation. You can restart a mailbox move or PST import/export by changing the properties of the MRS request with a higher bad item threshold and then resuming the operation. For example, commands like this might be used to set a higher bad item limit for a mailbox move and then resume it:

Set-MoveRequest -Identity “TRedmond” -BadItemLimit 20

Resume-MoveRequest -Identity “TRedmond”

Unfortunately, you can only amend the bad item threshold using the Exchange Management Shell (EMS) as the Exchange Management Console (EMC) interface dealing with mailbox move requests doesn’t allow access to this property. And of course, EMC doesn’t have any UI at all for dealing with PST imports and exports.

Avoiding the need to intercede with stalled requests is one reason why administrators usually specify a higher bad item threshold for mailbox moves (in particular). This is especially so when you’re moving mailboxes from older versions of Exchange as all of the evidence indicates that there’s a far higher chance that corruption lurks in mailboxes hosted on older servers. One reason why this might be so is that older versions of Exchange usually support older clients: most corruptions are caused by MAPI clients that fail to update properties to the satisfaction of MRS. Another reason is that the Exchange Store has become better and better as the versions have rolled by, meaning that there are fewer corruptions caused by server bugs in Exchange 2010 than previous versions.

It’s also true that Exchange 2010 mailboxes are “cleansed” by MRS every time they are moved. In fact, those of us that remember when it was common practice to take databases offline to run ESEUTIL to rebuild their internal structures (colonic irrigation for databases) could think of an MRS move mailbox operation in similar terms because essentially all of the mailbox structures are rebuilt by MRS when it moves the mailbox from one database to another.

One good piece of advice I heard from another Exchange MVP is to run ISINTEG on databases before attempting to move mailboxes from an Exchange 2003 server. This makes sense because ISINTEG is all about fixing minor logical corruptions within Exchange databases and so might well remove some of the lurking corruptions that MRS will complain about when it moves mailboxes. I don’t think this step is necessary for Exchange 2007 databases and it’s absolutely useless for Exchange 2010 as ISINTEG is replaced by a new set of store “online fix” cmdlets in this release.

Other pieces of good advice about preparing for successful mailbox moves include 

The bad item threshold can go as high as 2,147,483,647. This is a nice number but it’s unreasonable. A more practical value is somewhere in the 10 to 100 range. However, the critical point to remember here is that MRS drops bad items. In other words, if MRS meets an item it deems to be corrupt, it won’t process that item and so the item won’t make it into the destination mailbox or PST. Most of the time this doesn’t matter because the item is probably corrupt in such a way that a client can’t access it anyway, but if you run mailbox moves with a bad item threshold of 100, you’re saying that MRS can cheerfully discard up to 100 items while it does its work. I have a nagging feeling that something important might be present in 100 items but maybe not. In any case, the Exchange developers force you to accept the responsibility for your actions once you specify a bad item threshold higher than 50 by requiring you to include the AcceptLargeDataLoss parameter when you create the request.

The bad item conundrum is determining the right threshold. Zero is good from the perspective that MRS will never drop anything, but bad in that you’ll spend a lot of time managing stalled move requests. Ten to twenty is a range that should allow the vast majority of mailbox moves to complete without administrator intervention. Above this we start to get into the realm of increasing data loss. You might view this as a way to help users clear out useless crap from their mailboxes; they might view it as an unjustifiable assault on their most precious possessions. I don’t know your users so I can’t say how they’ll react. But I’m sure you do…

Follow Tony @12Knocksinna