[English]Kurze Information an die Blog-Leserschaft, die Veeam Backup 365 einsetzen. Im November 2025 gab es schon mal Probleme beim Zusammenspiel zwischen Veeam Backup und Postfächern bei Microsoft 365. Nun hat mir ein Leser erneut das Veeam Backup-Problem bei Microsoft 365-Postfächern berichtet. Dieses Mal hat die ab Ende 2026 geplante EWS-Umstellung bei Exchange Online bereits ihre Schatten vorausgeworfen. Microsoft hat seine Code-Änderung am 27. März 2026 ausgerollt, was sich auf Veeam Backup auswirkt und zu Fehlern führt.
Rückblick: Das Veeam Backup Problem von November 2026
Blog-Leser Christian S. hatte mich im November per Mail kontaktiert und über Probleme mit Veeam Backup bei Microsoft 365-Postfach-Sicherungen berichtet. Seinerzeit führte eine Änderung von Microsoft bei Exchange Online dazu, dass Veeam Backup bei Microsoft 365-Postfächern teilweise nicht mehr funktionierte. Es gab seinerzeit sporadische Probleme bzw. Fehlermeldungen beim Sichern.
Ich hatte im Blog-Beitrag Probleme mit Veeam Backup und MS 365-Postfächern (Nov. 2025) berichtet und auch die damalige Ursache samt Möglichkeiten zur Beseitigung erläutert. Im Veeam-Forum gab es dazu die Diskussion Mailbox errors: The HTTP request was forbidden with client authentication scheme 'Anonymous'. Ein Nutzer von Veeam Backup schrieb dort, dass er seit dem 19. November 2025 krasse Fehlermeldungen bei Mailbox-Objekten bekomme, und der Error:
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
gemeldet werde. Nach Untersuchungen von Veeam und Microsoft waren bestimmte Microsoft 365-Pläne erforderlich, um ein funktionierendes Backup mit Veeam-Software anfertigen zu können. Es gab von Veeam dazu den Supportbeitrag KB4796: The HTTP request was forbidden with client authentication scheme vom 25. November 2025. So viel als Rückblick – wenn Microsoft "hustet", bekommt Veeam Backup "Schnupfen".
EWS-Umstellung verursacht erneut Veeam Backup-Problem
Wir schreiben inzwischen April 2026, und Leser Christian S. hat sich zum 2. April 2026 erneut per Mail gemeldet (danke dafür). In seiner Mail schrieb er: "Dieser Fehler [mit Veeam Backup und Microsoft 365 Postfächern] ist wieder da. Und diesmal durch eine Umstellung beim EWS."
Exchange Web Services (EWS) wird abgeschaltet
Der Hintergrund: Microsoft ist dabei, Exchange Web Services (EWS) in den Ruhestand zu schicken. EWS soll gegen Graph API getauscht werden. Dieser Vorgang beginnt im Oktober 2026 und endet mit einer vollständigen Abschaltung von EWS im Jahr 2027. Ich hatte dies im Beitrag Exchange Online: Zeitplan für das Ende von EWS veröffentlicht erwähnt. Und ich hatte u.a. im Beitrag EWS-Apps und deren Nutzung vor der EWS-Abschaltung identifizieren darüber berichtet, was Administratoren tun können.
Microsoft setzt im März 2026 das "EWS-Flag"
Da wäre eigentlich noch etwas Zeit, wir haben noch einige Monate bis zum Oktober 2026. Christian gab in seiner E-Mail aber an, dass "Sie" [die Entwickler von Microsoft] ein EWS-Flag eingebaut haben und dieses erstmal auf False gesetzt hätten. In einer Nachtrags-Mail auf diesen Text, den Christian vorab lesen konnte, schrieb er: "Ich muss meine Aussage mit dem Flag nochmal korrigieren. Der Flag scheint schon vorher dagewesen zu sein. Er funktioniert jetzt wohl nur richtig. Vorher reichte entweder Orga oder User auf True [zu setzen] um zu funktionieren. Jetzt muss beides auf True oder Null stehen. Betrifft nebenbei alles was per EWS auf Daten zugreift. Synology Active Backup for M365 schlägt genauso fehl."
Von Microsoft gibt es den Supportbeitrag The way to control EWS usage in Exchange Online is changing vom 20. Februar 2026. Dort liest man in einer nachträglichen Einblendung:
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.
Und genau dieses Änderung hat bei Veeam Backup 365 beim Sichern von Microsoft 365-Postfächern zugeschlagen.
Es gibt ab Ende März 2026 Probleme
Dazu hat Christian auf den Thread Mailbox errors: The HTTP request was forbidden with client authentication scheme 'Anonymous'. im Veeam-Forum verwiesen. Dort gibt es seit dem 30. März 2026 eine Diskussion, dass die Nutzer von Veeam Backup vor dem eigentlichen Stichtag der EWS-Abschaltung den oben erwähnten HTTP 403 Forbidden-Fehler beim Sichern von Microsoft 365-Postfächern mit Veeam Backup 365 erhalten und das Backup scheitert.
Veeam löst das im Support-Beitrag auf
Veeam hat seinen alten Support-Beitrag The HTTP request was forbidden with client authentication scheme zum 1. April 2026 aktualisiert. Dort heißt es:
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-Administratoren müssen nun also auf die Microsoft-Umstellung reagieren und bei Exchange Online das EWS-Flag umsetzen. Um die Ursache des obigen Problems zu beheben, sollen Administratoren den EWS-Zugriff in Exchange Online überprüfen und ggf. so konfigurieren, dass er sowohl auf Organisations- als auch auf Postfachebene ausdrücklich aktiviert ist. Diese ließe sich laut Veeam mit folgenden PowerShell-Befehlen bewerkstelligen:
#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
Wenn die Ausgabe für Organisationen oder Mailboxen nicht ausdrücklich auf True gesetzt gemeldet wird, muss der Zugriff über EWS mit den folgenden Befehlen aktiviert werden:
#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
Falls gewünscht, können Postfächer mit dem folgenden Befehl individuell angepasst werden:
#Granularly set a single mailbox's EwsEnabled state to $true Set-CASMailbox mailbox@address.com -EwsEnabled $true
Es kann bis zu 24 Stunden dauern, bis die neuen Werte übernommen werden und wirksam werden. Danach ist der Sicherungsauftrag noch einmal zu überprüfen. Ist jemand von diesem Problem betroffen? War das im Vorfeld bekannt bzw. klar?
MVP: 2013 – 2016
Das Problem betrifft auch "Active Backup for Microsoft 365" von Synology.
Danke Hr. Born für Ihren Beitrag. Ich habe schon seit letzter Woche bei einem Kunden mit ABB für MS365 bei einem Konto genau dieses Problem. Und ich fand nirgends die Lösung, da die Fehlermeldung im Log von Synology ein bisschen anders ist als bei Veeam, aber genau dieses Problem betrifft.
@Alle: Das cmdlet Set-CASMailbox MaxM@address.com -EwsEnabled $true lässt sich nicht ausführen auf F1/F3-Lizenzen, da diesen die Berechtigung seitens MS für EWS fehlt. Es kommt die Fehlermeldung:
Set-CASMailbox: ||The operation on Identity "Max M" 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 'Max M' with license 'BPOS_S_Deskless'.
Ist zum Beispiel auch beim Online Kiosk Plan so.
Das ist kein veeam exklusives Problem. Es betrifft alle Programme die auf EWS setzen. Das sollten aktuell noch die meisten Backup- und Archivierungslösungen sein. MailStore kann seit der letzten Version auch Graph, nutzt dies aber nur für neue Archivierungsprofile. Da haben die Anbieter bis zur Abschaltung von EWS im Herbst noch einige Hausaufgaben.
Ich zitiere hier mal einen Mitarbeiter von veeam aus dem im Artikel verlinkten Forums-Beitrag – They say, some vendors practice test rollouts which are called 'scream testing' – what a creative naming, isn't it?
Die Umstellung wird auch bei Commvault Cloud-Backup für Exchange-Online knapp: "Summer 2026"
*ttps://community.commvault.com/platform-updates-47/updated-transition-from-exchange-web-services-ews-to-microsoft-graph-api-11349
Die Smoking Gun wird hier ja völlig ignoriert.
Das Problem ist doch, das der Zugriff vorher ging obwohl der Zugriff nicht korrekt erlaubt wurde. Mag administrativ dem ein oder anderen die Arbeit leichter gemacht haben, aber Sicherheitstechnisch ist das doch eine Katastrophe und jetzt fällt es einem auf die Füße.
Ich sehe bei uns keine Probleme, Mailstore ruft die Mails zur Archivierung korrekt ab.
@Chris: Ich sehe Deinen Punkt, allerdings hat MS nicht die Freiheit den Wert $Null (oder in der PoSh-Anzeige <>) nach ihrem Gutdünken zu interpretieren?
Vorher $Null wie $true, jetzt eben $Null wie $false.
Wer es unzweifelhaft will, muss halt $true oder $false explizit setzen-
So wie es jetzt ist, ist es aber der richtige Ansatz.
Wenn nicht explizit erlaubt = verboten.
Das ist wie mit einer Firewallregel, wo man erst eine deny-all Regel setzt und dann explizit einzelnes erlaubt.
Hätte von Anfang an so sein müssen, den Schuh muss sich MS anziehen. Wäre es von Anfang an so eingestellt gewesen, wäre es auch kein Problem gewesen, weil man dann von Tag 1 darauf trainiert gewesen wäre.
Das Eigentliche Problem sehe ich jedoch beim Hersteller, es ist nicht erst seit gestern bekannt, dass EWS abgeschalten wird.
Warum also kein Update der Veeam App rausbringen, das die EWS Permissions durch Graph Permissions ersetzt? Man wäre MS konform und das Problem wäre gelöst, warum jetzt wieder etwas abgekündigtes erneut aktivieren?
Ich sehe das immer wieder bei Softwarehersteller, dass entweder die MS Ankündugungen gar nicht verfolgt werden und man plötzlich von etwas "neuem" überrollt wird, oder die Hersteller es bis zum Tag X ignorieren und denken MS macht einen Scherz.
Selbes Thema ist mit ServicePrincipalless logins, die angekündigte "deprecation" der Client Secrets usw.
Warum muss immer erst etwas nicht mehr gehen, bis man seine Software so ändert, dass zb. auch Zertifikate bei App-Registrations genutzt werden können.
Klar, MS hat in den letzten Jahren extrem angezogen mit dem Thema Sicherheit, aber ich sehe da auch die Hersteller in der Verantwortung, da man MS nicht immer den schwarzen Peter zuschieben kann, gleich wie MFA wurden auch diese Themen schon lange angekündigt und nicht erst seit gestern.
"Das Eigentliche Problem sehe ich jedoch beim Hersteller, es ist nicht erst seit gestern bekannt, dass EWS abgeschalten wird.
Warum also kein Update der Veeam App rausbringen, das die EWS Permissions durch Graph Permissions ersetzt? Man wäre MS konform und das Problem wäre gelöst, warum jetzt wieder etwas abgekündigtes erneut aktivieren?"
Grundsätzlich richtig, aber die Abschaltung ist von Microsoft für Oktober angekündigt, nicht für April. Laut Veeam arbeiten sie ja auch schon an einer Version, die die Graph-API verwendet, die ist aber halt noch nicht fertig. Das jetzt ist ein Workaround, bis die neue Version veröffentlicht ist. Microsoft hätte sich ja auch einfach an sein bekanntgegebenes Abschaltdatum halten können, ohne schon vorher dran rumzufummeln.
@Rene: "angekündigte "deprecation" der Client Secrets"
Hast Du dafür eine Quelle?
Angekündigt ist es schon lange, aber erst zum Oktober 2026 und dann in Wellen.
Außerdem sind immer noch nicht alle Funktionen von EWS in Graph verfügbar.
Ich sehe da MS und die Softwarehersteller für die nächsten 6 Monate noch mit vielen Hausaufgaben .
Heute hat Veeam die Kunden informiert:
Dear Customer,
We want to inform you of two separate known issues that may impact Veeam Backup for Microsoft 365:
1) Exchange (EWS) Backup Sessions — Action May Be Required
Recent Microsoft control changes to Exchange Web Services (EWS) may affect Exchange backups. If you see backup sessions completing with the error "The HTTP request was forbidden with client authentication scheme Anonymous" starting March 24, please refer to KB4796 and apply the required updates to your EWS configuration to ensure backups continue to run successfully.
2) Issue Opening Restored Items (No Action Required Yet)
Separately, an issue has been identified that impacts Veeam Backup for Microsoft 365. For details, please review KB4835.
At this time, no action is required. However, action will be needed later once we release an update that resolves the issue.
Thank you for your patience during this matter.