[German]A quick note to blog readers who use Veeam Backup 365. Back in November 2025, there were already issues with the integration between Veeam Backup and Microsoft 365 mailboxes. Now, a reader has once again reported the Veeam Backup issue with Microsoft 365 mailboxes to me. This time, the EWS migration planned for Exchange Online starting at the end of 2026 has already cast its shadow. Microsoft rolled out its code change on March 27, 2026, which affects Veeam Backup and leads to errors.
The Veeam Backup Issue from November 2026
Blog reader Christian S. contacted me via email in November to report issues with Veeam Backup when backing up Microsoft 365 mailboxes. At the time, a change Microsoft made to Exchange Online caused Veeam Backup to stop working for some Microsoft 365 mailboxes. At the time, there were sporadic issues or error messages during backups.
I had reported on this in the German blog post Probleme mit Veeam Backup und MS 365-Postfächern (Nov. 2025) and also explained the cause at the time along with possible solutions. There was a discussion on the Veeam forum titled Mailbox errors: The HTTP request was forbidden with client authentication scheme 'Anonymous'. A Veeam Backup user wrote there that since November 19, 2025, he had been receiving severe error messages regarding mailbox objects, and the error:
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
According to research by Veeam and Microsoft, certain Microsoft 365 plans were required to perform a successful backup using Veeam software. Veeam published support article KB4796: The HTTP request was forbidden with client authentication scheme on November 25, 2025.
EWS retirement causes Veeam Backup issue
It is now April 2026, and reader Christian S. contacted us again via email on April 2, 2026 (thank you for that). In his email, he wrote: "This error [with Veeam Backup and Microsoft 365 mailboxes] is back. And this time, it's due to a transition in EWS."
Exchange Web Services (EWS) is being phased out
The background: Microsoft is in the process of retiring Exchange Web Services (EWS). EWS is set to be replaced by the Graph API. This process begins in October 2026 and concludes with the complete shutdown of EWS in 2027. I mentioned this in the German blog post Exchange Online: Zeitplan für das Ende von EWS veröffentlicht. And I had reported on what administrators can do in the post EWS-Apps und deren Nutzung vor der EWS-Abschaltung identifizieren among others.
Microsoft has set the "EWS flag" in March 2026
There's actually still some time left; we have a few months until October 2026. However, Christian mentioned in his email that "they" [the Microsoft developers] had implemented an EWS flag and initially set it to False. In a follow-up email regarding this text, which Christian was able to read in advance, he wrote: "I need to correct my statement about the flag. The flag seems to have been there all along. It just seems to be working properly now. Before, setting either Orga or User to True was enough for it to work. Now both must be set to True or Null. Incidentally, this affects everything that accesses data via EWS. Synology Active Backup for M365 fails in exactly the same way."
Microsoft has published the support article The way to control EWS usage in Exchange Online is changing dated February 20, 2026. There, a follow-up note states:
Update 3/31/2026: This change has now been fully rolled out. If your EWS applications have access problems, please verify your tenant and mailbox level EWS settings.
And it is precisely this change that has caused issues in Veeam Backup 365 when backing up Microsoft 365 mailboxes..
Issues since late March 2026
In this regard, Christian referred to the thread "Mailbox errors: The HTTP request was forbidden with client authentication scheme 'Anonymous'. on the Veeam forum. Since March 30, 2026, there has been a discussion there stating that Veeam Backup users are receiving the aforementioned HTTP 403 Forbidden error when backing up Microsoft 365 mailboxes with Veeam Backup 365 before the actual EWS shutdown deadline, causing the backup to fail.
Veeam addresses this in the support article
Veeam updated its old support article The HTTP request was forbidden with client authentication scheme on April 1, 2026. It states:
It was confirmed on March 27th, 2026, that Microsoft recently applied a patch to correct how Exchange Online enforces Exchange Web Services (EWS) access. Previously, some environments were able to access mailboxes via EWS even when it was not explicitly enabled (i.e., $Null status). After Microsoft corrected this behavior, EWS must now be explicitly enabled at both the organization and mailbox levels for backups to succeed.
Veeam Backup administrators must now respond to Microsoft's change and enable the EWS flag in Exchange Online. To resolve the cause of the above issue, administrators should check EWS access in Exchange Online and, if necessary, configure it so that it is explicitly enabled at both the organizational and mailbox levels. According to Veeam, this can be accomplished using the following PowerShell commands:
#Get the organization's EwsEnabled state. Get-OrganizationConfig | Fl EwsEnabled
#Get all mailboxes where EwsEnabled state is not set to $true.
Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.EwsEnabled -ne $true } | Select-Object Identity, PrimarySmtpAddress, EwsEnabled
If the setting for organizations or mailboxes is not explicitly set to True, access via EWS must be enabled using the following commands:
#Set the organization's EwsEnabled state to $true. Set-OrganizationConfig -EwsEnabled $true
#Bulk set EwsEnabled to $true for all mailboxes where it is not already set to $true.
Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.EwsEnabled -ne $true } | Set-CASMailbox -EwsEnabled $true
If desired, mailboxes can be customized using the following command:
#Granularly set a single mailbox's EwsEnabled state to $true Set-CASMailbox mailbox@address.com -EwsEnabled $true
It may take up to 24 hours for the new settings to be applied and take effect. After that, the backup job must be checked again. Is anyone else experiencing this issue?
