Solved

Move mailbox fails from exchange 2010 to 2013

Posted on 2013-10-29
10
2,062 Views
Last Modified: 2014-06-04
I'm in the last phase of migrating from exchange 2010 to 2013.  Over the weekend I was able to move approximately 1250 mailboxes from 2010 to 2013.  There are two mailboxes that refuses to move (both shared mailboxes).

Deleting the request and creating a new one gets the same error.  It will run for 12 to 18 hours then fail with the following error (mailbox is only 200 megs in size so it shouldn't take that long).

Data migrated: 305.2 KB ¿(312,540 bytes)¿
Migration rate: 0 B ¿(0 bytes)¿
Error: MigrationPermanentException: Error: Cannot query rows in a table. --> MapiExceptionInvalidObject: Unable to query table rows. ¿(hr=0x80040108, ec=-2147221240)¿ Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=1569] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=403][latency=77] Lid: 52176 ClientVersion: 15.0.712.17 Lid: 50032 ServerVersion: 15.0.712.6014 Lid: 23226 --- ROP Parse Start --- Lid: 27962 ROP: ropGetContentsTableExtended [164] Lid: 27962 ROP: ropSetColumns [18] Lid: 27962 ROP: ropRestrict [20] Lid: 17082 ROP Error: 0x80040108 Lid: 27489 Lid: 21921 StoreEc: 0x80040108 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 ---- Remote Context Beg ---- Lid: 65304 StoreEc: 0x8004010F Lid: 58880 StoreEc: 0x80040108 Lid: 63016 dwParam: 0x14 Lid: 39640 StoreEc: 0x80040108 Lid: 10786 dwParam: 0x0 Msg: 15.00.0712.012:SHB-EXGDB3 Lid: 1750 ---- Remote Context End ---- Lid: 27962 ROP: ropQueryRows [21] Lid: 17082 ROP Error: 0x80040108 Lid: 17153 Lid: 21921 StoreEc: 0x80040108 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 ---- Remote Context Beg ---- Lid: 65304 StoreEc: 0x8004010F Lid: 58880 StoreEc: 0x80040108 Lid: 63016 dwParam: 0x14 Lid: 39640 StoreEc: 0x80040108 Lid: 10786 dwParam: 0x0 Msg: 15.00.0712.012:SHB-EXGDB3 Lid: 60464 dwParam: 0x80040108 Lid: 10786 dwParam: 0x0 Msg: 15.00.0712.012:SHB-EXGDB3 Lid: 1750 ---- Remote Context End ---- Lid: 26849 Lid: 21817 ROP Failure: 0x80040108 Lid: 28414 Lid: 32510 StoreEc: 0x80040108


I can move the mailbox between 2010 databases easily, takes about 10 minutes. but moving it to 2013 has been unsuccessful.

any clue what is causing the failure and how to work around it?  thanks
0
Comment
Question by:NIS_RULE
  • 4
  • 4
  • 2
10 Comments
 
LVL 34

Expert Comment

by:Seth Simmons
Comment Utility
if it's only 2 mailboxes and if they aren't that big then might be best just to export to pst, remove the mailbox from 2010 and create a new one on 2013 and import

http://technet.microsoft.com/en-us/library/ff459227%28v=exchg.141%29.aspx

http://technet.microsoft.com/en-us/library/ff607310%28v=exchg.150%29.aspx
0
 

Author Comment

by:NIS_RULE
Comment Utility
That would be my last option.  These two mailbox aren't that big (about 1.5gb each) but the mailboxes are shared mailboxes so lots of different shared permissions.  I'd hate to have to set all that up again and contact all the end users to make sure they still have all the proper access.

If there was a way to get them to migrate over that would be ideal
0
 
LVL 34

Expert Comment

by:Seth Simmons
Comment Utility
you said before the mailbox is only about 200mb
0
 

Author Comment

by:NIS_RULE
Comment Utility
the live data is about 200MB but once you add all the recoverable deleted items, it is about 1.5GB.  Ideally I'll like to preserve that (which you can't do with an export to pst).
0
 
LVL 4

Expert Comment

by:peter_field
Comment Utility
Have you made any progress on this? We are having the same issue. So far I have been doing the export/new mailbox/import business which is very frustrating as I can see you are aware.
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 

Author Comment

