New-MoveRequest failed with Error MapiExceptioNoAccess

New-MoveRequest failed with Error MapiExceptionNoAccess

It’s not uncommon to run into the mailbox move failure during an exchange migration, We have seen the following error multiple times and its mostly because of not using an appropriate user account for mailbox migration. No, the Built in domain admin account is always not the best account. Quite frankly I am too not sure what groups a user should be a member of to carry on a Move request but fortunately I know how to resolve this issue without going there.

Coming back to the issue , following is the error we are talking about today

Service ‘net.tcp://ex.contoso.local/Microsoft.Exchange.MailboxReplicationService’

encountered an exception.

Error:MapiExceptionNoAccess: Unable to open message store. (hr=0x80070005, ec=-2147024891)

Diagnostic context:

Lid: 18969 EcDoRpcExt2 called [length=165]

Lid: 27161 EcDoRpcExt2 returned [ec=0x80070005][length=194][latency=0]

Lid: 32881 StoreEc: 0x80070005

Lid: 50035

Lid: 64625 StoreEc: 0x80070005

Lid: 1494 —- Remote Context Beg —-

Lid: 26426 ROP: ropLogon [254]

Lid: 56503

Lid: 12716 StoreEc: 0x80070005

Lid: 20794

Lid: 28474 StoreEc: 0x80070005

Lid: 22330 dwParam: 0x0 Msg: 14.01.0438.000:OldExchangeServerName

Lid: 1750 —- Remote Context End —-

Lid: 23354 StoreEc: 0x80070005

Lid: 25913

Lid: 21817 ROP Failure: 0x80070005

Lid: 26297

Lid: 16585 StoreEc: 0x80070005

Lid: 32441

Lid: 1706 StoreEc: 0x80070005

Lid: 24761

Lid: 20665 StoreEc: 0x80070005

Lid: 25785

Lid: 29881 StoreEc: 0x80070005

+ CategoryInfo : NotSpecified: (0:Int32) [New-MoveRequest], MailboxReplicationPermanentException

+ FullyQualifiedErrorId : BC4A9AA5,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest



If you read the error carefully, it clearly denotes that its Unable to Read the Message store or the mailbox, The reason for not being able to read them is either

Problem 1: The user who is running the command (Admin user who is logged on to the server or under who’s context you have the PowerShell open) doesn’t have the permission to Read the mailbox.

OR

Problem 2: The mailbox has some kind of corruption.

Now that we have state the two problems, lets talk of solution

Solution 1:

As we stated in the beginning of this article, this issue is mostly because an appropriate account is not being used for executing the mailbox move cmdlet or it may be because default permissions are not being applied on the problem user. We have seen these issues mostly happening on Admin users  or rather I should say users with AdminCount=1 because they do not have appropriate permissions on them.

AdminCount is a user attribute (can be viewed in user properties under adsiedit.msc), if a user is ever made part of an admin group like domain admin, enterprise admin, server admin and many other than this value turns true or 1 for it.  Unfortunate part is that when the user is taken off the group the value doesn’t become false or 0 by itself.

Now any user for whom the value of AdminCount is 1, that users permission is governed by AdminSDHolder thread. Basically it replicates whatever permission it has on itself to all the users who’s admincount=1 and it does this process at every one hour by default. So even if you manually fix the permission of a user they will get reverted the next hour. The solution is

1) If the user is not part of an admin Group and still has the AdminCount=1, then simply edit the attribute from adsiedit.msc and make it 0. Do not change the attribute if the user is still part of admin group because than it will get changed back to 1 by itself.

2) If the problem user is an admin user and you want to fix permissions on it, than rather just fix the permission on the Admin SD Holder object so that next time the AdminSDHolder thread executes, it will fix the permission on all the AdminCount=1 users.

Fixing permission on AdminSDHolder thread.

1) Open Active directory users and computers on your domain controller

2) Click View Menu and enable advance feature from the list

3) You will now see a System container/folder in the tree, expand that and the first container in the list is AdminSDHolder

The AdminSDHolder Container under system folder

The AdminSDHolder Container under system folder

4) Right Click on it and Pull up its properties and edit the security from there like of any regular folder or file

So here is what we need to do to fix the permissions on the user.

1) Open Active Directory users and computers

2) Pull up the properties of the problem user, go to security tab (Make sure Advanced Feature is enabled under ADUC else you might now see the security tab, its explain in the box above)

3) Click on the advanced button on the bottom of box and under the advanced security settings box , ensure that the “Include Inheritable permissions” Check box is enabled, if it’s not than please do.

Click the Advanced button

Click the Advanced button

Check the Permission Inheritance box

Check the Permission Inheritance box

4) Please remember if this is a user with AdminCount=1 than these permissions will go away in an hour unless you fix them on AdminSDHolder thread (Confused 🙂 , Please read the box above)

5) So basically go to the AdminSDHolder container security and enable the “Include Inheritable permissions” Check box there and that should fix all the other users (with AdminCount=1) in next hour.

After this step, you should wait for some time and over night probably if you have too many domain controllers , so that these permissions can replicate across all the DC’s before you try the mailbox move again.

If the above didn’t fix the issue than we need to manually give full access to the admin user (which we are using to Move mailbox) on the problem mailbox. fortunately its simple 🙂

1) Open Exchange PowerShell

2) Execute following commands one by one

Following command is just to get a list of all the mailbox’s on your exchange, so that you do not have to add permission on each mailbox individually, this step can be skipped if you want to try it on one or rather actually want to add it one by one

$mailbox=get-mailbox

Following command start with a for loop so that all the mailbox’s collected in previous commands can get the permission, if you want to do it one by one than use the command starting from add-mailboxpermission and loose the last }. Also please replace AdminUserName with your adminuser and also if you are running the command without for loop than after -identity replace $m.alias with the problem user alias.

foreach($m in$mailbox){add-mailboxpermission -identity $m.alias -user AdminUserName -accessrights fallaccess -inheritencetype all}

This should be mostly enough for taking care of this issue, else lets move to solution 2

Solution 2:

I have solved my issue mostly with Solution 1, very rarely needed to try the following

1) Remove any database limits on the mailbox/Database : We have noticed that if a Mailbox is over its limit than at times it fails to move with this error

2) Try to repair the mailbox corruption using New-MailboxRepairRequest, Please refer the steps here and here

3) I have also seen at times that request fails with this error if there are too many request going on at the same time, in which case let the other request finish completely and wait for another 15, 20 mins to begin this problem mailbox user request

4) Once I have seen my request failing because I had the -BadItemLimit set too high, it was 1000.  I changed the limit to 100 and it worked.

Hope this article helps you with your failing move request, else feel free to start a new thread on our forum  to report any issue you need help with

The following two tabs change content below.
An automobile enthusiast at heart and computer geek by profession, started my Career with MS in 2005.Left Jobs and started Pledge Technologies (the parent company to Grishbi) back in 2009.We have been providing IT consulting to various Small and Medium businesses across US and UK since then.Our company specialises in Microsoft Server technologies like AD, Exchange, the rest and with numerous Office 365 migrations under our belt, we quite an expert with that too. Whatever we learn in our day to day life, we share it back on Grishbi as a Thank for all the love and support our customers have given us.
%d bloggers like this: