In January this year, Microsoft completed a roll-out of Data Consistency Scoring to help Mailbox Migrations leveraging the Mailbox Replication Service (MRS). As the Director of Enterprise Migrations at Quadrotech, to say I’m a bit too excited for this update is an understatement. We’ve integrated these changes into the latest release of our Office 365 mailbox migration software.
The problem with Mailbox Migrations before the new Data Consistency Scoring
Data corruption is a prominent issue Admins were facing daily with mailbox migrations initially before the new Data Consistency Scoring was introduced. Although now this is notably much less of an issue than it has been in the past, it’s still a reality of some of the complications which can occur during Office 365 migrations. Over the years, as Exchange has matured, the data issues have become less arduous. However, there are still some which can hinder a migration.
Previously, during a migration, the admin could set an acceptable BadItemLimit. Most administrators picked between 25 and 50 items. As the migration occurred, the system would tally the bad items that it found. If the number of bad items found was under this limit, the migration would continue. If it exceeded this limit, or no limit was defined and items were found, then the migration would not complete until the administrator raised the limit.
But, what exactly is a bad item? Bad items are those which have failed, and are unable, to move from the source account to the target during the migration. Most commonly people think of this as actual email, however it can also be non-item data like Folder Level Permissions that can’t migrate. With the latter being the larger annoyance.
The main challenge here was that these all lacked differentiation and migration projects would appear to have a high number of ‘bad items’ when actually these were common low priority inconsistencies, for example, folder level permissions mentioned above that can’t migrate. This also meant that if there was a high-risk bad item, and an admin ran a migration by default, they would not be aware of it. From experience, I know folder permissions will fail and for me and my clients, and this isn’t a cause for concern. However, if actual messages fail, this is a more pressing matter, I’ll want to know more and document it.
It should be noted that you can remove these problem permissions in some cases, however, as we will read next, this new system negates this need.
What is the new system?
The new DCS solves this ongoing problem because it allows us to focus on the issues we care about. What we will be able to see with this new solution is each mailbox we migrate will be allocated a score, also referred to as a ‘grade’.
For simplicity, there are now four possible grades which have been presented in the latest Microsoft documentation:
During an Office 365 migration project there will be a lot you will have to oversee as an admin, so what makes this really useful is using the Data Consistency score because you’ll only be alerted to actual data loss or major issues that need attention. However, this still begs the question, what is the remedy if the score highlights corrupt items during your project? From experience, in almost all scenarios, I’d document it, raise the limit, add -acceptlargedataloss, maybe cry a little, and move on.
In the table above, you can see Investigate. In relation to this, I fear that during a mailbox migration this would be the same situation as mentioned prior. In this scenario, you’d have to move the mailbox. Your first option is to accept the situation and move on. The second option is to give the user a blank new mailbox. For the sake of simplicity, I think we can all agree that here, we are going to use option one.
The good news is, I’m not really seeing many Investigate from the DataConsistencyScore and my unofficial pooling of migration admins have only found two. Again, this is due to the stability of Exchange and enhancements to storage.
How do I use it?
The good news is that this feature has been rolled out to all tenants and is GA. If you want to see the scores of batches you are running, you can simply pop into the Migration UI in the Exchange admin center and view them. This will help you understand your scoring and understand your current situation.
If you’re using the admin center UI to submit batches, then you simply leave the BadItemLimit and LargeItemLimits blank in the new batch wizard.
If you’re submitting user and batches via PowerShell, simply stop using the -BadItemLimit and -LargeItemLimit switches in your scripts. This will default to the new scoring. You will need to approve any pairs that hit the Investigate stage, which depending on the source system, should be rare.
Can I use this for cross-forest moves with on-prem versions of Exchange?
No, so keep your scripts handy if you run into a Merger, Acquisition, Divestiture and/or have some accounts on-premises.
Can I use the old method?
For now, yes you can. However, the documentation warns that this is going to be turned off in the near future, so don’t incorporate this into any of your future migration plans.
What do I do with poor scores?
Again, I am not seeing these, but I’m sure there are some out there. The only remedy offered is to open a case with Microsoft for guidance.