by:NIS_RULE
Comment Utility
yes, what finally worked for us is to migrate the mb that is having issues to another database on 2010, (may have to do this 2 or 3 times) then migrate it to 2013.  That worked for us on the mailboxes that were having issues.
0
 
LVL 4

Expert Comment

by:peter_field
Comment Utility
No such luck for us unfortunately. It was worth a shot, thanks for sharing.
0
 

Author Comment

by:NIS_RULE
Comment Utility
Have you tried to migrate the 2010 mailbox to a few different 2010 databases, then migrate it to a few different 2013 databases?  That's what worked for us.  We eventually found a combination of 2010 db -> 2013 db that worked.

I had opened a ticket with MS and worked with them for 2 weeks straight on it and they couldn't figure it out.  After two weeks, they gave up and suggested I export to PST then re-import.

Another solution I found on a different forum is to backup the 2010 db on whatever backup software you use.  Delete the online mailbox,  restore the backup to a different 2010 database, then migrate it to a 2013 db.  I was going to try this next if moving to different 2010 db's didn't work for us.  but didn't have to try this. so you can give it a shot
0
 
LVL 4

Accepted Solution

by:
peter_field earned 500 total points
Comment Utility
Yeah, our MS ticket went nowhere as well. Thanks for the suggestion, I actually wrote up a script to try a migration for every possible combination of 2010<->2013 servers, and not one combination worked unfortunately (that was 48 combinations, yes, I'm desperate).

I might give the backup/restore option a shot, but that is basically as much work and around the same level of disruption for the end users so other than keeping the dumpster/rules/other bits doesn't save much, and has the risk it will result in the same error anyway.

We still have more than 50,000 accounts to migrate, I'm expecting to get quite a lot of these before we are done, and between trying to minimize disruption, ensuring mail delivery during the fix and not stuffing anything up like rules or X500 addresses this is going to drive me insane.

Thanks for your help.
0
 
LVL 4

Expert Comment

by:peter_field
Comment Utility
OK. I have narrowed it down, and have successfully fixed a number of mailboxes now. I still do not have root cause, or a direct fix.

If you do the following once the move request goes into "TransientFailure" it will give you the item/folder that has the issue:
(Get-MoveRequestStatistics <yourmailbox> -IncludeReport).Report.Failures | select -expand datacontext

Open in new window


In every one of our cases, it has been the "Sent Items" folder. The way I've got the mailboxes to move is:
Disable single item recovery, litigation hold or inplace hold if any of them are enabled
Move all items out of the folder to somewhere else
Connect to the mailbox using MFCMAPI with the "Use MDB_ONLINE when calling OpenMsgStore" option enabled (see http://support.microsoft.com/kb/2509983/en-us)
Delete the folder using MFCMAPI, with the "Hard Deletion" option. You will get an error message (if it's a system folder), and when you refresh your view the folder will still be there
Move all the items back into the folder
Re-enable single item recovery / hold if required
The move request now works successfully

This is a decent pain, but in my opinion better than export/import as there is no data loss other than maybe some settings on the folder in question. If you're using retention tags and it's a non-system folder, I'd be checking that the tag remained. I did notice some settings I would have thought would be on the folder persisted, so maybe it doesn't actually delete the folder, just fixes whatever is wrong with it.

Unless I get a lot more of these, I'm not going to dig into exactly what is wrong with the folder itself, but hopefully if you are after that, this should give you enough to track it down to that level if you want.

Some other points I noticed:
Every single one of the failed mailboxes we have had have been shared mailboxes, I'm not sure how that fits into the equation, but I'm sure it is a factor. I suspect something with DelegateSentItemsStyle as it is set on the clients accessing every one of the affected mailboxes.
The DataContext from the move request statistics shows Exchange trying to apply folder restrictions on the target has a very interesting filter. The filter seems to point to a specific item, but finding and removing the item from the mailbox does not fix the issue
Doing an export of the properties of the folder before and after deleting it with MFCMAPI shows no differences at all, whatever is fixing the issue presumably is happening somewhere else in the store other than the folder itself
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Follow this checklist to learn more about the 15 things you should never include in an email signature from personal quotes, animated gifs and out-of-date marketing content.
Following basic email etiquette rules will help you write a professional email and achieve a good, lasting impression with your contacts.
In this video we show how to create a Contact in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Contact ta…
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now