Mailbox Move to Exchange Online – Error: ASSERT: Reservation to update is not found

So I came across this “challenge” when trying to move a user from Exchange 2010 SP3 to Exchange Online.

All the others users in the batch worked fine, but one user would get to around 50% and then fail!

The batch log contained:

09/11/2017 17:42:55 [HE1PR04MB2985] User xx.xx' failed migration: Error: ASSERT: Reservation to update is not found

The user log wasn’t much better with:

09/11/2017 17:38:47 [HE1PR04MB3241] Fatal error ExAssertException has occurred.

and

MigrationMRSPermanentException: Error: ASSERT: Reservation to update is not found

So I tried something that I have done before. Using PowerShell and connecting to EXO, I ran:

Set-MoveRequest -Identity xx.xx -SkipMoving: FolderRestrictions, KnownCorruptions, FolderViews

I then restarted the batch

Start-MigrationBatch "yy_yy" -Verbose

And BOOM! it worked. Not sure what the hell was going on but hey, the user moved!

Hope this helps someone ;-)

Exchange Online Default Email Address Policy

So this was interesting.  I had a user that was failing to create an Exchange Online Mailbox, due to a duplicate tenant address (tenantname.onmicrosoft.com), which us mortal people have zero control over.

After a week of playing I raised a call with Microsoft to see what the hell was going on.

To cut a long story short, the issue was resolved by itself.  “When product group started the troubleshooting mailbox was already created.”  Yeah right! As if by magic after a week it sorts itself .. sorry not convinced!

Anyway, it turns out (according to PSS), that the Default Email Address Policy on Exchange Online actually does nothing, and updating it from the default email template, has zero effect on users!  Which seams a bit odd, but hey!?!

The other interesting thing, is that if two users share the same UPN prefix like bob@domain1.com and bob@domain2.com there will be a conflict because both should get bob@tenantname.onmicrosoft.com as an alias in Office 365.

We have over 100k synced objects and over 600 domains.  So we should have seen this issue before .. but we didn’t.

Anyway, this is where the duplicate attribute resiliency feature of AAD Connect should come in to play, to make sure the attributes are unique. https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency.

However, for the user I had an issue with, this didn’t happen!

The expected behavior should be:

1st user to be synced / provisioned:
UPN / primary SMTP: bob@domain1.com
Secondary SMTP / cloud alias: bob@tenantname.onmicrosoft.com
Remote routing address: whatever is set via Exchange console (using the tenantname.mail.onmicrosoft.com domain)

2nd user to be synced / provisioned:
UPN / primary SMTP: bob@domain2.com
Secondary SMTP / cloud alias: bob1234@tenantname.onmicrosoft.com
Remote routing address: whatever is set via Exchange console (using the tenantname.mail.onmicrosoft.com domain)

So, only the IT gods know what happened, and it shouldn’t have happened in the first place, but welcome to the occasional oddness of cloud computing and Office 365.

UPDATE#1: Resolution from Microsoft: Attribute resiliency feature action generated unique onmicrosoft.com smtp address, but unfortunately with significant delay.

Laters

Exchange Online Mailbox Types

That is interesting.  Been playing with Exchange Online Mailbox types.

With the -Type parameter specifies the mailbox type for the mailbox. Valid values are:

  • Regular
  • Room
  • Equipment
  • Shared

Now I had never noticed this before, but when you switch a mailbox to anything other than Regular, the UserAccountControl changes to AccountDisabled.

That would explain why authenticated SMTP relay to smtp.office365.com would stop working :-o