Your Exchange Online backup hangs on a single text field

Microsoft flipped the switch today. From 10 October, in its multi-tenant cloud, a tenant with EwsEnabled set to $true and an empty allowed-application list stops letting every app through and starts letting none through. On 2 October Microsoft recorded which tenants were in that state, and on the 8th and 9th it wrote the list for them, putting in whichever applications it had seen using EWS over the previous 60 days. If you back up Microsoft 365 mailboxes, as of today your backup depends on a list you probably did not write. And there is one thing worth knowing about the parameter holding it: the documentation declares it as <String>.

This week's calendar

The Exchange team published the day-by-day detail on 1 October. On 2 October, end of day Pacific Time, Microsoft records the list of tenants with EwsEnabled set to $true and no EwsAllowedAppIDs. Between the 8th and the 9th, also end of day, it creates that list and populates it with the application IDs seen using EWS over the previous 60 days. And from 10 October it turns on the setting that requires the list to be present when EwsEnabled is $true. That last step, for now, only in the worldwide multi-tenant cloud: other clouds will get their timeline through the message centre.

The behaviour table published in advisory MC1447678 back in August comes down, as of today, to four states. With EwsEnabled set to $true and a list written, only the listed applications get through; that is the one state where you decide. With $true and an empty list, everything is blocked except cross-tenant organisation relationships. With $false, everything is blocked, as always. And with no value set, which Veeam says is where most tenants are, the tenant sits inside the phased retirement Microsoft runs on its own schedule. Further out sits the last date: 1 April 2027, when EWS retires completely.

The list you have may not be yours

That automatic fill is the detail that changes the conversation. Veeam sums it up in its KB4820 article: Microsoft pre-populates the list based on each tenant's observed EWS usage, but only for tenants where the list was not already configured. The criterion is whatever was seen running over 60 days, so the list describes your tenant's recent past fairly faithfully and describes nothing else.

For a daily mailbox backup this plays in your favour: if the job was running, the application was inside those 60 days and should be on the list. The important word is "should". The part about who uses EWS in your tenant and how to inventory it we covered in August's post on the real deadline, back when the list could still be written at leisure.

The parameter takes no add and no remove

In the Set-OrganizationConfig syntax, EwsBlockList is listed as <MultiValuedProperty> and EwsAllowedAppIDs as <String>. For the older lists, Microsoft documents the @{Add="Value1"; Remove="Value2"} syntax, which adds and removes without disturbing the rest. For the new one there is no equivalent, and the vendor says so plainly in its announcement: the cmdlet does not support incremental add or remove operations, and setting the property writes the full list value, so any app IDs already there are replaced unless you include them in the new command.

The pattern Microsoft publishes for changing it is to read the current list, compute the new one and write the whole thing back. It works perfectly as long as whoever does it knows what is in there. The day the mail migration tool has to be added in a hurry and only that ID gets written, your backup's ID disappears: no warning, no error, and nobody meant to do it.

Reading it back has a catch

The command anyone would type, Get-OrganizationConfig | Format-List EwsAllowedAppIDs, returns the field empty even when the list is configured. You have to ask with a switch: Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs. Microsoft documents it in the parameter description and in the Exchange team blog, which also explains why: it is required for performance reasons. Where it is not documented is the Get-OrganizationConfig reference page, checked today carrying a 27 February 2026 revision date, whose syntax only accepts -DomainController and whose EWS example shows the older lists.

There is a September thread on the Veeam forums with two admins who arrived with the same scare: list configured, query blank. What finally returned the values was not the switch on its own but -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs. Worth keeping to hand before concluding the list is not there.

The clocks do not run at the same speed either. Per the Exchange team, changes to EwsAllowedAppIDs take 24 hours to take effect, because servers refresh their in-memory cache once a day, while a change to EwsEnabled usually applies in under an hour, with peaks of up to four. A test run ten minutes after touching the list proves nothing, and pushes you into re-editing something that was already right.

And one sentence in the documentation now means the opposite of what it looks like: to remove the application-ID restriction, it says, you pass $null to the parameter. With the switch on and EwsEnabled set to $true, a tenant with no list blocks everything. The documented escape hatch shuts the door.

Which part of your backup hangs on that field

Veeam keeps a dedicated article, KB4820, published on 25 March 2026 and last modified on 7 October. It affects Veeam Backup for Microsoft 365 — they recommend version 8.6 or later — and Veeam Data Cloud for Microsoft 365. The sentence that matters is short: once EWS access is blocked for your tenant, Exchange Online mailbox backups will fail. We run backups with Veeam and with Proxmox Backup Server, so we do not read this as industry news but as a task.

The same article explains why EWS is still in the picture in 2026, and it names it: what is missing in Graph is the delta sync support that incremental backups need. Microsoft also keeps a public parity gap roadmap with the status of each piece. This is not a Veeam choice or anyone being lazy; it is two calendars that are not in sync.

