Your Microsoft 365 backup has stopped seeing three places, and nobody changed the policy

On 1 October Microsoft started blocking EWS in Exchange Online, tenant by tenant. Your backup vendor already sent you the email: upgrade the version, review the permissions, everything keeps working. Almost. There are three locations inside Exchange Online for which Microsoft Graph still brings no replacement you can back them up with: public folders, the in-place archive and group mailboxes. One of the three has not been backed up in any tenant anywhere since 1 October. The other two go the day the block reaches your tenant, and no later than 1 April 2027. Meanwhile, there is a Microsoft process that is on by default and has spent months moving old mail into one of those three. Nobody changed your backup policy: the coverage shrank on its own.

The sentence that leaves no room for optimism

EWS went into a siding in 2018, when Microsoft announced it would get no new features, and the shutdown date was put in writing in September 2023. We have spent three years reading calendars. What almost nobody read is the public folders paragraph. The Exchange team wrote it like this, verbatim: Microsoft decided to "restrict programmatic access to public folders to supported Outlook clients only, and for bulk import/export purposes", and then added the sentence that closes the matter: "We will not provide APIs for programmatically creating, reading, updating and deleting public folders after October 2026."

That is not a delay, it is a decision. The consequence has been written down by the backup vendors in their deprecation notices, each in their own words and all with the same content. Druva's, for instance, says the platform "will no longer be able to ingest new data from Exchange Online Public Folders after Oct 1, 2026" and that restoring that data from the console "will not be supported" from the same date. And it explains why there is no plan B: "Microsoft Graph does not currently support the necessary operations for Public Folder backup." This is not a product gap: the missing piece is not going to be manufactured.

Old mail is moving into the blind spot, and it ships by default

This is where it stops being a public-folder matter —which plenty of people no longer use— and becomes a plain-email matter. The second location is the in-place archive, the "Online Archive" the user sees as a second folder tree in Outlook. About the archive, Microsoft wrote in the retirement post: "We are working on delivering access to archive mailboxes via Microsoft Graph and will provide an updated timeline in the coming months." And the timeline did arrive: message centre post MC1469565, dated 9 September, announces general availability between late October and early November 2026, and December for government clouds. It is worth reading what arrives, because it is the import and export APIs plus the archive folder-management APIs, not the incremental read a backup job needs. Which is why the backup vendor we quoted earlier still writes today, in its status guide, that "Microsoft has not released a Graph API for archive mailbox access" and that both the archive and public folders "will continue to rely on EWS beyond October 1, 2026, because no alternative exists".

And now the detail that turns this into a live problem rather than a footnote. Since this year, Exchange Online has auto-archiving: when the primary mailbox goes past 96% of its quota, the Managed Folder Assistant starts moving the oldest items to the archive mailbox until usage drops below the threshold. Microsoft's documentation is generous with the details: each run attempts to move 3% of the quota —3 GB if the quota is 100 GB, with that exact example—, it does not touch anything received in the last 60 days and it honours "Never Move to Archive" tags. A few lines further down is what really matters: "the default setting is enabled" at mailbox level, and "Auto-archiving can't be disabled at the organization level"; the only thing you can touch from above is the threshold.

Put the two together. The primary mailbox, which your backup can read through Graph, slowly empties into the archive, which your backup can only reach through EWS. And EWS is being switched off. Nobody changed a policy, nobody unticked a box: the balance of what is protected drops by itself, 3% of the quota per run, starting with the oldest mail — which, as it happens, is exactly what somebody will ask you for seven years from now in a dispute.

The three locations, and who can read them

What did arrive in May, and why it is not a backup

Microsoft has not been idle: on 7 May 2026 it made the mailbox import and export APIs generally available in Graph. They are useful and they solve migrations. But it pays to read the fine print of its own announcement before writing them down as a substitute for anything. First, the scope: archive mailboxes, public folders and group mailboxes are "not included in the initial GA release" —the same three locations we have been talking about. Second, the format: "the exported item format is intentionally opaque and is designed to preserve item fidelity rather than to serve as a general-purpose interchangeable format". And third, the supported pattern is exporting and importing back into Exchange Online mailboxes.

Translated into the question that actually matters: that gives you the mail back inside Microsoft 365. If what you need is a file somebody can open seven years from now without going through the tenant or your vendor's console —a court order, an audit, a change of supplier— this is not that. It is a data-mobility API, not a legal archive. The problem shows up when it gets sold as the latter.

Your backup's expiry date is set by somebody else's calendar

Back to the Druva notice, because it contains one line that belongs on the whiteboard of anyone who manages cloud backups: "Druva will permanently delete all existing Public Folder backup data on Dec 31, 2026." Today is 12 November. That is 49 days. And look at what the sentence actually says: it does not say the data expires according to your retention policy, it gives a date, theirs.

We are not going after that vendor: its notice is clear, dated and published months in advance, which is more than others manage. We use it because it puts in black and white something almost nobody considers when signing up for backup as a service: the retention you buy lives inside your vendor's product lifecycle. If the API a workload depends on gets retired, it does not just stop being backed up: a window opens to evacuate the history, and the vendor sets that window. Miss it and what was there does not come back. We hit the same asymmetry when we wrote that lowering the recovery window of the native backup deletes copies you already had: raising it is reversible, lowering it is not.

