O365 Migration that completes with warnings due to insufficient rights.

The Problem:

With the rise in Hybrid configurations around the world, we are starting to see some regular occurrences of issues around migrating from OnPremises exchange (called OnPrem henceforth) to O365. Perhaps the most common is one where most users migrate fine, but a select few only partially migrate. When you look at the migration logs, they typically look as follows:

FailureType       : UpdateMovedMailboxPermanentException
FailureHash       : 1304
FailureCode       : -2146233088
MapiLowLevelError : 0
FailureSide       : Source
FailureSideInt    : 1
ExceptionTypes    : {Exchange, MRS, MRSPermanent, MRSUpdateMovedMailbox...}
Message           : An error occurred while updating a user object after the move operation. --> Active Directory
operation failed on DC1.instant-grits.com. This error is not retriable. Additional information:
Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS),
data 0
--> The user has insufficient access rights.

So basically, the user now has a mailbox in the cloud and a mailbox onPrem, because the migration did not fully complete. They can only access their mailbox in the cloud using OWA.


In most every case, the user you are trying to migrate either belongs to a protected group of some sort or simply does not have permissions inheritance enabled. The protected groups, by design, do not inherit permissions in Active Directory (AD). Exchange OnPrem needs to have specific permissions set in order for a mailbox migration to O365 to complete. Specifically, it needs to be able to convert the OnPrem mailbox to an OnPrem remote mailbox and link it to the O365 mailbox. For Exchange to do that, two groups have to have rights on the mailbox:

Exchange Trusted Subsystem
Exchange Servers

These rights are typically pushed down from the top of the domain using inheritance, so with inheritance disabled, you simply cannot migrate them without errors.

What can I do about that?

A most excellent question. There are a few options here. The ideal one would be to turn on inheritance for the onPrem mailbox.

The problem with that in regards to the protected group members is there is this tiny little process called SDProp that will revert it back to disabled, usually within the hour. Not always long enough for the mailbox to finish migrating. It is a protection mechanism to make sure that the protected group member doesn't suddenly have a bunch of permissions thrust upon it by the OU that it is a member of thereby giving permissions to an OU administrator over the privileged account that it shouldn't have.

So what do you do? Well, you can add the two Exchange groups to the user's permissions manually, which is a huge undertaking as you will have to look at a user who does have inheritance turned on to see exactly which rights the Exchange Trusted Subsystem and Exchange Servers groups has on the account and then mimic them on each mailbox you intend to migrate, or you can add them manually once to the AdminSDHolder container in AD. Or better yet, just enable inheritance on the AdminSDHolder container itself. Sometime in the next hour, it will update all of the protected group members at once, and then you can migrate them. Once migrated, you can turn inheritance back off and up to an hour later, all of those accounts would have it removed for them as well and they would revert back to their original permissions.


Once the permissions have been inherited, Exchange will then have adequate permissions to convert the mailbox to a remote mailbox and link it to the new O365 mailbox. Once that has completed, the user should be able to access their O365 mailbox from Outlook and OWA.


For more information on AdminSDHolder, SDProp and Protected Groups, check out the following TechNet article:


There is another option which involves manually completing the process for these accounts. That article can be found here:


One of our partners has an addendum to the support article that goes into some additional steps which will help preserve your proxy addresses in that process:



Special thanks to Raymond Fong for helping me iron out this issue and to Perficient for their excellent blog.