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

[Dagr]

Would be nice if someone at Veeam could list the affected licenses in https://www.veeam.com/kb4796 instead of
"To resolve this issue, ensure that a supported Microsoft 365 plan that includes full Exchange Online and Graph API support is used ".

[track1044]

@Polina,
I'm hoping you can help clarify some concerns around kb4796 and the October 2026 EWS deprecation timeline.
We're trying to plan ahead and need to understand whether KB4796 was based on confirmed Microsoft guidance or if it was a response to what turned out to be a temporary issue that has since self-resolved.

The KB states these licenses need to support Graph API, but the Microsoft documentation linked in the KB itself just shows that these licenses don't have EWS access—the other Microsoft documentation shows all licenses support Graph API.
This makes it look like an EWS availability issue rather than a Graph API support issue.
Your comment about RnD "researching a longer term solution" combined with "no certainty it won't reoccur" suggests the Graph API implementation might not be fully ready to replace EWS yet.
With October 2026 bringing global EWS deprecation, we're concerned about whether this same scenario will happen again but permanently.
Is the KB addressing a licensing gap or a transitional state while Veeam completes the EWS to Graph migration?

For planning purposes, our clients would collectively need to spend roughly 1.5 million US dollars yearly to upgrade all affected licenses based on KB4796's guidance.
We need to understand whether this is a permanent licensing requirement or a temporary workaround while the Graph API transition is completed. Any clarity you can provide on the roadmap and timeline would be incredibly helpful for our client planning.

[Polina]

Hi David,

We plan to fully switch from EWS to Graph well before the planned deprecation date. Veeam's RND is already working on it.
Graph support for those currently impacted limited licenses still needs to be confirmed by our engineering, but the current assumption indeed is that it'll do the job.
The "HTTP request was forbidden" issue seems to be self-resolved atm, but our RND keeps monitoring and investigating it. If it re-occurs, KB4796 will remain relevant - atm, we cannot see any other and more suitable workaround.

[cc-kyle]

Having similar issues intermittently with a shared mailbox. We'll get the 'anonymous' error in the evening run of the job, but it will go through without complaint in the morning run. Doesn't seem like that makes much sense if it's a license issue...

Case # 03485895

[Patrik87]

Same issue here to.
Yesterday 2 mailboxes, today 7.

2 of them has Exchange Kiosk Online license - should not work.
Rest of them has F3 licenser activated..
Case number: 07898202

Can also verify that our failed mailboxes are fine today.
Veeam needs to work on a solution with MS because EWS will be disabled under 2026...

[DHuppertz]

I can also confirm that bakups from all customers were fine last night

[Dagr]

Also confirming the issue was resolved.

[Zoddo]

Microsoft has started to send messages center communication regarding deprecation of EWS access for Kiosk / F1 / F3 licences starting on March 1, 2026.
The communication points to this blog article: https://techcommunity.microsoft.com/blo ... rs/4474299

What are the Veeam's plans for this new deadline?

[zer0]

Update to EWS Access for Kiosk / Frontline Worker Licenses
We're making some changes to Exchange Web Services (EWS).
Starting March 1, 2026, we will start to block EWS access for all mailboxes without license rights to EWS. This is another step in our ongoing commitment to enhance the security and control mechanisms of EWS.
How this will affect your organization:
The impacted licenses are:
• Exchange Online Kiosk
• Microsoft 365 and Office 365 F1
• Microsoft 365 and Office 365 F3
As stated in the Service Descriptions, these licenses do not provide access to mailboxes via EWS, but these restrictions were never enforced. With this change, EWS access for users with only these license types will be blocked.
What you need to do to prepare:
If you wish these users to continue to use EWS, and your users are licensed with one of these noted above, you’ll need to assign a new license, one containing EWS access rights. For example, you could assign an Exchange Online Plan 1 or 2 license, or a Microsoft 365 or Office 365 E3 or E5 license.
Starting March 1, 2026, requests to use EWS without a suitable license will result in a HTTP 403 response.
Learn more: Update to EWS Access for Kiosk / Frontline Worker Licensed Users
View in the Microsoft 365 admin center

[DaStivi]

can someone please test some mailbox restores?
i've got the same "The HTTP request was forbidden with client authentication scheme 'Anonymous'." Message while a restore for a mailbox now ?!

[Mildur]

Hi Stephan,

That issue can have multiple root causes.
Please contact customer support so we can review the logs and verify the issue.

Thank you,
Fabian

