Backup of public folder mailbox fails

[lukasholzknecht]

Since october 13th several of our customers experience issues while trying to backup public folder mailboxes with error "mailbox must be accessed as owner". Anyone else having this issue?
Case #4440395

Regards

[Mike Resseler]

Hey @lukasholzknecht

Please keep working with support. I believe that there are a few changes made on the MFST side.
Keep us informed from the outcome after investigation by our engineers
Thanks
Mike

[DavidRobertson]

Having the same issue here, since the 13th. Case# 04442154.

[jdgsoh]

I'm also experiencing this issue. Since there are already a couple of cases opened by others here, I'm not going to open a new case right away (unless it's recommended to do so).

lukasholzknecht and DavidRobertson, can you post any updates as progress is made on your cases?

Thanks!

[modenthal]

Same issue here. Any updates?

[Mildur]

There is a knowledge base entry for this kind of error. Do you have tried to solve this with the proposed configuration?

https://www.veeam.com/kb3093

[mamosorre84]

Same issue..I would like to have official info before apply https://www.veeam.com/kb3093

[RPoland]

I'm having the same issues.
Does anyone have more up-to-date info?
Thanks,
Rex

[eashdown@ksp.ca]

Same issues here but only on one of several tenants with 365 backups with public folders. A fix from Veeam/MSO would be appreciated.

[Renaud]

Same issue, only for one tenant at the moment.

[JacquesvZ]

Same here. 3 tenants so far, all same error.

Any feedback from Veeam support yet?

[JacquesvZ]

There is a knowledge base entry for this kind of error. Do you have tried to solve this with the proposed configuration?

https://www.veeam.com/kb3093

Tested it on one of my tenants. Broke all mailbox backups, so reverted the change.

[cata81]

Same issue here Case # 04443288

https://www.veeam.com/kb3093

- IPM_SUBTREE OK
- Veeam user is the owner of all public folders

[Mike Resseler]

Some update from our research for everyone suffering from it.

We currently have a workaround, which is being handed out by support. The underlying issue is that MSFT has suddenly disabled certain items that used to be allowed (without telling or notifying anyone, or at least not that we can see).

So you need to change the impersonation (as described in https://www.veeam.com/kb3093) and make sure that the "service account" has a mailbox. Then it will work again.

[DaStivi]

Hello,
since a few days something strange is happening on my O365 Backup Customers... it started with a single customer with a message like this:

14.10.2020: Processing mailbox Test_Kontakte_Ordner_04ecf557@cust1.onmicrosoft.com failed with error: Failed to access public folders.. An internal server error occurred. The operation failed., Mailbox must be accessed as owner. Owner: af00a897-7ca9-412e-88aa-9cec5bc0099a; Accessing user: /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=8856c15c7edc405f991702ebcfd2cd1e-Test_Kontak :: 0:00:51

all others still worked without an issue...
until the 2 days ago,another tenant started to having this issue:

17.10.2020 16:43:29 :: Processing mailbox@cust2.onmicrosoft.com failed with error: Failed to access public folders.. An internal server error occurred. The operation failed., Mailbox must be accessed as owner. Owner: 4ad8e0a6-a06e-4dba-af57-2e18a0eb0a9b; Accessing user: /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=b3874a81a7a945989261564c584bb0d3-PF:: 0:00:50

really wired is that the backup 2h earlier still worked without an issue!
since yesterday, 18.10, 17:20 around another customer started to having this issue... and from yesterday to tonight another customer started with the issue erroring the job...

i've added another new customer right now, that has the issue just from the beginning now, with a slightly different error message though:

19.10.2020 10:52:42 :: Processing mailbox PFMailbox1@cust3.onmicrosoft.com failed with error: Failed to synchronize item changes in folder: IPM_SUBTREE.. An internal server error occurred. The operation failed., Mailbox must be accessed as owner. Owner: 14336876-ab5c-410d-8882-7d52388ecf36; Accessing user: /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=146880985c3c4286bf94d4a2d26f1e29-PFMailbox1 :: 0:01:01

i did not experienced this error before, also nothing hast changed at the specific dates...
i did also found the KB article about such a issue (https://www.veeam.com/kb3093), but first i could not imaging how to do this for all the different customers, even when changing the permissions on the public folders could work, does the proxy impersonisation change in the xml file also work on the Serviceprovider installation??

edit:
also on double checking the KB article, i do not have the "ErrorAccessDenied" messaged mentioned in the article...

and how could it be that that started all suddenly and day-by-day for each client?

anybody else experienced this issue ? i will propably also open a case right now as this looks like to not be normal

best regards
Stephan

[nielsengelen]

@DaStivi I’ve merged your post with the existing topic on this issue. Please see Mike’s response as it is still relevant.

[DaStivi]

ok interessting... i do have this issue in serviceprovider deployment of veeam o365 backup... and i do also see the that for at least one user that broke all other backups too...
as far as i understand the article i have to change some behavoir on my o365 proxy.. so that would affect all tenants i do backup ...

[nielsengelen]

The issue itself can appear on any tenant though so the change would be effective for all as well.

[DaStivi]

the problem is that is i understand the article, i need to the give all the service accounts a mailbox on my customers, so an active, payed o365 license... is a problem for its own, as this will cost the customers again at least a few bucks...

then i need to make the publicfolder permission changes on each an every customer and public folder...
even more what happens if a new public folder is created, then the permissions are missing for the new one...

and finally after every customer is preped i could change the setting on my proxys.

[JacquesvZ]

You can avoid additional licensing cost by assigning a temp license, changing the mailbox to a shared mailbox and then unassigning the license again. Just a headache logging into every tenant to update owner permissions. Also not happy with disabling PF impersonation on a proxy level...

[DaStivi]

Tested it on one of my tenants. Broke all mailbox backups, so reverted the change.

@JacquesvZ you wroted a few post earlier that it broke your mailbox backup and you reverted the changes?

[nielsengelen]

@DaStivi that was related to another KB which is not the same as Mike’s response (which seems to be the solution).

[eashdown@ksp.ca]

@DaStivi that was related to another KB which is not the same as Mike’s response (which seems to be the solution).

I don't see Mike's response as a solution. It's a work around sure but not a solution. As an MSP with multiple tenants and therefor multiple backups, adding an additional license for each backup and turning off application impersonation isn't a fix. Mike put the issue on MSFT which is likely the case but we do need an actual fix from Veeam.

[pcdr11]

I getting the same error, did everything thing KB posted including give backup account a license, tried to exclude the public folder but still get same error, just started last week.

[nielsengelen]

@pcdr11 please work with support if it still fails and let us know the support case ID.

[DaStivi]

....
then i need to make the publicfolder permission changes on each an every customer and public folder...
even more what happens if a new public folder is created, then the permissions are missing for the new one...
...

still a few open questions... i fully understand that veeam propably only is ah passanger on the o365 train and its APIs too.... but at least even the workaround couldn't be ah permant fix for serviceproviders...

i don't even think about asking what happens when not using the "service" account, instead the "registerd application" when modern auth. is required, or even more "security defaults" are enabled, is this still a valid option then, when the "service account" itself can't be used at all correctly? maybe i don't understand how this is handeld at all with the non-basic auth. but, just asking...

please just get my point, when i start changeing the proxy.xml, all my customer tenants in my vbo365 environment has to be prepared first, and even afterwards i'm not sure if this is a permant solution, not blaming veeam, just hoping to give veeam more points against microsoft, as i hope there is some discussion allready gooing on!

[lukasholzknecht]

I don't see Mike's response as a solution. It's a work around sure but not a solution. As an MSP with multiple tenants and therefor multiple backups, adding an additional license for each backup and turning off application impersonation isn't a fix. Mike put the issue on MSFT which is likely the case but we do need an actual fix from Veeam.

Tested Workaround https://www.veeam.com/kb3093 on one of our onPremise installations, seems to work so far.
But as @eashdown@ksp.ca said this is not a really solution for a SP-environment since there's a bunch of organizations for which all public folder permissions had to adjusted, shared mailbox created etc.

[m.novelli]

+1 with this issue on multiple tenants...

[Polina]

All,

The workaround suggested above is not ideal, but it can help you to get things up and running as fast as possible, while our RnD is further researching the issue and working on the hotfix.

i don't even think about asking what happens when not using the "service" account, instead the "registerd application" when modern auth. is required, or even more "security defaults" are enabled, is this still a valid option then, when the "service account" itself can't be used at all correctly? maybe i don't understand how this is handeld at all with the non-basic auth. but, just asking...

With the app-only auth, public folder mailboxes are not supported for backup at all due to the Graph API limitations (KB 3146).

[DaStivi]

ok, the limitations are only there when talking about "security defaults" with disabled legacy auth. methods... but when not using sec.def. for my understanding, when using registered app (mfa requirements/conditional access) public folder backup should and does work.. because on my latest customer i have exactly this... conditional access policys in place, and had to add it with the registred app and apppassword and also got the public folder error now...

btw. when thinking about the workaround for the issue right now... couldn't it be a solution to use the "workaround" for publicfolders on the "security defaults"-Tenants to backup PFs??