Improving Migrations Using Data Consistency Scoring
Published Jan 13 2020 11:51 AM 25.6K Views

Hello!

As you may have seen from the Microsoft 365 roadmap item, the O365 migration team has been working on improvements to the way we detect inconsistencies or data loss during migrations or moves.

We’ve historically used a configurable parameter called the ‘Bad Item Limit’ to define the number of items that you, the admin, are okay with dropping during migrations. We allow the admin to use their discretion to set this bad item limit to as low or as high as they feel comfortable with. On the service side, we can see that many migrations hit a large number of ‘bad items’ which are simply inconsistencies in metadata that the end-user may not even notice. This then resulted in many admins running their migrations with a very high Bad Item Limit by default. The problem is that the current implementation has limited capabilities to alert the admin when there are bad items that the end-user will notice, or significant amounts of truly ‘bad items’.

As our experience around migrations has grown over time, we’ve learned to distinguish between ‘expected’ and ‘unexpected’ inconsistencies and have built functionality to expose this to admins. We call this mechanism Data Consistency Scoring or DCS. Based on the number and type of data inconsistencies we detect, your migration will be categorized as Perfect, Good, Investigate, or Poor.

Migrations that end up in the Investigate bucket would require additional admin approval (self-approval via the UI or cmdlet) for completion. Migrations marked as Poor cannot be completed without escalating to support. By doing this, we are taking the guessing out of the “How many bad items am I OK with?” equation. We never had an official recommendation on what to set your ‘bad items’ limits to, and we are hoping this helps to deal with ambiguity that resulted.

Now that the DCS mechanism is fully rolled out, any new migration/migration batch that is started without a value set for the Bad Item Limit (-BadItemLimit parameter) or Large Item Limit (-LargeItemLimit parameter) will use the new DCS method. The Bad Item Limit mechanism will still be available for use and overrides DCS whenever explicitly specified, as we want to allow you time to modify your scripts to work with the new DCS method.

Update: the BadItemLimit and LargeItemLimit parameters will be completely replaced by DataConsistencyScore in January 2021.

For more details, take a look at the official documentation and guidelines for DCS! Let us know what you think!

O365 Migration Team

10 Comments
Silver Contributor

Great. That Bad Item Limit ambiguity was really weird to me :)

Copper Contributor

This is very timely information.  I've been troubleshooting why a move request would not finish for the last few days.

Copper Contributor

I am using the new method, DCS, and have migrations failing, support are telling me to add a baditem limit to my requests.

 

Is DCS really for mainstream?

Silver Contributor

Maybe support is not up to speed yet with new features (especially L1). You said migrations are failing. Do you get Poor results as described in this article?

Copper Contributor

Hi,

 

No mailboxes had a 'fail' score. For the 3 mailboxes which failed to complete migration: 1 had a score of 'perfect' and the others were 'good'. 

 

Last night whilst trying to complete the migration they failed and all 3 had the following error:

 

30/01/2020 22:05:47 [DBAPR02MB6199] Stage: FinalIncrementalSync. Percent complete: 95.
30/01/2020 22:05:52 [DBAPR02MB6199] Mailbox store finalization is complete.
30/01/2020 22:05:52 [DBAPR02MB6199] SessionStatistics updated.
30/01/2020 22:05:52 [DBAPR02MB6199] Content verification: source mailbox:
01524bdc-ae3a-418a-8675-6f0abfc84bd9, target mailbox: 01524bdc-ae3a-418a-8675-6f0abfc84bd9, flags: Default.
30/01/2020 22:05:52 [DBAPR02MB6199] Started Data Guarantee wait.
30/01/2020 22:06:25 [DBAPR02MB6199] Mailbox contents verification complete: 209 folders, 8536 items, 529.7 MB
(555,447,067 bytes).
30/01/2020 22:06:25 [DBAPR02MB6199] Transient error DataConsistencyTransientException has occurred. The
system will retry (60/60, 60/600).

