rss.livelink.threads-in-node

Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy

The_Exchange_Team — Fri, 07 Aug 2026 19:19:23 GMT

If your organization shares Free/Busy, MailTips, or calendars with other Microsoft 365 organizations, there's a change coming that you'll want to understand and plan for. If it doesn't, you can stop reading in about two paragraphs. This post covers what's changing as Exchange Web Services (EWS) is deprecated, how the new Microsoft 365 Cross-Tenant Access Policy model replaces the old plumbing, how to tell whether your tenant is affected, and what to do about it. The official announcement is Message Center post MC1446796; consider this the friendlier, more complete version with the context we wish the MC post had room for.

Is your organization impacted by this change?

Only if your organization shares Free/Busy, Calendars, or MailTips information with other Microsoft 365 organizations.

This change affects cross-tenant / cross-organization collaboration - the ability for people in your organization (Organization A) and people in a partner's Microsoft 365 tenant (Organization B) to see each other's Free/Busy availability, shared calendars, and MailTips (such as out-of-office notices). If you've set up these relationships with subsidiaries, partners, vendors, or recently acquired companies, you need to understand this and take action before the deadline, or those experiences will break.

Organization sharing is not set up by default – tenant admins must have set it up by themselves.

Not impacted scenarios:

Sharing Free/Busy availability, calendars, or MailTips within your organization.
Sharing Free/Busy availability, calendars, or MailTips between your on-premises and online users in an Exchange Hybrid Deployment. You should work on your Dedicated Hybrid App as per our previous announcements.
Sharing Free/Busy availability, calendars, or MailTips with another organization running on-premises Exchange. Watch for future Message Center posts covering this scenario (no immediate impact but changes are coming). If you are sharing with a partner organization running both Exchange Online and on-premises, the sharing with Exchange Online is impacted.

The “How to check your sharing configurations?” section below has more information on how to verify.

What's changing, and why

Deprecation of Exchange Web Services (EWS) begins on October 1, 2026. Several cross-tenant collaboration features - Free/Busy, MailTips, and Calendar Sharing – currently use Exchange Web Services under the hood. As EWS is retired in Exchange Online, the mechanism that carries those cross-tenant requests has to move somewhere else.

That “somewhere else” is Microsoft 365 Cross-Tenant Access Policy. It replaces the EWS-based approach, and it becomes available starting September 2026. The end state is the same experience your users have today - someone sees a colleague's calendar availability across a tenant boundary - but it travels over a modern, Entra-governed path instead of legacy EWS. It's part of the broader push to retire legacy protocols and eliminate high-privilege access.

How the new model works

Today, three Exchange Online configurations drive cross-tenant sharing:

Organization Relationships - used to share Free/Busy and MailTips with other Microsoft 365 tenants.
Availability Address Spaces - used to share Free/Busy with other Microsoft 365 tenants (specifically those set with AccessMethod: OrgWideFBToken).
Sharing Policies - used to share calendars externally, either through invitations sent to recipients in other Microsoft 365 organizations, or calendars published for anonymous access via an internet URL.

Historically, each of these has used EWS to fetch availability and MailTips from the partner tenant. Going forward, that trust and data exchange is expressed through Microsoft 365 Cross-Tenant Access Policy instead. You still decide which partner organizations you collaborate with and what you share; only the mechanism carrying it changes. Migrating means understanding your current configuration, standing up the equivalent Cross-Tenant Access Policy, validating that sharing still works, and then removing the old configurations you no longer need.

How to check your sharing configurations?

MC1446796 was sent to every tenant but most admins who received it won't actually need to do anything. So before you plan a migration, confirm you're in scope. Run these three commands in Exchange Online PowerShell:

Get-OrganizationRelationship | Format-List Name, DomainNames, Enabled, FreeBusyAccessEnabled, FreeBusyAccessLevel, FreeBusyAccessScope, MailTipsAccessEnabled, MailTipsAccessLevel, MailTipsAccessScope

You're affected if the results show Enabled: True, and either FreeBusyAccessEnabled: True or MailTipsAccessEnabled: True, and the external organization is hosted in Microsoft 365. Otherwise, no action is needed.

Get-AvailabilityAddressSpace | Format-List ForestName, AccessMethod

You're affected if the results show AccessMethod: OrgWideFBToken and the external organization is hosted in Microsoft 365. Otherwise, no action is needed.

Get-SharingPolicy | Format-List Name, Domains, Enabled, Default

You're affected if the results show Enabled: True, the Domains property contains at least one rule with a CalendarSharingFreeBusy access level (Simple, Detail, or Reviewer), the targeted external organization is hosted in Microsoft 365, and the policy is assigned to one or more mailboxes. Otherwise, no action is needed.

One note on that last check: rules that begin with Anonymous: represent calendar publishing to anonymous internet recipients through a published URL, and they show up in the same output. If you have an Anonymous: rules with a CalendarSharingFreeBusy access level (Simple, Detail, or Reviewer) then you are affected.

The rollout schedule for Cross-Tenant Access Policy

This feature becomes available starting September 2026, so your migration window opens as the rollout reaches your environment. Here's the schedule:

Environment	Rollout begins	Expected completion
Worldwide	August 2026	September 1, 2026
GCC	Mid-August 2026	Mid-September 2026
GCC High	Early September 2026	End of September 2026
DoD	Early September 2026	End of September 2026

What happens if you do nothing?

Starting October 1, 2026, EWS will be gradually disabled in Exchange Online, in line with the deprecation communications we've been sending for a while now. As that rollout reaches your tenant, any cross-tenant Free/Busy, MailTips, and Calendar Sharing that still depends on EWS will stop working - people in your partner organizations may no longer see Free/Busy, MailTips, or shared calendars coming from your tenant. You may no longer be able to see Free/Busy, MailTips, or shared calendars from the partner organization. If you're in scope and take no action, that's the outcome.

Not ready by October? You have a runway

