Restore Job failed with error "Default folder Root not found"

[kunniyoor]

Hello,
Case # 05713925

I was restoring the emails as usual for MS365 users after the latest cumulative update (Veeam Backup for Microsoft 365 v6a P20220926) and all restore fails with the *error "failed to access mailbox.. the specified object was not found in the store, Default folder Root not found"

Restore was executed by user having MS365 global admin privilege
MS365 authetication didn't show any issue
Tried the same by disabling global admin user MFA on MS365 portal, but no luck

Strange is that, global admin users can restore own emails to his mailbox without any issue.

Best regards
Krish

[HannesK]

Hello,
I recommend to continue with support. I makes little sense to guess on errors like that on a forum.

If you need to restore something "now", then I would take the workaround with export to pst.

Best regards,
Hannes

[kunniyoor]

Hi Hannes,

Thnaks for commenting

For us, we were in the middle of UAT and project finalization when this unpleasent error popped up. Also the support for the escalated case is not moving as expected. So posted the issue here to know whether someone facing kind of issue and got workarround or fix for it.

Thanks again

BR
Krish

[HannesK]

Hello,

Also the support for the escalated case is not moving as expected.

in that situation, there is the "talk to manager" button in my.veeam.com

Sure, you can try the forums, let's see how it goes

Best regards,
Hannes

[kunniyoor]

Hi Hannes,

Thanks for guidance. Sure will ring that the button "talk to manager" and let see how it helps. Meanwhile, hope to see someone comes with a rescue post here.

BR,
Krish

[kunniyoor]

Hi,

Not sure!!! what we tried and observed was a fix for the issue, generally or it is case to case..

Azure App was initially deployed during the base configuration. Cumulative patch got installed later on. As a last sort of action and for curiosity sake we deployed the Azure App once again, seems like that fixed our issue. Restore worked this time!!!!

It was strange!!!

BR,
Krish

[Mike Resseler]

Krish,
This is indeed strange and I am not sure why deploying the Azure App again fixed the issue. I see that the ticket is still open so please update with the "solution" but I still hope they can see what happened

[kunniyoor]

Hi Mike

This trial was carried out in our lab along with veeam support team. Seeing the fix was working in the lab setup, we tried the same with couple of other clients installtions where the similar issue reported but the solution didnt go well.

Puzzled and unsure about what to do about a problem, we are still chaising the Veeam support!!!

BR
Krish

[kunniyoor]

Still inquisitive for a fix...

BR
Krish

[Polina]

Hi Krish,

I'll get the latest state from our support team and get back to you with updates.

[Polina]

Krish,

According to your case details, the ApplicationImpersonation permission was missing in your setup. Could you please confirm if adding this permission helped to fix your restores?

Thanks!

[kunniyoor]

Hi Polina,

Thanks for the update, we will sync with end customer to enable the mentioned change. I'll update the outcome of the actions soon!!!

BR
Krish

[AlexLeadingEdge]

I had the same issue. I was using the Global Administrator login so thought there would be no issue since I should have God-like powers, but it was not so.

I had to log into the Microsoft 365 Admin Center, go into Roles > Role Assignments, click on the Exchange tab at the top, find Discovery Management and add my (user) account to Discovery Management under the Assigned tab on the right, and then in Discovery Management add the Permissions called ApplicationImpersonation.

The mailbox impersonation is now working and the backup restores are all working.