none
Identifying "corrupt" mailbox items in Exchange 2010 SP1 prior to mailbox move?

    Question

  • Is there no way to identify corrupt mailbox items prior to moving a mailbox between Exchange 2010 servers?

    The New-MailboxRepairRequest command with the -DetectOnly option does not appear to address individual mailbox items.

    The usual advice to keep retrying the move with an ever-increasing BadItemLimit is just silly unless you are doing this in a lab environment.  In a production environment the "corrupt" items need to be addressed without users losing data that may be of value to them.

    Thanks

     

     

     

     

     

     


    • Edited by sime3000 Friday, October 14, 2011 1:44 AM
    Friday, October 14, 2011 12:51 AM

All replies

  • New-MailboxRepairRequest is basically the online version of the old ISINTEG. We recently had a blue screen, the first ever on one of the Exchange servers. The command below fixed all corruption.

    The interface is a bit of lackluster. You'll have to look out for these events in the Event Viewer.

    New-MailboxRepairRequest -Database DB1 -CorruptionType Folderview, SearchFolder, AggregateCounts

    Event 10047 hen the repair is initiated
    Event 10062 when a corruptions is found and repaired
    Event 10048 when the repair completes successfully

    You may need to run this command several times before all corruptions are eliminated and event 10048 is reported.

    I would start this way, and then proceed with no BadItemLimit, and yes increase it slightly. There are types of corruption that are not fixed by ISINTEG or New-MailboxRepairRequest.


    MCTS: Messaging | MCSE: S+M
    Friday, October 14, 2011 5:08 AM
  • New-MailboxRepairRequest is basically the online version of the old ISINTEG. We recently had a blue screen, the first ever on one of the Exchange servers. The command below fixed all corruption.

    The interface is a bit of lackluster. You'll have to look out for these events in the Event Viewer.

    New-MailboxRepairRequest -Database DB1 -CorruptionType Folderview, SearchFolder, AggregateCounts

    Event 10047 hen the repair is initiated
    Event 10062 when a corruptions is found and repaired
    Event 10048 when the repair completes successfully

    You may need to run this command several times before all corruptions are eliminated and event 10048 is reported.

    I would start this way, and then proceed with no BadItemLimit, and yes increase it slightly. There are types of corruption that are not fixed by ISINTEG or New-MailboxRepairRequest.


    MCTS: Messaging | MCSE: S+M


    Thanks for your reply Jon. I ran the New-MailboxRepairRequest command with those options and -DetectOnly against a mailbox that the move process flagged as having "corrupted" items.  New-MailboxRepairRequest found absolutely nothing wrong with the mailbox - it doesn't check individual items in the mailbox afaik.

    Increasing the BadItemLimit value during repeated retries of a single mailbox move and having it lose messages is silly on many levels unless you do not care about your users data and business implications of losing that data.

     

     

     

     

    Friday, October 14, 2011 5:22 AM
  • If you do not want to loose items just perform an export to an PST file before you move the mailbox.

    When you import the item after a mailbox move the messages will be created again.

    The questioni s: Why do you have so many corrupted items in the mailbox.


    Thomas Stensitzki - MCPD, MCITP, MCTS, MCSA, MCSA:Messaging
    Friday, October 14, 2011 10:16 AM
  • If you do not want to loose items just perform an export to an PST file before you move the mailbox.

    When you import the item after a mailbox move the messages will be created again.

    The questioni s: Why do you have so many corrupted items in the mailbox.


    Thomas Stensitzki - MCPD, MCITP, MCTS, MCSA, MCSA:Messaging


    I've been doing these moves for many years for different clients and I have moved tens of thousands of mailboxes during different migrations.  What we typically do is have the user delete the "corrupted" item if they do not need it, and if they do we copy the item off somewhere then delete it. Its a waste of everyones time all around.  Archiving these mailboxes to a PST or just the ones with "corrupted" items is a giant waste of time and is bound to cause other issues.

    The question is not why do we have so many "corrupted" items in a mailbox - we didn't say that.  The "corrupt" items show up during every migration in a small percentage of mailboxes at all of my clients.  In every case the databases are are well maintained and there have been no hardware related issues that someone could blame as the cause of the "corruption".

    The questions really are:

    1) What exactly is a "corrupted" item and how does Microsoft determine that during the mailbox move ?

    2) Why can we not check the integrity of all of the data in a mailbox prior to a move and take action to address it before wasting time during a move process - obviously Microsoft knows what a "corrupt" item is during a move.

    3) Why as of Exchange 2010 when the product has been around for about 15 years do we still have a ridiculous procedure which says to keep re-running the move with an ever increasing BadItemLimit until the move eventually works, and lets not talk about the user data that you just lost.

    I've been doing this long enough that I am convinced that these "corrupt" items are not actually corrupt or if they are that the corruption is caused by Microsoft code.

    Microsoft really needs to address this "corruption". ;-)

     

     

     

     





    • Edited by sime3000 Friday, October 14, 2011 5:17 PM
    Friday, October 14, 2011 1:17 PM
  • Hi sime3000,

     

    When you try to use New-MailboxRepairRequest command, here is a related document for you:

     

    Exchange 2010 SP1: New-MailboxRepairRequest

    http://blogs.technet.com/b/nawar/archive/2010/08/19/exchange-2010-sp1-new-mailboxrepairrequest.aspx

     

    Please note that, you have to include " –CorruptionType" when you run this command.

     

    Thanks,

     

    Evan

    Tuesday, October 18, 2011 9:16 AM
  • Hi sime3000,

     

    When you try to use New-MailboxRepairRequest command, here is a related document for you:

     

    Exchange 2010 SP1: New-MailboxRepairRequest

    http://blogs.technet.com/b/nawar/archive/2010/08/19/exchange-2010-sp1-new-mailboxrepairrequest.aspx

     

    Please note that, you have to include " –CorruptionType" when you run this command.

     

    Thanks,

     

    Evan


    Hello Evan,

    and here is a url for you: http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8d78e08b-4ef9-4b28-a322-98a9dbc436e5 (its the url for this thread).

    If you read the thread you would understand that New-MailboxRepairRequest with the –CorruptionType option will do nothing to address the reported "corruption" of individual mailbox items which is what this thread is about.

    Wednesday, October 19, 2011 3:48 AM
  • Hi sime3000,

     

    Sorry that I didn’t explain clearly.

     

    I know you have run the New-MailboxRepairRequest. In my last post, I only want you follow the document to run again, check for the Event IDs “10044,10045,01146,10047,10048,10049,10050,10051,10059,10062” , to see whether there is any related information for the command (New-MailboxRepairRequest).

     

    You can know more detail for these Event IDs from this document:

     

    View Mailbox Repair Request Entries in Event Viewer

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

     

    Thanks,

     

    Evan

    Wednesday, October 19, 2011 5:33 AM
  • Hello Evan,

     

    When I run New-MailboxRepairRequest, events 10047 and 10048 appear. i.e. Integrity check started and Integrity check completed successfully.

    Again, this command does not check individual items in a mailbox for "corruption", it checks for folder related issues.

    So the question remains, how does one check for "corruption" of individual items in a mailbox so that they can be addressed prior to conducting a mailbox move ?

     

     

    Wednesday, October 19, 2011 4:12 PM
  • Hi Evan,

    I don't have a solution for your Problem. I just want to say that I agree to you: We migrated about 1600 Mailboxes from Exchange 2003  to Exchange 2010 the last months and nearly all of the "corrupted" items the local move wizzard finds seem to be ok.

    I had a closer look with the users together. The main problem seems to be old calendar conflikt objects maybe from the exchage 5.5 migration whitch microsoft does not support anymore. The Items in the outlook mailboxes of the users behave as if they are ok - only the wizzard seems to have a problem.

    It would be realy nice to have all corrupted Items detected at once.

    Wednesday, October 19, 2011 5:44 PM
  • What we ended up doing was moving everyone like normal.  For users that flagged as corrupted they got put into a pool to try again.  When we came to do those, we up'd the bad item count to 10 and then told it to suspend when ready to complete.  Verified with the users for any data lose and then resumed the move to finish it off.  Saved a lot of time rather then having to redo it each time and bumpted the baditemcount by 1 or 2 per attempt.

    Wednesday, October 19, 2011 7:00 PM
  • Thank you for explaining the moderator what the Powershell Command does AND what not. I had to do that a few weeks ago with same person and Schema Changes on a 2010 Migration.

    Normaly when we have "Corrupt" items those are appointments which where migrated from older version like 5.5/2000/2003. Those have been migrated the whole path upwards to 2007/2010.

    Because they are appointments and some of the private i guess most of them are related to sync issues with handheld or two diffrent handheld (Activesync and USB) syncing with the Mailbox. This should not be a problem with identical OS like (IPAD and IPHONE) which comes up a lot the last few weeks.

    There is still the rumar that not to sync more than one device with a mailbox (Partnership). This is relally ralted to complex appointment like Recuring etc. Also Baclkberry had/has probelsm with such more complex elements.

    Maybe somone from MS (Not a payed moderator) can write something in here for the MS Partners. Normaly we have around 1-20 items but today also had a case with 70 corrupt items with a mailbox started in 2001.

    Thank you

     

     

     

     

     

    Thursday, December 22, 2011 12:48 PM