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

Mirela_Buru The_Exchange_Team 

Here are my comments based on your feedback:

1. I believe that DCS may be calculated on the same data/metadata or at least if the incremental sync (manually run) and the cutover occur in close proximity to each other, something isn't updated in time and DCS is being recalculated on the data that it was already calculated on. I had instances where I would run a manual Incremental Sync and DCS was Good/Perfect. I would then kick off a completion job that would "fail" (go back to Synced state) with DCS of "Investigate". When I reviewed the items identified, they were items that were originally synced without issues because they were "old" items in the mailbox (Calendar entry from 2018 and similar). 
2. You are correct, apologies for using the wrong term. We are seeing "Investigate" DCS on CorruptFolderACL, CorruptMailboxRule, CorruptItem issues. I can provide examples of this (some are attached to the case # provided in the DM).
3. This is a challenge, because the mailbox is "live" and is able to send/receive emails (as well as generate other items like Rules and grant Permissions) during the migration. If I set the SkippedItemApprovalTime and the user happens to send/receive an email or generate a new item during the cutover that is deemed corrupt will the DCS change to "Investigate" even though I set the SkippedItemApprovalTime? If the answer is yes, then it could explain my situation (but only if the item was created during the "cutover" time period). I've seen the DCS change to "Investigate" on old items, similarly to my comment #1. Some mailboxes generate a large delta between "prestage" and "cutover" stages (including final delta sync) that can result in items becoming corrupt but I would expect the items time stamp to be very recent.
4. I wasn't able to find the .xml file for the user that had 2 CorruptACLs and went into "Investigate". Unfortunately, I only started to keep the xml files after this became an issue for me. I did find a user with 139 CorruptACLs; should that have triggered investigate? The article states that 100,000 corrupt ACLs with trigger a failure but doesn't state how many will trigger "Investigate". I can provide the xml if required.

I believe that more parameters are required for the feature or different "weighting" of the score should be applied to items based on age and IPM type. For example, I should be able to specify -IgnoreCalendarItems or -IgnoreMailboxFolderRules and similar. I think having the ability to control "-Start" and "-End" for any DCS parameters would be great, eg. "-startDCS -start:$startdate -end:$enddate". This will allow us to ensure that the data created during the specified time range is stringently validated while the rest isn't. Not all items are treated "the same" by users so they shouldn't treated the same by the DCS. In the past, organizations accepted the fact that some items will be corrupt and lost during the migration and I am yet to see a "perfect" migration for every single mailbox.

It would be very helpful to be able to control how and where the DCS score is being calculated as well being able to reduce its impact on the batch (for example, still allow the completion of the batch but exclude the "Investigate" move requests automatically rather than block the entire batch). Additionally, since the "magic" behind DCS calculations is known, it might be very helpful to release a tool similar to IdFix for Azure AD that will allow admins to proactively review their environments and address the issues prior to migrations.

My suggestions are biased toward my needs and the needs of the clients I deal with so it would be great to see what other admins feel is missing as well.