We realize that the window between this announcement and the start of the rollout is short. For organizations with many partner tenants and a tangled web of organization relationships, analyzing, testing, and executing a migration in a few weeks is a tall order, and we know it.

There is a safety valve. You can keep the existing cross-tenant sharing working by setting EWSEnabled to True, following the guidance in our earlier post, Exchange Online EWS, Your Time Is Almost Up. That keeps the old path alive while you prepare and execute the migration. This extension remains available until the final EWS shutdown on April 1, 2027 - which is the hard deadline for completing the move.

You do not need to specify AppIDs in your tenant Allow List to keep the old method working, as it doesn’t rely on AppIDs (as it doesn’t use OAuth). If EWSEnabled is set to True, we’ll allow the cross-tenant flows covered here to continue working until April 2027, no matter the tenant Allow List state.

What you need to do

Confirm scope. Run the checks above. If nothing flags, you're done.
Plan your migration for after the rollout reaches your tenant and before EWS deprecation affects you. Review the migration guide for step-by-step instructions.
Migrate - understand your current configurations, set up the new Microsoft 365 Cross-Tenant Access Policies, validate that sharing works, and remove the configurations you no longer need.
If you can't finish by October 1, set EWSEnabled to True to keep sharing alive until you can migrate, no later than April 1, 2027.

Frequently Asked Questions

We cannot make the October deadline for this migration. Other than setting EWSEnabled to True for our tenant, do we need to add some AppID to the tenant EWS Allow List?
Setting EWSEnabled to True is all that you need to do to keep your current configurations for sharing with other organizations working. You do not need to add anything to the EWSAllowedAppIDs tenant value. Please note that both your and your partner Microsoft 365 organization need to set EWSEnabled to True to continue bidirectional information sharing.

What happens if we set up sharing using the new model on my side but the partner organization does not?
For bidirectional sharing, both organizations need to configure Microsoft 365 Cross-Tenant Access Policies and disable the old configurations before sharing will work in both directions.
For one-way sharing, only the resource tenant (the tenant with the mailboxes that contain the Free/Busy, Calendar, or MailTips information) needs to configure a Microsoft 365 Cross-Tenant Access Policy. Once configured, users in the home tenant (the tenant with users trying to access the shared information) will be able to access the information via Cross-Tenant Access Policy. Ensure both organizations disable old configurations for sharing as these will prevent requests from flowing through the new Cross-Tenant Access Policy.

What happens if we extend EWS deprecation in my tenant but the partner organization does not and we do not complete the migration before EWS deprecation starts?
After EWS is disabled in the partner organization, users in your organization will no longer be able to access information shared from the partner organization. Users in the partner organization will continue to be able to access information shared from your organization.

We have a Sharing Policy with a Wildcard in the domain. Do we need to migrate it?
Yes, as long as the CalendarSharingFreeBusy access level is Simple, Detail, or Reviewer.

What if we are sharing with multiple domains that are in the same partner Tenant ID?
Create a single Microsoft 365 Cross-Tenant Access Policy to configure sharing with the partner Tenant ID. Any domains associated with the partner Tenant ID will be covered by the policy.

What if we have an Availability Address Space with Google Workspace for Google/Exchange Calendar Interop?
You are not affected by this change. Users in Exchange Online can continue to access calendar information of users in Google Workspace via the Availability Address Space configuration. Users in Google Workspace can continue to access calendar information of users in Exchange Online via Microsoft Graph API. Ensure Google Workspace is configured to connect to Exchange Online via Microsoft Graph API and not the legacy EWS connection method. See: Allow Google Calendar users to see Exchange availability

What if we have an Availability Address Space configuration for sharing Free/Busy between commercial cloud (most customers world-wide) and 21Vianet cloud?
You are affected and should migrate your configuration to Microsoft 365 Cross-Tenant Access Policy.

The Exchange Online EWS Deprecation Team

Get-EXOMailbox -Filter returns empty when $WarningPreference = 'SilentlyContinue'

DavidB2390 — Fri, 07 Aug 2026 14:08:28 GMT

Get-EXOMailbox -Filter returns empty when $WarningPreference = 'SilentlyContinue' under UAMI app-only auth

Module version: ExchangeOnlineManagement 3.x (PS7, Azure Automation sandbox)

Auth method: Connect-ExchangeOnline -ManagedIdentity -ManagedIdentityAccountId <UAMI ClientId>

Reproduction steps:

$WarningPreference = 'SilentlyContinue'

Connect-ExchangeOnline -ManagedIdentity `

-ManagedIdentityAccountId "<UAMI-ClientId>" `

