When moving mailboxes to Exchange 2010, you might come across the following error:
Or when using the EMS, you might find some move operations with a state of Failed or Queued for hours.
When you try to suspend/resume these queued move requests, you get a similar error:
[PS] C:\>Resume-MoveRequest "Nuno Mota"
Active Directory operation failed on dc1.letsexchange.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150A48, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+ CategoryInfo : NotSpecified: (0:Int32) [Resume-MoveRequest], ADOperationException
+ FullyQualifiedErrorId : 2851DFD3,Microsoft.Exchange.Management.RecipientTasks.ResumeMoveRequest
Since Exchange 2000 every version of Exchange has a massive dependency on Active Directory. What is happening here is that whenever a move request is issued, the Mailbox Replication Service (MRS) needs to update several attributes in the user object. These attributes are used by the MRS to keep track and report the progress of the move. Using ADSIEdit you can see all these attributes under msExchMailboxMove*:
These attributes are populated when the move request is issued and cleared when the move request is deleted with the Remove-MoveRequest cmdlet (or from the EMC). Because the MRS needs to be able to update these AD fields, the move will fail if it can’t. And this is what is happening here.
So, all you have to do is fix the permissions for the affected user. To do this:
1. go to Active Directory Users and Computers
2. click on View and select Advanced Features (so you have access to the Security tab of AD objects)
3. find the affected user, right-click on it and go to Properties
4. Select the Security tab and then click on Advanced
5. Tick the Include inheritable permissions from this object’s parent box
6. Click OK
This should fix it! You can now suspend/resume the Queued move request or issue a new move request if the first one failed.
This seems to only affect highly privileged user objects that were created before the deployment of Exchange 2010. But why? Exchange 2010 system components are granted access to AD through the Exchange Trusted Subsystem, which has privileged and powerful access to AD. However, it can’t deal with cases where the Access Control Entries (ACEs) that Exchange depends on are not stamped into user objects. In these situations, any attempt by Exchange to update the object is declined by AD, like the problem with the Move Request.
Hope this helps!