Mailbox errors: The HTTP request was forbidden with client authentication scheme 'Anonymous'.

[Polina]

Hi Karsten,

Yes, if you edit your existing organization and select to 'Grant permissions automatically' or add a new organization in an automated manner, they will be added to the app.

[mkevenaar]

Hi Polina,

I have updated to 8.5.0.1014, and the permissions have not been updated when updating the existing Microsoft Entra ID application or when registering a new application. The checkbox "Grant the required permissions to this application and register its certificate in Microsoft Entra ID" has been checked.

This has been tested on two (2) different installations, both on 8.5.

Am I doing something wrong?

[Polina]

Hi Maurice,

No, you're not doing anything wrong — this is a product behavior, not a configuration mistake on your end. And I need to correct what I said earlier: automatic permission granting does not currently update permissions. My earlier statement was inaccurate, and I apologize for the confusion.
Until the next patch, the reliable path is still to manually update the application's permissions in Microsoft Entra ID.

Thanks for your patience and for the detailed repro.

[AlexL]

Am I correct in understanding that for v8.5 no api permissions changes are needed (if upgrading from v8.4) but they are needed for a future update? Else I would have thought that the gui wizard would automatically set them or at least the release notes would mention them. Since neither are I’m assuming no changes needed (for now).

[juerg.hirschi]

confused

"Until the next patch, the reliable path is still to manually update the application's permissions in Microsoft Entra ID."

so you forgot this part ? and we need an update to the upgrade to get automated permission adjustment by running the org setup wizard.
makes quite a difference if i can just run the wizard vs. going into each tenant and do permisson magic manually for our customers.

[mjr.epicfail]

As I can see everything still runs via EWS. For now there is afaik no need to update any permissions yet for production use. It s good to already have the permissions in place but they wont be used until a later patch.

[sumeet]

Hello,

Did v8.5 upgrade. Upgrade successful - thanks.
Post upgrade, to apply the new permissions https://www.veeam.com/kb4820 for EWS retirement, I did the steps in post upgrade section - https://helpcenter.veeam.com/docs/vbo36 ... pplication
Checked the Entra App in azure and I do not see the new permissions.

Ok, maybe the new permissions do not apply with edit organization.
I did the steps to create a new Entra App amd still do not see the new permissions for MailboxItems - https://www.veeam.com/kb4820

Except for the User.Read.All - which already existed, prior to v8.5 upgrade, none of the new permissions from the KB for Miailbox has been applied?

Is this expected? I don't think so. I was hoping Veeam to create the new permissions.

Without the new permissions, the backups for mailbox continue to work - does this mean that post v8.5 upgrade, even if the new permissions are not applied the backup will continue to use EWS permissions, until they expire?
I was hoping the backups to fail. How do we know post upgrade that new permissions are being used and not the old EWS.

Also the documentation does not say that after applying new permisisons, what permissions to remove, which were for EWS and no longer required.

[Mildur]

Hi Sumeet,

Yes, @Polina confirmed in this topic yesterday that the Organization wizard does not handle the permissions in this release.

Without the new permissions, the backups for mailbox continue to work - does this mean that post v8.5 upgrade, even if the new permissions are not applied the backup will continue to use EWS permissions, until they expire?

VB365 does not use Graph yet. Mailboxes are still protected through EWS.
EWS permissions are therefore still required.

Best,
Fabian

[tonynray6]

Hi everyone,

I just wanted to chime in regarding this issue. It appears Microsoft prematurely activated the EWS block on our tenant as of July 1st, completely ignoring their own postponed October 1st deadline. We started experiencing this error yesterday on our F3 mailbox backups:

The HTTP request was forbidden with client authentication scheme 'Anonymous'.

We upgraded to v8.5 and configured all the new Microsoft Graph API permissions per KB4820. However, as Fabian mentioned above, because v8.5 still relies on EWS for mailboxes, our F3 accounts are now completely locked out. The jobs are skipping 600+ mailboxes with the warning: "Mailbox does not have EWS access enabled and will be skipped. For more information, see KB4796."

KB4796 states to enable EWS for the organization as well as the mailboxes. EWS is enabled for the organization, and explicitly enabling EWS on the F3 mailboxes fails:

Set-CASMailbox: ||The operation on Identity "<user>" failed because it's out of the current user's write scope.
License validation error: the action 'Set-CASMailbox', 'EwsEnabled', can't be performed on the user '<user>' with license 'BPOS_S_Deskless'.

I've reached out to MS Support as well as opened a Veeam support case. Hopefully there is an actual fix soon!

Veeam Support Case #: 08149015
Microsoft Support Case #: 2607020040007257

Thanks!
Tony

[Sieben]

Hello everyone!

Any update on the errors that started showing up yesterday for F1/F3/... licensed mailboxes?

I am drowning in hundreds of errors, heeeelp!

[Polina]

Hi Sieben,

Please open a support case to get assistance.

Thanks!