The five-month bridge almost everyone is using

Mechanically, the shutdown works like this. Since October, the EwsEnabled setting in tenants that had not explicitly chosen anything flips to False as the rollout proceeds. An administrator can set it back to True if something critical broke, and there is also an allow list of applications so you do not have to open the door completely. Then comes 1 April 2027: EWS becomes "fully and permanently disabled" and, in Microsoft's words, "the ability to control EWSEnabled will be removed from tenant admins".

What we see in practice is that when somebody's backup job fails, the first reaction is to re-enable EWS and breathe. That is legitimate, and sometimes it is the only thing you can do at nine on a Tuesday. But then it is worth saying out loud what you have bought: a bridge of less than five months, not a solution. And there is a second thing to check in your backup vendor's documentation. Veeam, for example, publishes it without make-up in its article on the EWS retirement, updated on 7 October: once access is blocked, "Exchange Online mailbox backups will fail"; you need version 8.6 or later for the Graph permissions to be configured automatically; and "Microsoft has not yet completed all the Graph API capabilities required — specifically, delta sync support needed for incremental backups". No delta means no incremental: the first Graph-based backup is a full one. On a mid-sized tenant that is not a planning detail, it is a night.

The inventory, in six read-only commands

Before deciding anything you need to know whether this touches you, and how much. Ten minutes with Exchange Online PowerShell answers it. None of the six checks changes anything:

And now the step that turns six figures into a conversation: take the results of 3, 4 and 6 and put them next to what your backup console declares as protected. The difference is not a suspicion, nor an opinion of ours. It is your gap, in objects and in gigabytes, dated today.

The four questions, in writing, to whoever runs your backups

In writing, not on a call. Not out of distrust: because the answers to the second and the fourth need to be re-readable in March.

When NOT to do anything

Start by ruling yourself out. If you have no public folders and no mailbox has an archive provisioned, this does not touch you: two of the commands above confirm it in five minutes and you can go back to your day. The worst thing this article could produce is a December project against a risk you do not have.

And if it does touch you, there are two reasonable-looking reactions we think are worse than the problem. One is pushing the auto-archiving threshold to 100 to stop the leak: per the documentation itself that disables auto-archiving for the entire tenant, and what you have done is trade a hole in the backup for mailboxes that stop receiving mail when they hit quota. If something genuinely has to be excluded, exclude it per mailbox with Set-Mailbox -AutoArchivingEnabled $false or with the "Never Move to Archive" tag, and knowing what you are trading. The other is yanking the public folders out in a hurry. If they have spent ten years as a department's filing cabinet, moving them is a project with its own invoice and its own risk, and December is the worst month of the year to open it. What is urgent is knowing what is inside and being able to get it out —bulk import and export is still allowed, you are not left without a door—; moving is a separate decision, taken cold.

How we work this

We do not sell licences for anything, and we have no favourite backup tool to place either. What we do with a tenant is boring: a Microsoft 365 backup is not a button you switch on, it is an inventory of locations —mailbox, recoverable items, archive, public folders, groups, SharePoint, OneDrive, chats— cross-checked against what the tool claims to protect, plus a test restore every quarter to prove the way back exists. It is the same old list, and it is the one that catches this in October instead of April. It already happened to us with Teams chats, which are not where almost everybody thinks: the pattern repeats because the cloud changes underneath you without asking, and managing the tenant is precisely about reading those changes before anyone feels them.

Failure is inevitable, an outage is a design decision. Here the failure is a vendor retiring an API — it happens, it has been announced since 2018 and dated since 2023 and it is even reasonable, because EWS had security problems of its own. The outage is finding out in April, when your vendor already deleted the history in December and nobody wrote the date down.

Sources (verified 12 Nov 2026): Microsoft, "Retirement of Exchange Web Services in Exchange Online", updated 14 Sep 2026 (blocking from 1 Oct 2026, the public folders sentence and the note on archive mailboxes in Graph); message centre post MC1469565, 9 Sep 2026, "Microsoft Purview: Data Lifecycle Management – Graph API Support for archive mailboxes" (the timeline for Graph access to the archive and its actual scope); Microsoft, "Exchange Online EWS, Your Time is Almost Up", updated 27 Oct 2026 (EwsEnabled states, the AppID allow list and 1 Apr 2027); Microsoft 365 Developer Blog, "Announcing general availability of the mailbox import and export Microsoft Graph APIs", 7 May 2026 (exclusions and opaque format); Microsoft Learn, "Auto-archiving in Exchange Online", updated 26 Jun 2026 (96% threshold, enabled by default per mailbox, 3% per run, 60 days, threshold 100 = disabled); Veeam, KB4820, updated 7 Oct 2026 (job failures, version 8.6 and delta sync); Druva, "Deprecation Notice for Microsoft 365 Exchange Online Public Folder Backups", published 12 Jun 2026 (ingest and restore ending 1 Oct 2026, deletion 31 Dec 2026), plus its EWS-retirement status guide (the archive and public folders keep relying on EWS "because no alternative exists"). The 49-day count is ours, as of the publication date.