Synology Microsoft 365 Backup: EWS, Microsoft Graph and Recovery Explained

Quick answer: Synology Active Backup for Microsoft 365 3.0.0 migrates supported personal mail, calendar and contact backups to Microsoft Graph. Some services still depend on Exchange Web Services, or EWS, during the transition. An effective review checks the installed version, protected workloads, application permissions and representative restores. A successful backup task alone does not establish that every required item can be recovered through the intended route.

For an organisation protecting Microsoft 365 data, the important question is not simply whether the backup package has been updated. It is whether a deleted message, older project document or affected mailbox can be recovered when the business needs it.

Highlights

• The API transition affects the connection path. It does not change the need to define what must be backed up and restored.
• Version 3.0.0-14300 was released on 20-Aug-26. Its migration covers supported personal mailbox services, while other scenarios retain EWS dependencies.
• October 2026 begins a phased change. Microsoft’s permanent EWS retirement in Exchange Online is planned for April 2027.
• Backup and restore permissions are different checks. Test the actual recovery operation, not only authentication.
• A NAS repository needs protection too. Capacity, access control, power continuity and an independent recovery copy belong in the design.

What the EWS and Microsoft Graph Transition Means

EWS and Microsoft Graph are interfaces used by applications to access cloud services. Replacing one with the other is therefore an application and permissions change, rather than a reason to replace a healthy NAS automatically.

Synology’s 20-Aug-26 release moves Personal Mail, Personal Calendar and Contacts to Microsoft Graph. Its September migration notice also makes a useful distinction: updating supported services does not remove every dependency on EWS.

Remaining scenarios identified in Synology’s migration guidance include archive mail, group mail and group calendars, along with services hosted in the China region. These need to be considered separately from an ordinary personal mailbox. Coverage should be mapped to the actual protected service and installed backup product.

October 2026 and April 2027 Are Different Milestones

Microsoft’s Exchange Online timetable begins phased EWS disablement in October 2026 and moves to permanent retirement starting 01-Apr-27. It should not be described as a single simultaneous switch for every tenant, nor as an identical retirement of on-premises Exchange Server.

For administrators, that means the tenant’s current access settings and rollout notices matter. A service depending on EWS may need a documented transition arrangement while its supported replacement is prepared. An update to a related product is not evidence that the particular dependency has disappeared.

Record the relevant application, workload and tenant state before changing access. Coordinate changes with the Microsoft 365 administrator and the organisation’s security requirements. A blanket instruction to enable legacy access is not a substitute for identifying the specific dependency.

Start with the Data the Business Must Recover

A user count is not a complete backup specification. Two organisations with the same number of users can have very different mailbox sizes, shared data, retention periods and recovery expectations.

A useful inventory names the services and data types, the owners, the required historical versions and the acceptable recovery destination. Personal mail, shared or group scenarios and archive content should be listed separately where they are required.

Consider an accounts mailbox containing older supplier correspondence and a project library with frequently revised drawings. Finding yesterday’s message and recovering the correct version of a drawing are different tests. Both can matter even if a dashboard displays one overall job status.

Recovery Point and Recovery Time: Define Both

Recovery point objective, or RPO, describes how much recent data the business can tolerate losing. Recovery time objective, or RTO, describes how long it can tolerate waiting for the required service or data to be restored.

For a worked example, an incident at 11:00 with the latest recoverable point at 02:00 leaves a nine-hour gap. That may be acceptable for one workload and unacceptable for another. The time needed to locate, restore and validate the data is a separate question.

Application Permissions and Credentials Need Their Own Review

The cloud application used by the backup task needs the correct permissions, consent and valid credentials. Access to the NAS administration interface does not establish that the application can reach the required Microsoft 365 service.

Restore requirements deserve particular attention during the transition. Synology describes Mailbox Import for Exchange restores when EWS is disabled, with an update to the Microsoft Entra ID application credentials. A working backup connection does not prove that this restore path has been prepared.

When a task reports an EWS, permission or 403 error, keep the job details and existing recovery data. Distinguish the affected workload, access path and application before rebuilding tasks. Deleting a task or backup set can add a second problem without correcting the first.

How to Run a Meaningful Restore Test

Use approved sample data or an authorised recovery request, with a safe destination that avoids overwriting live content. The test should reflect the operation the business would actually request.

1. Choose representative data. Include important supported workloads and any exceptional mailbox or archive scenarios in scope.
2. Check the recovery point. Confirm the required item or version exists at an acceptable time.
3. Use the intended recovery route. Test restoration or export through the route that would be used in an incident.
4. Open and validate the result. Check the content, attachments or document version with an authorised owner.
5. Record the elapsed time and limits. Keep enough evidence to show what was recovered and what remains outside the tested scope.

A small restore test does not prove that a full mailbox or large library can be recovered within the same time. Use a second, appropriately sized exercise when the recovery objective depends on a larger operation.

Where a Synology NAS Fits

A compatible NAS can provide a separate repository for supported Microsoft 365 data. That creates another recovery location, but also another system to size, secure and maintain.

The Synology DS925+ is one hardware option to evaluate for a local repository. Its four-bay form does not, by itself, determine the number of users or years of history it can protect. Start with protected data, retained versions, growth, backup windows and the required recovery speed.

Raw disk capacity is not the same as usable repository capacity. RAID configuration, retained history, filesystem overhead and working headroom all affect the space available. A design based only on the current size of cloud data can run short when versions and growth are included.

The repository also needs a recovery plan of its own. RAID addresses a drive-failure scenario; it does not create an independent off-site copy. Administrative separation and another protected copy address different risks from power continuity. The NAS and network UPS planning guide explains how to protect the repository and its required network path.

NAS Package or Dedicated Backup Appliance?

Active Backup for Microsoft 365 is a package-based deployment on a supported Synology NAS. ActiveProtect is a different product platform, with appliances such as the DP320. Their version requirements and operating instructions should not be mixed.

Compare them around supported workloads, management needs, retention, required recovery operations and how the repository will be protected. Reusing a suitable existing NAS and deploying a dedicated appliance are operational choices, not a simple comparison of the number of drive bays.

A Practical Review Checklist

• Record the exact backup product and installed version.
• List required services and any archive, shared or group scenarios separately.
• Review task warnings and the latest recoverable point for each workload.
• Verify application credentials and the required restore permissions.
• Complete representative restores to an approved destination.
• Check repository capacity, access separation, power and its independent recovery copy.

Frequently Asked Questions

Can EWS be disabled immediately after updating the package?

Not on the assumption that the update removes every dependency. Some scenarios still rely on EWS during the transition. Identify the protected services and their supported access path first.

Does this mean Microsoft 365 has no native recovery features?

No. Microsoft 365 has its own retention and recovery capabilities. An independent backup should be assessed against the organisation’s required coverage, retention and recovery control.

Are ActiveProtect and Active Backup for Microsoft 365 the same product?

No. They are different Synology offerings. Use the version requirements, supported workloads and operating process for the installed product.

Which details are needed to size a backup repository?

The protected data size, supported services, retained versions, expected growth, backup window and recovery objectives are more useful than user count alone.

What does a successful test establish?

It establishes that the tested data was recovered through the tested route under the recorded conditions. Broader workloads, larger restores and untested destinations require their own evidence.

Build Around Recoverable Data

The EWS transition is a reason to inspect the whole recovery path: service coverage, cloud access, repository and restore process. Updating the package is one step. Knowing which data can be recovered, to where and within what time makes the result useful to the business.