-Organization "yourtenant.onmicrosoft.com" `

-ShowBanner:$false

# Returns empty — mailbox provably exists

Get-EXOMailbox -Filter "ExternalDirectoryObjectId -eq '<EntraOID>'"

# Restore and retry — returns correctly

$WarningPreference = 'Continue'

Get-EXOMailbox -Filter "ExternalDirectoryObjectId -eq '<EntraOID>'"

Expected: Mailbox object returned regardless of $WarningPreference

Actual: Returns $null when $WarningPreference = 'SilentlyContinue'

Notes:

Only affects -Filter parameter under app-only/UAMI auth
-Identity and -UserPrincipalName are not affected
Delegated auth sessions are not affected
$WarningPreference = 'SilentlyContinue' is a common pattern in Azure Automation runbooks, making this a significant undocumented breaking behaviour for automation scenarios

HCW - Hybrid Configuration Wizard for Hybrid Certificate

jt8585 — Tue, 04 Aug 2026 18:42:01 GMT

I've gone through about 5 Microsoft Exchange Support Engineers for last two years with Exchange on-line migration and 80% of time running HCW, it caused email outages where the engineers did not know what to do. They've also gave conflicting information on how to correctly run HCW for adding server and to replace certificate. Some say use powershell and some says do not use powershell.

Now, I need to replace the hybrid certificate, do I uncheck everything and check only "Update Secure Mail Certificate for connectors" in a centralized transport setup (email flows through on-prem servers) ? I assume uncheck everything will not roll back configurations. I have Microsoft Exchange engineers says it will and some say it won't and they all say they have 20+ experience.

Writeback for Cloud-Managed Remote Mailboxes: Now Generally Available

The_Exchange_Team — Mon, 03 Aug 2026 12:58:46 GMT

In May, we announced the Public Preview of Writeback for Cloud-Managed Remote Mailboxes. Since then, many customers have enabled this feature and shared their feedback. Today, we're excited to announce that Writeback for Cloud-Managed Remote Mailboxes is now Generally Available (GA).

Writeback is available in WW, GCCH, DoD, and 21Vianet environments and supports up to 600,000 cloud-managed mailboxes per tenant.

A quick recap

Cloud-Managed Remote Mailboxes allow organizations to transfer the Source of Authority (SOA) for a directory-synchronized mailbox's Exchange attributes to Exchange Online by setting IsExchangeCloudManaged to true.

The user identity remains synchronized from on-premises Active Directory but Exchange attributes become editable in Exchange Online. Administrators can update these properties through Exchange Online PowerShell, the Exchange admin center, or the Microsoft 365 admin center.

Writeback extends this capability by synchronizing a critical set of Exchange attribute changes from Exchange Online back to on-premises Active Directory through Microsoft Entra Cloud Sync. This helps organizations whose on-premises line-of-business applications continue to read Exchange attributes from Active Directory.

If you already use Microsoft Entra Connect Sync, you don't need to uninstall or replace it. Cloud Sync runs alongside Connect Sync:

Connect Sync continues to synchronize your directory identities and attributes as before.
Cloud Sync handles Exchange attribute writeback.

What's new at GA

Support for up to 600,000 cloud-managed mailboxes

During Public Preview, writeback supported tenants with fewer than 200,000 cloud-managed mailboxes. At GA, the supported scale increases to 600,000 cloud-managed mailboxes per tenant.

This expanded scale enables larger organizations to adopt cloud-managed Exchange attributes while keeping the required Exchange attribute values current in on-premises Active Directory.

Writeback for the MAIL attribute

One of the most requested feature during Public Preview was support for writing the mail attribute back to on-premises Active Directory.

Based on this feedback, GA adds the mail attribute to the supported writeback set. Changes made to WindowsEmailAddress in Exchange Online can now be written back to the corresponding mail attribute in Active Directory.

The supported writeback set now includes 24 attributes, including:

extensionAttribute1 through extensionAttribute15

msExchExtensionCustomAttribute1 through msExchExtensionCustomAttribute5

```
msExchRecipientDisplayType
```
```
msExchRecipientTypeDetails
```
```
proxyAddresses
```
```
mail
```

For the complete attribute list, see Identity, Exchange Attributes and Writeback.

Existing Public Preview configurations require one update

Exchange attribute writeback configurations created on or after August 3, 2026 will have mail writeback enabled by default. No additional action is required for newly created configurations.

Configurations created before August 3, 2026 aren't updated automatically to writeback mail attribute. If you enabled writeback during Public Preview:

Open your Exchange Online attribute writeback configuration in the Microsoft Entra admin center.
Select Attribute mapping and then Restore default mappings.
After the synchronization job restarts, mail writeback will be enabled.

Detailed guidance is available in the Frequently Asked Questions section of the documentation.

Important reminder about tenant-wide SOA

Tenant-wide Exchange attribute SOA is intended for organizations that have completed mailbox migration to Exchange Online and no longer create Exchange mailboxes, mail-enabled users, or remote mailboxes on-premises.

Don't enable tenant-wide SOA while on-premises mailbox migration or recipient creation is still ongoing. Doing so can cause a newly synchronized Exchange recipient to appear in Microsoft Entra ID as an identity-only user without the MailUser required in Exchange Online. This blocks mailbox onboarding and migration.

Review the prerequisites and guidance in Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments before enabling tenant-wide SOA.

A path towards removing the last Exchange Server

Cloud-managed Exchange attributes and writeback help organizations continue using Active Directory for identity while removing their dependency on an on-premises Exchange Server for recipient management.

When you're ready to remove the server, follow Decommission the last Exchange Server after transferring SOA to cloud. The guide covers prerequisites, hybrid cleanup, Exchange Server uninstall, and post-uninstall cleanup in Exchange Online.

Exchange-attribute SOA applies to user objects with Exchange Online mailboxes. Organizations that want to manage mail-enabled groups or mail contacts from the cloud should use Group SOA or Contact SOA transfer.

Get started

Review Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments.
Follow How to enable Exchange attribute writeback.
Review the complete writeback attribute list.
Read the last Exchange Server decommissioning guide.

Thank you to everyone who participated in the Public Preview and shared feedback. Your input led to us adding mail attribute writeback for GA.

We look forward to hearing about your experience with the GA release.

Exchange Online Management and Exchange Hybrid teams

Outlook - Online mode address book search fails with "Operation failed" when Name only is ticked.

Gustavo94 — Fri, 31 Jul 2026 12:55:46 GMT

I hope you had this issue and managed to solve 😂 pulling my hair already.

Symptom:

In classic Outlook for Windows, open the Address Book → set Search to Name only → type any single character → "The address book operation failed." Switch to More columns and the exact same search works fine. Ctrl+K resolution in the To: field works. OWA people search works. Mail flow is fine. It's only the Name-only ANR seek in the dialog.

Environment:

Exchange hybrid, mailbox in Exchange Online, dir-syncedfrom on-prem AD via Entra Connect

Classic Outlook for Windows, online mode (Cached Mode is not permitted here — this is the constraint, I can't just flip it)

Affects all users, all machines

What I've already ruled out:

Test Result

Other address lists (Contacts, All Users) Same failure
Ctrl+K in To: field Works
Safe mode (outlook.exe /safe) Same failure — not add-ins
Multiple accounts / multiple machines Same failure
Brand-new mail profile Same failure — not profile corruption
Addressing order (Tools > Options) GAL set first, not "Choose automatically"
Off corporate network (5G) Same failure
AddressBookPolicy / OfflineAddressBook on mailbox Both blank (inherit defaults)
Get-OfflineAddressBook Default OAB, IsDefault: True, web dist enabled
Get-GlobalAddressList Default GAL, IsDefaultGlobalAddressList: True, stock default RecipientFilter

Import Bulk PST to Office 365 Step by Step | Stellar Migrator for Outlook

GiulianoDeLuca — Tue, 28 Jul 2026 10:03:37 GMT

Learn how to import bulk PST files to Office 365 (Exchange Online) step by step using Stellar Migrator for Outlook. This tutorial walks you through automating the migration of multiple PST mailboxes to Exchange Online — no manual uploads, no scripting.

Stellar Migrator for Outlook automates bulk PST-to-Office 365 migration, letting you map source PSTs to target Office 365 mailboxes (Primary, Archive, or Public Folder), apply filters, and run the whole job with minimal effort — without worrying about duplicate emails. It's a reliable way to move legacy mailboxes into Office 365.

Using a CSV file, you can migrate unlimited PST files to Office 365 users from the same system or across networked systems. The software also supports incremental migration, so you can resume or re-run a job and only new items get imported — no duplicates, no reprocessing what's already migrated.

Learn more: https://www.stellarinfo.com/import-pst-to-office-365.php

Exchange Online PowerShell Updates to 3.10.1 to Fix CBA

TonyRedmond — Mon, 27 Jul 2026 09:33:55 GMT

Microsoft rushed out version 3.10.1 of the Exchange Online management PowerShell module to fix a problem with certificate-based authentication. It seems like a change in an internal Microsoft identity platform caused the tokens issued after a successful connection to Exchange Online to not authorize the execution of further cmdlets. To their credit, Microsoft fixed the issue, but is this the kind of thing that should be caught in testing?

https://office365itpros.com/2026/07/27/exchange-online-management-3-10-1/

Apple Mail EWS sync intermittent after EwsEnabled=True + AppID allow list

stringworks — Thu, 23 Jul 2026 17:15:28 GMT

We're a small Microsoft 365 Business tenant (Exchange Online Plan 1/2 mix). One user's Apple Mail (macOS, Exchange/EWS account) intermittently stops syncing new mail — Connection Doctor shows a healthy green "Connection and login to server succeeded," but Get New Mail/manual fetch and forced Sync All Accounts return nothing new, while the same mail is already present via ActiveSync on the same user's iPhone/iPad. Symptoms recur every 1–3 days after temporarily resolving.

Troubleshooting completed so far:

- Confirmed autodiscover/External URL correctly resolves to outlook.office365.com/EWS/Exchange.asmx

- Confirmed EWS enabled at the mailbox level (Manage email apps in admin center)

- Found EwsEnabled was blank/null at the org level — set to $true via Set-OrganizationConfig

- Configured EwsAllowedAppIDs to include Apple's app ID (f8d98a96-0999-43f5-8af3-69971c7bb423, "Apple Internet Accounts")

- Fully removed and re-added the Mac Mail account after the above org-level change

- Restarted the Mac, tried DNS changes (8.8.8.8/8.8.4.4), ruled out router-level filtering

- Verified no antivirus/VPN/security software on this Mac's network

Despite all this, the issue persists intermittently. Notably, a second mailbox on the same tenant, used with Apple Mail on a different Mac (different macOS version, different physical location/network), does NOT experience this issue — so it doesn't appear to be a blanket tenant-wide EWS disruption.

Given Apple Mail's continued reliance on EWS ahead of the October 2026 phased disablement, and Microsoft's acknowledgment that Apple Mail for Mac is a heavy EWS consumer they're working with Apple to migrate to Graph, I'm wondering:

1. Could this be related to the ongoing "scream test" EWS disruption testing Microsoft has mentioned, and if so, is there a way to check whether a specific mailbox has been included in that testing?

2. Any known differences in EWS session/connection handling between macOS versions that could explain one Mac being affected and not the other?

3. Anything else worth checking tenant-side (throttling policies, CAS mailbox settings, conditional access rules) that could apply per-mailbox rather than tenant-wide?

Happy to provide EWS usage report data or run any diagnostic commands if it helps others hitting the same thing before October.

account only remote wipe device

adsnow — Tue, 21 Jul 2026 02:05:02 GMT

Hello,

My o365 account is E3. My phone is android, I installed outlook on my phone.

I tested to wipe the outlook on my phone with my admin account, but after I click the "account only remote wip1e device", it showed "Saving in progress", then showed a red "X".

The client is Outlook for iOS and Android, client type is outlook not EAS.

Do I need more steps to wipe outlook on my phone? or a role/permission is missed?

Thanks and regards,

Adsnow

Reminder: Exchange 2016 and 2019 ESU Program Ends in October 2026

The_Exchange_Team — Mon, 20 Jul 2026 18:10:45 GMT

Over the last several weeks we have received several questions about possible extension of the Exchange Server 2016/2019 ESU program past October 2026. After all, in our original Exchange 2016/2019 ESU announcement we said that there would be no extensions, but then we ended up creating a Period 2 Exchange ESU program that is scheduled to end with October 2026. We are just about at the mid-point of Period 2 Exchange ESU now.

There will be no further extension of Exchange 2016/2019 ESU program timeline. Once October 2026 ends, there will be no further updates for Exchange 2016/2019, even if you currently have a Period 2 ESU.

If your organization still uses Exchange 2016 or 2019 in production:

See Upgrading your organization from current versions to Exchange Server SE | Microsoft Community Hub – which lays out the path for how to migrate to Exchange SE if you plan to keep Exchange on-premises.
Why “in-place upgrade” from Exchange 2019 to Exchange SE is low risk | Microsoft Community Hub – which explains why in-place upgrade from Exchange 2019 CU14/CU15 to Exchange SE RTM is not a significant technological change and is low risk.

Please review Microsoft Exchange Online and Exchange Server Licensing FAQs especially "What is Exchange Server Subscription Edition (SE) and how is it licensed?” section. Exchange 2019 and Exchange SE licensing requirements are the same.

The Exchange Server Team

Reference Architecture for an On-Premises AI Assistant for Microsoft Exchange.

Vinay_Prakash — Mon, 20 Jul 2026 08:07:51 GMT

Bringing Secure AI Capabilities to On-Premises Microsoft Exchange

Many organisations continue to operate Microsoft Exchange within their own data centres because of regulatory requirements, data-residency policies, security considerations, operational dependencies, or the need to maintain complete control over sensitive email information.

At the same time, users increasingly expect Artificial Intelligence to help them manage growing email volumes, understand long conversation threads, locate information quickly, analyse attachments, and prepare relevant responses.

This creates an important question:

Can organisations introduce AI-assisted email capabilities without migrating their on-premises Exchange environment or sending email data to public AI services?

With the right architecture, the answer is yes.

The opportunity for AI in on-premises Exchange

Users spend a significant amount of time reading lengthy email chains, searching for previous discussions, identifying action items, reviewing attachments, and preparing responses.

An AI-powered email assistant can help reduce this effort while continuing to operate within the organisation’s controlled infrastructure.

Such a solution can be integrated with Microsoft Exchange through an Outlook Web App, or OWA, Add-In. The Add-In provides AI-assisted capabilities within the familiar Outlook Web interface and can be centrally deployed to selected users or Active Directory groups by the Exchange administrator.

The purpose is not to replace Exchange or change the way emails are managed. Instead, it introduces an intelligence layer that helps authorised users interact more efficiently with the email information they are already permitted to access.

Key capabilities of an AI-powered Exchange Email Assistant

1. Email and conversation summarisation

The assistant can summarise an individual email or an entire conversation thread.

Instead of reading every message in a long chain, the user can receive a structured summary covering:

The purpose of the conversation.
Important decisions and commitments.
Key action items.
Deadlines and pending responses.
Relevant information available in attachments.

The summarisation process can consider both incoming and sent messages so that the complete context of the conversation is preserved.

2. Contextual draft reply generation

The assistant can prepare a suggested response based on the complete email thread and the user’s instructions.

Users may select an appropriate tone, such as:

Formal.
Neutral.
Technical.

The generated response is placed in the user’s Exchange Draft folder or displayed for review within the OWA Add-In.

A critical control is that the AI assistant does not independently send the email. The user remains responsible for reviewing, editing, approving, and sending the response.

This human-review approach helps organisations adopt AI while retaining accountability over external and internal communications.

3. Natural-language mailbox search

Traditional mailbox search generally depends on exact keywords, sender names, subjects, or date filters.

An AI-enabled search experience allows users to search their mailbox using natural-language questions, such as:

“Find emails received last month regarding the infrastructure renewal.”
“Show unread emails from the finance team that require my approval.”
“Find the discussion where the customer confirmed the delivery date.”
“Summarise emails from a particular sender concerning the purchase order.”

The solution can combine semantic search with traditional keyword-based search to improve the relevance of results.

Users can also apply filters such as sender, subject, date range, read or unread status, and conversation thread.

4. Attachment analysis and OCR

Important information is often contained within email attachments rather than the email body itself.

An on-premises AI assistant can process supported documents, including:

PDF files.
Microsoft Word documents.
Microsoft Excel files.
Scanned documents.
Image-based attachments.

Optical Character Recognition, or OCR, can be used to extract information from scanned or image-based documents.

The extracted content can then support email summarisation, contextual draft generation, and mailbox search.

For example, a user may ask the assistant to prepare a response based on the commercial terms or delivery date mentioned in an attached document.

Maintaining strict mailbox privacy

Mailbox privacy is one of the most important architectural considerations for an enterprise AI email assistant.

Each user must only be able to access and process emails from their own authorised mailbox. Information retrieved from one user’s mailbox must never become available to another user.

This isolation should be enforced across every layer of the solution, including:

User authentication.
Exchange access tokens.
Application sessions.
Search indexes.
Vector embeddings.
AI prompts and responses.
Cache and temporary data.
Audit logs.

The backend should validate the authenticated user and verify mailbox ownership for every request made to Exchange.

Where vector search is used, mailbox data should be stored in user-isolated collections, partitions, or namespaces. This helps prevent cross-user retrieval at the data layer rather than relying only on controls within the user interface.

Operating without public cloud AI services

For organisations with strict security or data-sovereignty requirements, the AI models and supporting components can be deployed within the customer’s infrastructure.

A fully on-premises architecture may include:

A locally hosted Large Language Model.
An on-premises embedding model.
A re-ranking model.
A vector database.
A keyword-search engine.
A backend API layer.
An OCR or document-intelligence service.
A secured OWA Add-In.
Integration with Active Directory.
Audit, monitoring, and administrative controls.
The entire solution can operate within an internal network without sending email content, attachments, prompts, or generated responses to public AI platforms.

This model can also support air-gapped environments where internet access is either restricted or completely unavailable.

Centralised deployment and administration

The OWA Add-In can be deployed centrally through Exchange administration controls.

Administrators can assign the Add-In only to selected users or security groups. Employees who are not assigned the solution will not see the AI assistant within their Outlook Web interface.

Administrative controls may include:

User and group assignment.
Enabling or disabling individual AI features.
Summarisation-only mode.
Draft-generation controls.
Attachment-size restrictions.
Session and retention policies.
Model and performance settings.
Usage monitoring.
Audit logs.
Resource utilisation monitoring.

These controls allow organisations to begin with a limited group of users and gradually extend the solution after validating performance, security, and user adoption.

Security and governance considerations

Introducing AI into an enterprise email environment requires more than deploying a language model.

The complete solution should be designed around security, privacy, governance, and responsible AI principles.

Important considerations include:

Authentication and authorisation

The solution should integrate with the organisation’s existing identity infrastructure, such as Active Directory, and enforce role-based access controls.

Encryption

Email content, attachments, indexes, logs, and other sensitive information should be encrypted both in transit and at rest.

Data retention

Organisations should clearly define whether AI prompts, generated summaries, and draft content are retained.

In privacy-sensitive environments, generated content may remain available only for the active session and should not be permanently stored by the AI application.

Auditability

The system should record relevant operational events, such as the user identity, requested function, timestamp, and processing status.

Depending on the organisation’s policy, the actual email or generated response content may be excluded from audit logs.

Human oversight

AI-generated responses should be treated as suggestions. The user must review and approve them before sending.

The assistant should also disclose its limitations and avoid presenting uncertain outputs as confirmed facts.

Performance and capacity

On-premises AI processing depends on available compute, memory, storage, and GPU resources.

The architecture should account for:

Number of concurrent users.
Average mailbox size.
Volume and size of attachments.
Expected response time.
Model size.
Search-index growth.
OCR processing requirements.
High availability and backup requirements.

A practical adoption approach

Organisations do not need to introduce all capabilities at once.

A controlled proof of concept can begin with a limited number of users and a defined set of features.

A practical implementation sequence may include:

Phase 1: Email summarisation

Start with individual email and conversation-thread summaries. This provides immediate value while keeping the initial architecture relatively focused.

Phase 2: Contextual draft replies

Introduce draft generation with mandatory user review and clearly defined tone controls.

Phase 3: Attachment processing

Enable OCR and document parsing for supported attachments.

Phase 4: Intelligent mailbox search

Index authorised mailbox content and introduce natural-language search with strict per-user isolation.

Phase 5: Wider deployment

After security testing, performance validation, and user feedback, extend the solution to additional departments or user groups.

Conclusion

Organisations operating on-premises Microsoft Exchange do not necessarily need to choose between maintaining control over their email environment and adopting AI-assisted productivity capabilities.

A carefully designed on-premises AI email assistant can support email summarisation, contextual draft preparation, attachment analysis, and natural-language mailbox search while keeping sensitive information within the organisation’s infrastructure.

The most important success factors are not limited to the AI model itself. Identity controls, mailbox isolation, human approval, auditing, infrastructure sizing, and data-governance policies are equally important.

For organisations evaluating private, sovereign, or air-gapped AI, on-premises Exchange can become an effective starting point for introducing practical AI capabilities in a secure and controlled manner.

Connect with us to implement this solution in your organization.

About the Author

Vinay Prakash is the CEO of Glorious Insight and an Ex Microsoft Employee. He works with organisations on Data, Artificial Intelligence, Microsoft cloud technologies, enterprise applications, and secure on-premises AI solutions.

For technical discussions related to private or on-premises AI adoption, he can be reached at:

Email: email address removed for privacy reasons

The Demise of the OWA Light Client

TonyRedmond — Fri, 17 Jul 2026 09:46:02 GMT

On July 8, Microsoft said that they will retire the OWA Light client for Exchange Server in August 2026. But what happened to the OWA Light client for Exchange Online? It seems like Microsoft announced the retirement of OWA Light for Exchange Online in June 2024, but didn’t really make the fact clear in a blog post about consumer accounts. In any case, you can’t run OWA Light for Exchange Online, even if you wanted to.

https://office365itpros.com/2026/07/17/owa-light-retirement/

Exchange 2019 + ADFS is it possible to configure ModernAuth for third-party Android mail clients?

DeadAuroraUz — Fri, 17 Jul 2026 05:18:21 GMT

Hello,

Our organization operates under Uzbekistan's data localization and banking secrecy regulations, which require customer and corporate data — including email — to remain on infrastructure physically located within the country and under direct regulatory oversight. This precludes the use of cloud-hosted mail services such as Microsoft 365/Exchange Online, and requires a fully on-premises Exchange deployment with local identity federation (AD FS) instead of Azure AD.

Environment:
Exchange Server 2019 CU14, single server (MX01), pure on-premises.
AD FS is registered as an AuthServer (Type: ADFS), no Azure AD / hybrid tenant involved.
The AuthServer is configured correctly: AuthorizationEndpoint and TokenIssuingEndpoint are populated, IsDefaultAuthorizationEndpoint: True, and DomainName points to our mail domain. Realm/ServiceName are configured as well.

Symptom:
The native iOS Mail client (account added manually, no MDM profile) correctly redirects to our AD FS login page on first setup — the full Modern Auth flow works.

A third-party EAS client (Nine by NitroDesk, Android) never receives an OAuth challenge at all — it falls back to Basic authentication.

Get-ActiveSyncVirtualDirectory/Set-ActiveSyncVirtualDirectory in this build simply has no -OAuthAuthentication parameter (unlike EWS/OAB).

Log finding:
When testing with the Nine client, the following was captured in the Exchange HttpProxy/Eas logs:

S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<domain>'. S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable

Questions:

What exactly controls "Flighting" for EAS OAuth in a pure on-prem Exchange 2019 CU14 + AD FS scenario (no Azure AD)? Is there a documented, supported way to enable it (New-FlightOverride? something else)?
Is EAS Modern Auth even supported for an arbitrary/generic OAuth client (not Apple, not Outlook) in this scenario, or is it effectively an allowlist limited to specific client_ids (Apple Native Mail / Outlook)?
How does native iOS Mail get redirected to AD FS without ever receiving an authorization_uri in the EAS/Autodiscover 401 challenge — is there an undocumented discovery path (e.g., hardcoded per registered client_id)?

Thank you in advance for any insight.

Cross-Tenant Message Recall and Duplicate DDG Detection Enhance Exchange Online Messaging

TonyRedmond — Wed, 15 Jul 2026 08:45:38 GMT

Last week, the Exchange development team announced two interesting developments. Stopping duplicate dynamic distribution groups and cross-tenant message recall. Preventing tenants from creating duplicate DDLs saves service resources and might make tenants easier to manage. The real value is in cross-tenant message recall, which solves a problem by allowing users to recall messages delivered outside their tenant. The facility only works if the receiving tenant allows, but nothing can be done for messages delivered outside Microsoft 365.

https://office365itpros.com/2026/07/15/cross-tenant-message-recall/

How to Check Distribution Lists for Activity Over the Last 90 Days

TonyRedmond — Wed, 15 Jul 2026 08:44:31 GMT

The new Get-MessageTraceV2 cmdlet can fetch 90 days of message trace data, which means that we can check for inactive distribution lists using data for the last 90 days instead of being constrained to the last 10 days. This is done by running fetches for nine batches of traffic, each covering ten days.

Distribution lists are still important to Exchange Online and Microsoft 365, and it’s good to know which distribution lists are in active use (and how much traffic they get) and which are not. All done with PowerShell.

https://office365itpros.com/2026/07/09/inactive-distribution-list-2026/

Released: July 2026 Exchange Server Security Updates

The_Exchange_Team — Fri, 24 Jul 2026 18:41:35 GMT

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The July 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed by these SUs and do not need to take any action other than updating any Exchange servers or Exchange Management tools workstations in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on ‘Server Software’ under Product Family for Exchange SE and ‘ESU’ under Product Family for Exchange 2016 and 2019).

Check for presence of legacy Exchange security groups

While not directly related to our July 2026 SU release, we wanted to call out that Exchange Health Checker script will now also check for the presence of very old, deprecated Exchange Server security groups, namely Exchange Domain Servers and Exchange Enterprise Servers. Those groups have been deprecated since Exchange 2007, should not be in use, and should be deleted as they might provide more permissions than modern Exchange security groups. Please see related documentation here.

Customers who have removed last on-premises Exchange Server from their organizations should also check for the presence of those groups and delete them to help prevent their possible abuse. Note that if you no longer have any Exchange servers on premises, you might want to perform a more comprehensive Active Directory cleanup as per this article.

Remove CVE-2026-42897 mitigations after installation

Installing the July 2026 update does not automatically remove already applied CVE-2026-42897 mitigations. Therefore, once you install July SU, you should:

If mitigation was applied using Exchange Emergency Mitigation (EM) Service:

Remove the mitigation M2.1.0 IIS rules.

If mitigation was applied using the downloadable EOMT script https://aka.ms/UnifiedEOMT:

Roll back the mitigation.

Exchange 2016 and 2019 updates are available only under the Period 2 ESU program

Exchange Server 2016 and 2019 are out of support. Only customers who enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive Exchange Server 2016 and 2019 security updates released between May and October 2026.

If you are not part of the Period 2 ESU program, migrate to Exchange Server Subscription Edition (SE) to keep receiving the latest security updates.

If you have already purchased the Period 2 ESU and need information on accessing the latest Security Updates, please contact us by sending an email to ExchangeandSfBServerESUInquiry@service.microsoft.com.

Known issues with this release

Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
Re-run the Health Checker after you install an update to see if any further actions are needed.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

When CVE-2026-42897 mitigation was released, there were several reported known issues. Are those addressed in this update?
Yes, when July 2026 SU is installed and mitigation is removed, mitigation known issues should be resolved too.

If we update some of our servers but cannot update others, can servers that will not receive update stay with CVE-2026-42897 mitigations? Is it OK to have some servers updated and some still using mitigations?
You can continue using mitigations on any servers that you cannot update to July 2026 SU (or newer). But note that known issues from mitigations will continue to apply to those servers. Additionally, after applying this update, Office Online Server (OOS) integration with Exchange Server might not function as expected until all Exchange servers in the organization have been updated.

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing an SU, you should re-run the Hybrid Configuration Wizard.

The last SU/HU we installed is a few months old. Do we need to install all SUs in order to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs or HUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install SUs on all Exchange Servers and all servers and workstations running the Exchange Management Tools to ensure compatibility between management tools clients and servers. If you are trying to update the Exchange Management Tools in the environment with no running Exchange servers, please see this.

Our organization does not have the Exchange 2016 and 2019 Period 2 ESU. How can we get current Exchange 2016 or 2019 updates?
Since Exchange 2016 and 2019 are now out of support, only customers who have enrolled into the Period 2 ESU program (which is valid between May and October 2026) can obtain Exchange 2016 or 2019 updates released after May 2026. For all other customers still running Exchange 2016 or 2019, we recommend that you upgrade your organization to Exchange SE as soon as possible.

Documentation may not be fully available at the time this post is published.

This post might receive future updates; they will be listed here (if available).

The Exchange Server Team

Unauthorized: You don't have permission to access this page or perform this action

BINODMAHARJAN — Tue, 14 Jul 2026 06:24:41 GMT

I frequently encounter an 'Unauthorized' error when attempting to manage Distribution Lists in the Exchange Admin Center, even while logged in with Global Administrator or Exchange Online Administrator privileges. Is this a known widespread issue, or is it specific to the configuration of these individual tenants?

Exchange Server to Exchange Online Migration: A Pre-Migration Readiness Checklist

Bharat-Bhushan — Sat, 11 Jul 2026 10:24:43 GMT

Over the years, I have worked on numerous Exchange Server to Exchange Online migration projects alongside Exchange administrators, IT teams, and MSPs. One consistent pattern I have noticed is that most migration issues do not originate during the migration itself — they surface because of gaps in pre-migration readiness. This checklist reflects what I have found most useful before starting any Exchange to Exchange Online migration.

Inventory and Assessment
Before touching any migration tooling, run a full inventory of your on-premises Exchange environment. This includes the Exchange Server version (2013, 2016, 2019), the number of mailboxes, database sizes, public folders, shared mailboxes, archive mailboxes, and any resource mailboxes such as rooms and equipment. Many teams also forget to document their distribution groups, dynamic distribution groups, and mail-enabled contacts. All of these need to be accounted for before you begin.

2. Active Directory and Entra ID Readiness

Check that your Active Directory is clean: no duplicate UPNs, no lingering objects, and no ambiguous legacy Exchange attributes. Verify that Microsoft Entra Connect (formerly AAD Connect) is installed, configured, and synchronizing without errors. Confirm the UPN suffix used in AD matches a verified domain in your Microsoft 365 tenant. Attribute mismatches between on-premises AD and Entra ID are one of the most common causes of post-migration issues with authentication and mail flow.

3. Mail Flow and DNS

Document all current MX records and any third-party mail filtering (SEG, anti-spam appliances). Plan whether you will cut over MX during the migration or keep a hybrid mail flow via Exchange connector. Verify SPF, DKIM, and DMARC records are in place for each domain. Applications and devices that use on-premises SMTP relay also need to be identified early — these often get missed and cause disruption after the migration window.

4. Licensing and Tenant Configuration

Confirm you have sufficient Exchange Online licenses assigned or ready to assign before the migration starts. Review your tenant for any conditional access policies that may block newly migrated users. Check the Microsoft 365 admin center for any service health issues that could affect the migration window. Also confirm your tenant's default accepted domains and any aliases that need to be added.

5. Coexistence and Hybrid Considerations

If you are running a hybrid migration (which is the recommended approach for most organisations with more than a few hundred mailboxes), confirm the Hybrid Configuration Wizard has been run and that the hybrid connector tests pass. Free/busy lookup, OAB distribution, and cross-premises message tracking should all be tested before you move any mailboxes. A common oversight is failing to validate OAuth configuration for modern authentication in hybrid — this affects calendar sharing and delegate access after migration.

6. Data and Backup

Before migrating any mailbox, verify that a recent backup of your Exchange databases exists and is recoverable. If you are running a DAG, confirm all database copies are healthy and no replay queues are building up. It is also worth checking the size and age of any archive mailboxes — large archives can significantly extend migration time and should be planned for separately.

What patterns have you seen in your environments? Are there specific pre-migration steps that have saved (or cost) you the most time? Happy to discuss further.

i need my existing exchange mail policies and everything properly configure

Alhootcenter — Sat, 11 Jul 2026 09:08:51 GMT

all configuration i need set properly have any cmd]

Cross-Tenant Message Recall in Exchange Online

The_Exchange_Team — Fri, 10 Jul 2026 15:38:58 GMT

Since we released cloud-based Message Recall in April 2023 (see Cloud-based Message Recall in Exchange Online), we’ve continued to expand where and how recall works – including support for Outlook on the web and mobile, recipient recall notifications, a maximum recallable message age, and support for external round-trip routing (see Exchange Online Message Recall Updates).

Until now, all these capabilities shared one boundary: Message Recall only worked within a single tenant. Today, we’re pleased to announce one of our most requested cross-organization enhancements:

Cross-Tenant Message Recall, controlled by a tenant admin allow list

The intra-tenant boundary

By design due to privacy concerns, Message Recall operates within the Exchange Online service boundary, and until now it has been limited to intra-tenant messages – those where the sender and the recipients belong to the same Microsoft 365 tenant. When a sender tried to recall a message they had sent to recipients in a different tenant, the recall would fail, even between organizations that work closely together and trust one another.

Customers told us this was a gap. Partners, subsidiaries, and affiliated organizations that collaborate daily across tenant boundaries wanted the same recall experience they already had inside their own tenant.

Introducing cross-tenant Message Recall

With Cross-Tenant Message Recall, a tenant admin can add other Microsoft 365 tenants to an allow list. Once a tenant is on the list, senders from those allow-listed tenants can recall messages they’ve sent to recipients in the receiving tenant – just as they would for an intra-tenant recall.

Control sits with the receiving tenant – the organization whose users received the messages. A cross-tenant recall is only honored when the receiving tenant’s admin has explicitly allow-listed the sender’s tenant. This keeps the receiving organization in full control of which external tenants are permitted to recall messages from its users’ mailboxes. The feature is disabled by default; no cross-tenant recall occurs until an admin adds at least one tenant to the allow list.

How it works

Consider two organizations that work together, Contoso and Fabrikam, both of whom are hosted in Microsoft 365:

A Contoso admin adds Fabrikam’s tenant to Contoso’s cross-tenant recall allow list.
A sender at Fabrikam recalls a message they previously sent to a recipient at Contoso.
Because Contoso has allow-listed Fabrikam, the recall is honored and processed like a standard recall against the Contoso recipient’s mailbox.

If Fabrikam is not on Contoso’s allow list, the recall fails and the Fabrikam sender will see in the recall status report that the message can’t be recalled across organizations. Allow-listing governs inbound recalls into the receiving tenant, so each organization decides independently which external tenants it trusts to recall messages from its mailboxes.

Configuring with Exchange Online PowerShell

Admins can configure these settings using Exchange Online PowerShell.

Enable or disable cross-tenant message recall for the tenant. Setting this parameter to $True turns on the capability; $False (default) turns it off:

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled [$true | $false]

Specify external tenants to add or remove from the allowed list. Add the tenant IDs of the organizations you trust to perform recalls:

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId 1>","<tenantId 2>"}; {Remove="<tenantId 1>","<tenantId 2>"}

What senders and recipients see

When a sender in an allow-listed tenant recalls a message, recipients in the receiving tenant experience the recall exactly as they would an intra-tenant recall. If the receiving tenant has enabled recipient recall notifications, those notifications apply to cross-tenant recalls as well. If the sender’s tenant is not on the receiving tenant’s allow list, the sender receives a notification that the message can’t be recalled across organizations.

Availability

Cross-Tenant Message Recall will start to deploy to worldwide, GCC, GCC High, DoD and Microsoft 365 operated by 21Vianet starting mid-August, completing by mid-September. We hope you’ll find this enhancement useful, and we look forward to your feedback.

Microsoft 365 Messaging Team