This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(121.6, 43%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EIG%3C/text%3E%3C/svg%3E)
Hey everyone...I'm doing a cutover migration from Intermedia to O365(I've done one successfully already for another tenant) using Outlook Anywhere endpoint/cutover migration and I'm running against "Transient error ObjectNotFoundException has occurred" on several mailboxes after initially migrating some of the data without issue. Some mailboxes sync just fine however, but almost half of them fail with this error! I'm thinking the mailboxes themselves have some corruption or something on them but am unsure how to resolve since I don't have full admin access to the Exchange server. I tried one of the culprit mailboxes to run outlook.exe /cleanfinders but that didn't help. I also tried to completely blow away the migration, remove all mailboxes/users, create a new migration and endpoint, but same issue at same place for the same users where it keeps running up against that error and then eventually gives up. A google search didn't really find any fix to this other than most ended up having to do a pst export and then import. Problem is that a couple of these users have very large mailboxes. Aside from trying a third party tool like bittan, or doing a pst export/import for the failed mailboxes that already have some of the email in them, i'm scratching my head trying to figure this one out. Going to also create a ticket for the O365 team, but not sure how much help they would be.
No firewalls in the mix here, at least any that I'm able to manage. Seems to me it's strictly related to the user data but since the error log doesn't really state where it's failing I literally have no idea how to repair this. I also am unable to move the mailbox to another database either, but could potentially ask Intermedia to try it.
Oh yes, they are running Exchange 2016 actually over in Intermedia.
thanks everyone for any input!!!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(198.4, 62%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJZ%3C/text%3E%3C/svg%3E)
Hi @Isaac Gonzalez ，
For further troubleshooting, we want to confirm something with you:
Do these problematic mailboxes have something common? Are they in the same database? As you have mentioned above, you could ask Intermedia to try to migrate one of these problematic mailboxes to another database and then please check if the issue continues.
In addition, are there any related error messages in application logs？
HI @Joy Zhang-MSFT .
I ran a Get-MigrationUserStatistics user@keyman .com -IncludeReport -DiagnosticInfo verbose | export-clixml c:\temp\movereport.xml on one of the mailboxes that is failing and I do have that available. The only relevant message is the over and over failure saying "Transient error ObjectNotFoundException", but it doesn't specify anything else other than this. Since there is under 25 total mailboxes, it appears that they all reside on the same mailbox database at Intermedia. Four more users who successfully completed sync the first time with my initial migration batch/endpoint are failing now. Intermedia may not just simply create a new database and move a mailbox to it, as they will only do this when a mailbox user has an issue with their service. Currently we have 0 reported issues with Outlook and it is failing on half of our users(11 out of 22). Before it was 7 out of 22. Any ideas on how to figure this out? Doing a PST import will be a daunting task and is essentially my only option as imap migration won't capture calendar. Thus I pretty much have to get the cutover working. I did a cutover migration for about 20 users a few months ago with no issue for a different Intermedia tenant, although they were running Exchange 2013, not 2016.
Hi @Isaac Gonzalez ，
Could you please compare the values of the MAPIBlockOutlookRpcHttp and MapiHttpEnabled with working well mailboxes and problematic mailboxes? To get the values of the MAPIBlockOutlookRpcHttp and MapiHttpEnabled, you could run below command:
Get-CASMailbox MailboxName | FL MAPIBlockOutlookRpcHTTP, MapiHttpEnabled
If the values are different between the working well mailboxes and problematic mailboxes, you could use the Set-CASMailbox to modify these values. Detailed information for your reference: Set-CASMailbox
hi @Joy Zhang-MSFT , I think this command may be intended on running on the on premise exchange which I have very limited powershell command access to. Nonetheless I ran this on the O365 side and all users have same values:
MAPIBlockOutlookRpcHttp : False
MapiHttpEnabled :
I deleted a duplicate contact in the source server hoping that would somehow remedy this but am still running up against that error for the same mailboxes unfortunately. I have a case opened with microsoft and sent them extensive details such as proof that remote connectivity works, and all the logs, etc. I'm also unable to get Intermedia to move any mailboxes to another db as their health check comes up clean....
Hi @Isaac Gonzalez ，
Based on above all information, your migration configuration and actions seem work correctly, the issue is more related with mailboxes themselves. It is hard for us to do a further troubleshooting on the issue since you don't have enough permission to do something on prem sever.
I also considered this as 9 mailboxes out of 22 consistently failed after trying from scratch a few times @Joy Zhang-MSFT
I then shifted to third party BitTitan that migrated mailbox items over without this issue, so there is something in those mailboxes that the built in Microsoft migration tool does not like(maybe a \ in the folder name?)...I wish there was a better meaningful error to handle this so I could fix the source and use the built in Microsoft tools as they are actually very good for the cutover migration if it all goes smoothly....but the error is way too vague to decipher where and what the problem even is. I am wondering if they can have better debugging to show which folder or email it's having the issue with.
Hi @Isaac Gonzalez ，
Glad to hear that you have migrated mailboxes successfully via 3rd tool.
As I know, all migration information is recorded in Migration user statistics for a specific user in new Exchange admin center (New EAC) and if there are skipped item, the details of these item will be recorded. Besides, I have done some research, there seems no other way to trace the migration statistics in exchange side.
To migrate the mailboxes, the admin must have one of the following permissions:
The migration administrator must be assigned the FullAccess permission for each on-premises mailbox.
or
The migration administrator must be assigned the Receive As permission on the on-premises mailbox database that stores user mailboxes.
For instructions about how to set these permissions, see Assign Exchange permissions to migrate mailboxes to Office 365
Also, check this blog for more insight - How to Decide on a Migration Path in Exchange Online?
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
hi @Amit Singh thanks so much for your response. I have already fully verified that the mailbox user I am using to migrate the mailboxes has FULLAccess permissions on ALL mailboxes in question and in addition I had Intermedia assign impersonation access after my first initial migration attempt had the exact same issue. It's not that it cannot sync the mailboxes at all, actually it partially syncs them and then loops with the error described above. If the migration user didn't have full access permissions it would fail to sync at all...that is not the case here!
I think I may be running against a bug with the Microsoft migration tool and Hosted Exchange 2016. I did another Intermedia tenant and assigned exact same permissions and did not run into this issue. Also Intermedia is unable to move any mailboxes to a different database. They ran a health check on their end and none of the mailboxes in question have any issues. The cutover migration is pretty much the only path we can go here. Imap won't capture calendars so that is not an option. The PST export/import will be daunting as there are several large mailboxes and I don't have local access to the exchange server(only limited powershell access), so that is not really an option either unfortunately. Cutover is really the only way to go here using Outlook Anywhere.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(105.60000000000001, 38%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETO%3C/text%3E%3C/svg%3E)
We have been facing this issue since October. We have seen this affect 50+ different migration organizations, all with a different source environment. We have contacted Microsoft Premier in October and for the past 3 months, we have been going in circles with Microsoft only asking us to run command after command on the source environments whilst seemingly never looking at the Migration tool in question.
It's quite strange because in several occasions, the tool was syncing all mailboxes properly for several days, then all of a sudden several accounts would start failing and the reports show the error "Transient error ObjectNotFoundException has occurred." Considering we are seeing this behavior of most migrations since October, all with different source Exchange environments, we simply cannot accept this to be a source issue.