Copper Contributor

Hello,

Running a restore mailbox request and noticed a DataConsistencyScore of investigate.

The restore to date is approx 35 gb and has taken 17:44 hours,  The restore has not reported any bad items only 5 large items.

 

Does an Admin need to intervene in this scenario?  

How does one approve a mailbox restore request?

 

I have read the documentation in your link but it only mentions PS commands for migrations or move requests, nothing on restore requests.

Thanks

 

Copper Contributor

I am in the same boat as ratzq described. DataConsistencyScore of investigate during mailbox restore and there is no way to override DCS using Baditemlimit

Steel Contributor

I noticed a bug with this feature DCS.  You can recreate it like this:

  • Create a new batch, say onboarding mailboxes in a Hybrid deployment, and set Bad Item Limit to something (let's say 10), and leave Large Item Limit blank.
  • Next, in EXO PowerShell change the move requests' Large Item Limits to something other than 0, let's say 10 again.
  • If there are large items, the large item limit will be ignored and the move will fail.
    • You'll see this in the Get-MoveRequestStatistics:  LargeItemLimt 10
    • And this won't matter it will just be ignored.

I'm testing the solution of also updating the migration batch in the GUI with the new Large Item Limit value.  But it's strange that I would need to when other overrides like -CompleteAfter still work just fine via Set-MoveRequest.

Steel Contributor

FYI in case anyone is back wondering the same.  It seems as though you can still override the Data Consistency Score by changing the limits on the batch itself while also doing Set-MoveRequest -BadItemLimit.

 

I also notice the Set-MoveRequest cmdlet in the EXO v2 PS module (v2.0.3) has been plastered with some double Write-Warning's about the fact that -BadItemLimit -LargeItemLimit parameters are going away.

 

Example of the double Write-Warning special

>Set-MoveRequest User@Domain.tld -BadItemLimit 40
WARNING: When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are
 requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox.
WARNING: The request is currently being managed as a part of a migration batch.  Changes to the request may be overwritten by the Migration Service or could impact the status expressed by the
migration batch or migration user.
WARNING: Setting a bad item limit may conceal unexpected data loss.  Please consider using the Data Consistency Score feature by not specifying the Bad or Large Item Limits.  Setting bad item
limits will be disallowed in the near future, even when the threshold (0) has not been exceeded.
WARNING: The request is currently being managed as a part of a migration batch.  Changes to the request may be overwritten by the Migration Service or could impact the status expressed by the
migration batch or migration user.
WARNING: Setting a bad item limit may conceal unexpected data loss.  Please consider using the Data Consistency Score feature by not specifying the Bad or Large Item Limits.  Setting bad item
limits will be disallowed in the near future, even when the threshold (0) has not been exceeded.

That 1x each of the original warning with -BadItemLimt, then 2x the usual warning about the move being part of a migration batch, and then 2x the new warning with the threat of the coming change.  So it definitely must be a serious threat.  That's 5 warnings, making for 1 large text wall of yellow.

 

I feel like the manual override should not be discontinued.  It should simply be updated in documentation that sometimes "BadItems" are not just corrupted items which are unsalvageable, sometimes they are indeed salvageable or even just worthwhile of letting the user know about.  Why the harsh discontinuance of these two significant features is beyond me.  Central Bad-Decisions'Ville.

Copper Contributor

I receive the following notification when attempting a migration from on-premises Exchange Public Folder to Exchange Online:

Identifier: PFMailbox1
Status: Synced
ItemsMigrated: 282153
ItemsSkipped: 2669
ErrorMessage: No Message
DataConsistencyScore: Investigate
DataConsistencyScoringFactors: LargeItem
HasUnapprovedSkippedItems: TRUE

We have investigated extensively but do not understand what the ItemsSkipped represent. Are these the Public Folders themselves, or the messages within them? Does anyone have a solution for this?

Version history
Last update:
‎Dec 21 2020 12:11 PM
Updated by: