Migrations with Data Consistency Score (DCS) – more than you ever wanted to know!

Mihai_Grigoruta 

@The_Exchange_Team 

Thanks for the response re mailbox items that have reached the nebulous state of "corrupted".  It appears that you missed most of what I posted.

If I can review the response, you've clearly stated that:

"Logical corruption on items can be introduced by any app" So that includes Microsoft Exchange Server, Microsoft Outlook, Microsoft ActiveSync clients, Microsoft Edge (for OWA) or another Microsoft approved browser. Thank you for acknowledging that these Microsoft applications may indeed introduce "corruption". This is consistent with Microsoft introducing "corruption" and not having the checks in place to ensure that the "corruption" does not make it to the Exchange database.

"Usually these items were corrupted by a 3rd party client of some kind" is a blanket statement abut the quality of 3rd party applications, so its logical to assume that you have statistics to back the assertion. Can you please share your statistics that support 3rd party clients that may or may not have been created by Microsoft Partners, causing the majority of the "corruption". I have been in Exchange environments with no third party apps and we always found "corrupted" items during migrations. The Exchange servers and clients were well maintained so there was no reason to believe that the "corruption" was caused by anything other than a Microsoft application such as Exchange or Outlook.

"Usually these items were corrupted by a 3rd party client of some kind that has put the source data into a logically corrupt state". This appears to be an acknowledgement Exchange is generally vulnerable to exploits from 3rd party apps as it does little checking.

"So the corrupt data will be skipped by our system only if you allow the data loss"
This a roundabout way of saying that if you want the mailbox migrations to complete without data loss, you may spend hundreds or thousands of hours trying to remediate the "corrupted" items. The New-MailboxRepairRequest has 40+ different types of -CorruptionType values. For a larger migration you could assign a full-time individual to do nothing but look at every last "corrupted" item, attempt endless variations of New-MailboxRepairRequest repairs and then still keep their fingers crossed that the repair did not truncate business-critical information.

As mentioned in my previous post, when you "skip" items that were "corrupted" by Microsoft applications, you have then chosen to effectively and very deliberately, delete messages from a user mailbox - i.e. you have deleted user data. During the course of a larger migration you may end up deleting hundreds or thousands of user messages - all deliberately. This is a serious problem, not only for compliance and legal reasons but you may also be deleting very important user messages which may have financial or other lasting implications.

The ability to "skip" items, or the New-MailboxRepairRequest command or DCS still does nothing to address the fact that after 25+ years, Microsoft is still allowing "corrupted" items, that are most likely "corrupted" by Microsoft supported software, to make it to the database.