[ACrispiels]

Since yesterday, same issue for me with some (not all) mailboxes (or archived mailboxes) with different licenses like Business Basic, Business Premium or Teams
VBO release 8.3.0.2201
I don't think it's an EWS access issue because it has been resolved in its time
I do not open a case

[Mildur]

Hi Alain,

Unfortunately we can’t comment on or verify anything without an active support case.
Please open a case if the issue still exists today.

Thanks,
Fabian

[ACrispiels]

Hi Mildur,
Opening a case is cumbersome, slow, intrusive, and only unnecessarily overloads your services, which is why I don't do it often, knowing that others have already done so for the exact same reasons.
I will therefore wait and hope for a quick resolution.
Thx

[DaStivi]

Since yesterday, same issue for me with some (not all) mailboxes (or archived mailboxes) with different licenses like Business Basic, Business Premium or Teams
VBO release 8.3.0.2201
I don't think it's an EWS access issue because it has been resolved in its time
I do not open a case

Have you possibly enabled the m365 baseline settings ? And disabled EWS there ? I noticed there is an recommended Option to disable EWS already... That of course would break vb365 for now

[ACrispiels]

Thanks for the advice, DaStivi.
Nothing has changed in the baseline settings in the last few days, and I double-checked that Microsoft hadn't done anything without my knowledge.
I also checked the EWS option.
What bothers me right now is the random nature of the problem, where only certain mailboxes, with equivalent licenses, are affected.
There are already differences between the mailboxes affected yesterday (the first day of the problem) and today.
So I'll analyze this with a bit more perspective, and if I really have no other choice, I'll open a case (the solution I'm considering as a last resort because I don't like doing it).

[admd]

Hello all,

Same for us since yesterday night. This error came back.
A lot less user are affected.
We didn't touched anything.
Case #08036687 for the logs

Thanks !

[track1044]

We are also seeing this again on some users on multiple different environments today.
Case #08036816

[Polina]

HI All,

Our RND is already looking into it. Atm, I can only assume that some change happed on the Microsoft side.

[DaStivi]

btw. there has been some issue with EXO, also had some media attention... maybe its related to this too..

https://support.nhs.net/2026/03/microso ... devices-2/

EX1256020

[Acknowledge]

Hello,
we've also seen it on multiple tenants today, only on one yesterday, the Veeam KB article says it's resolved so started some jobs again but we're still getting results with the exact same issue, am gathering logs at the moment and will make a case for support.

https://www.veeam.com/kb4796

[lmendel]

Same here, 1 tenant yesterday, multiple Today

[kikanq]

Hello !
Try this: https://www.veeam.com/kb4820

This fix resolve my problem

PS line:
Install-Module ExchangeOnlineManagement -Scope CurrentUser
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@yourcompany.pl
Get-OrganizationConfig | Select-Object EwsEnabled

When show this:

EwsEnabled
----------


You must try this:
Set-OrganizationConfig -EwsEnabled $true

Now this command:
Get-OrganizationConfig | Select-Object EwsEnabled

and you must see this:

EwsEnabled
----------
True

[DaStivi]

that would be a bold move from Microsoft to just disable EWS allready.. really strange, more and more customers from my Service Provider Environment are also affected now!

[Polina]

They say, some vendors practice test rollouts which are called 'scream testing' - what a creative naming, isn't it?

[Pat-Klbl]

We got the same error with different types of Licenses:
- M365 Business Basic (Not all Users, only some)
- Unlicensed (Gets the error, not the standard: Mailbox does not have a valid Microsoft 365 license Total count of failed items)
- Exchange Online

[aeph]

We tried to enable EWS for the affected organization (Set-OrganizationConfig -EwsEnabled $true), but the error continues to occur in the daily jobs (3 days ago).
Is there anyone else who has these problems?

[DHuppertz]

Same problem here: also enabled EWS, but it didn't work for a user with M365 Business Basic license (only for one user, other users with the same license are OK)

[TeamM365]

We tried to enable EWS for the affected organization (Set-OrganizationConfig -EwsEnabled $true), but the error continues to occur in the daily jobs (3 days ago).
Is there anyone else who has these problems?

You are not alone.
According to KB4796 Veeam is already actively working with Microsoft to resolve this issue

[athome]

I see the problem on a customer as well, and the strange thing is we get 100% hit rate on error on the job that does backup of mail and archive, while the job that backups one-drive run 100% successful at the moment.
SR: #08041848