M365 Exchange Online | Switching Cross-Tenant Free/Busy

When employees in tenant A need to check the availability of colleagues in tenant B, this has so far been handled via EWS. This interface is being deprecated, and the deadline is approaching: Message Center MC1446796 was updated on October 20, 2026.

The final EWS shutdown is April 1, 2027, even for tenants that have continued to use EWS via the EWSEnabled exception. The replacement is the Cross-Tenant Access Policy. This guide shows how to check if you are affected and what the migration entails.

Set Free/Busy, MailTips, and calendar sharing between tenants to use EWS. If the interface fails, Outlook Desktop will no longer display availability for partner companies in the scheduler, MailTips from the other side will be missing, and shared calendars will remain empty. The outage isn’t noticed in the configuration—it’s the sales team that realizes it when customer appointments are affected.

The rollout of the replacement feature has been ongoing globally since August 2026. According to the Message Center, Free/Busy and MailTips are expected to be rolled out by September 15, 2026, and calendar sharing by October 30, 2026. For GCC, GCC High, and DoD, the rollout is currently paused; Microsoft will announce the resumption date in the Message Center.

Hybrid deployments and pure on-premises scenarios are not affected. For hybrid environments, Microsoft recommends the Dedicated Hybrid App.

A relationship is affected if Enabled is set to True, FreeBusyAccessEnabled or MailTipsAccessEnabled is active, and the partner uses Microsoft 365. Sharing Policies control external calendar sharing:

What matters here is whether the policy is active, contains a domain rule with CalendarSharingFreeBusy access, is assigned to a mailbox, and the counterpart is in Microsoft 365. This also includes anonymous calendar publishing via URL (rules with the Anonymous: prefix).

A technical blog also mentions the Availability Address Spaces with AccessMethod OrgWideFBToken:

This third check point is not explicitly stated in the Message Center version I read. It comes from a secondary source. Still, perform it – the query is purely a read-rights task.

Export the results before making any changes:

Exports are your way back. Without them, after the migration, you won’t know which partner domain had which sharing level.

Only partners using Microsoft 365 are affected. Handle counterparts with on-premises Exchange separately: the Message Center promises further details in upcoming posts. Therefore, split the list into three groups: Microsoft 365 partners, hybrid partners, and on-premises partners.

Microsoft’s migration guide outlines four steps: capture current configuration, set up new policy, validate, and remove old configurations. I haven’t verified the exact click path for the sharing settings because I haven’t read the guide.

Cross-tenant access operates on the principle of mutual trust: the target tenant must explicitly allow incoming access, and the home tenant must explicitly allow outgoing access. Whether the same applies to calendar sharing is not specified in the message. Check the migration guide for clarification and proactively plan for the partner to participate.

Test with a pilot user and a partner: availability in the scheduler, MailTip for the recipient, sharing of a test calendar. Only then remove the old Organization Relationship and the associated Sharing Policy rule. Anyone who cleans up first risks a partner contact suddenly no longer seeing any availability.

The migration isn’t a major project, but it depends on coordination with third parties—which makes it prone to delays. The timeline helps you here: the rollout of the replacement feature for calendar sharing ends on October 30, while the shutdown isn’t until April 2027. That leaves you roughly five months for review, alignment, and testing.

Start with the inventory, not the configuration. Anyone who runs the three queries today and saves the CSVs will know how many partners are affected. If there are zero hits, you're done. If there are five partners, plan five coordination meetings. The EWSEnabled exception is a delay, not a substitute: it applies at most until the final shutdown and only lets you fix the error later.

The exact configuration path remains unclear. Read Microsoft’s migration guide before creating your first policy. And keep in mind the difference from the other EWS topics: the block for F1/F3 licenses and the migration properties are separate issues.