The hole the outage leaves

When access is restored, KB4820 says, the first job runs a full sync — slower than a normal incremental, though it uses the same storage — and mailboxes not backed up during the gap are left with a missing coverage window in their restore history. The blocked days do not fill themselves in. The job goes green again tomorrow and that green is true going forward, but you do not get last week back: if somebody asks for a mailbox as it stood on Tuesday and Tuesday falls inside the hole, that restore point does not exist.

That turns a PowerShell tweak into a continuity and compliance matter. If your continuity document promises a 24-hour recovery point for email, the day the list falls short that number stops being true and nobody is going to email you about it. It looks like what we saw with Microsoft 365 Backup when you enable it checkbox by checkbox: what is not ticked is not backed up, and the report cannot tell "there was nothing" from "nobody looked".

The layer below does not speak application IDs

If the backup fails for three mailboxes out of four hundred, do not look at the tenant. Each mailbox has its own EwsEnabled, defaulting to $true, and its own allow or block policy, written in user agent strings rather than Entra application IDs. The documentation specifies that the mailbox value is only meaningful if the organisation one is not set to $false; what happens the other way round it does not say. Asked exactly that on their forum, Veeam's product manager answered that they would expect a mailbox-level $false to keep blocking access, and that they would confirm it with the alliance team. When the best available answer is "I would expect", it is worth testing on one mailbox before four hundred.

The 2 April 2027 question

The allow list is a reprieve. On 1 April 2027 EWS goes dark for good and that date has no checkbox to switch it off, so the day after is the one worth thinking about. The Graph gap has a name and a roadmap, as noted; what does not exist on any public page is the sentence saying what backs up Exchange Online mailboxes if that roadmap slips a quarter.

We are asking our vendors exactly that, and it fits in one email: what internal date you are working to for delta sync, and what the plan is if April 2027 arrives without it. A vague answer to that question is information too.

Checks that fit in one morning

• Read the list with the documented switch and, if it comes back blank, repeat it with Select-Object -ExpandProperty EwsAllowedAppIDs before concluding anything. EwsEnabled is read separately. Save that output before touching anything: it is the backup of the list, and there is no other.
• Look at what Microsoft wrote for you on the 8th or 9th and compare it with the EWS usage report. What matters is the applications that did not run in the last 60 days, which are the ones missing by definition; and Microsoft's own apps count, because they get blocked too.
• Confirm your backup tool's ID is in there, and write into the procedure that any change to that parameter is made by reading, recomposing and writing the whole list. That note is worth more than the command.
• If a subset of mailboxes fails rather than all of them, go down to the mailbox: Get-CASMailbox -Identity <mailbox> | Format-List Ews*.
• And look backwards, not just forwards: check whether there are days with no restore point for the mailboxes during this week. It is the check nobody runs, because the dashboard only shows the latest job.

What we would not do: write the parameter without saving the previous value first, because there is no undo and what you erase will not show up in any log you are going to read. Nor would we call it done because the job goes green the next day, which is looking at the side of the calendar that is already fixed. And we would not leave this dependency with no review date, given it has a published expiry still unresolved in April 2027.

A text field standing in front of your backup

What stands out is not the retirement of an old API, which was announced years ago and makes sense. It is that the piece any Exchange Online tenant's mailbox backup depends on today is a text field with no history, no declared owner and no add operation, auto-filled two days ago from a 60-day snapshot. If you administer Microsoft 365, that field just joined your list of critical things, and it is the kind that rarely makes it into any inventory.

Sources: Exchange team blogs on Microsoft Tech Community, "Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement" and "EWS Deprecation Is Here – What This Means To You" (the latter dated 1 October 2026), which are the source of the 2, 8-9 and 10 October timeline, the limitation to the worldwide multi-tenant cloud, the automatic fill from the previous 60 days, the absence of incremental add or remove operations, the read-recompute-write pattern, the query switch and the reason for it, and the 24-hour and under-one-hour timings. Message centre advisory MC1447678, dated 5 August 2026, for the behaviour table and the cross-tenant exception. Microsoft Learn references for Set-OrganizationConfig, Get-OrganizationConfig and Set-CASMailbox (parameter types, @{Add=…} syntax, user agent strings, mailbox default value and the note about $null), all checked on 10 October 2026. Veeam article KB4820, "What Microsoft's EWS Retirement Means for Your Veeam Backups", published 25 March 2026 and modified 7 October 2026: products and versions, backup failure, full sync with a missing coverage window in restore history, automatic pre-population only where no list existed, and delta sync as the pending Graph capability. Public Veeam forum thread on EwsAllowedAppIDs, from September 2026, for the query that does return the values and for the product manager's answer about the mailbox level. We have not verified any figure in this article against customer tenants: everything above is public documentation.