Exchange Team Blog articles

Released: September 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 08 Sep 2026 20:40:02 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 September 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).

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

Published calendar (.ics) returns HTTP 500 for calendar applications | Microsoft Support – to be resolved in a future update

Issues resolved in this release

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.
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

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.

We installed an Exchange SU or HU update and are running Windows Server 2025. How do we uninstall updates as they are not listed on Windows Server 2025?
We do not recommend uninstalling Security Updates. But see Can't view or uninstall Exchange security or hotfix updates in Control Panel on Windows Server 2025 | Microsoft Support.

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.

Updates to this blog post:

Sep 8, 2026: Corrected one of issues addressed to the free/busy time zone issue over Graph

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

The Exchange Server Team

Exchange Server AD FS Modern Authentication: Expanded Outlook client support

The_Exchange_Team — Tue, 08 Sep 2026 14:14:41 GMT

We are pleased to announce expanded Outlook client support for Exchange Server AD FS Modern Authentication.

In our previous update, we announced broad Outlook for Windows/Mac support and support for the native Mail app on iOS and macOS. We are now extending this support to Outlook for iOS and Outlook for Android.

Outlook for iOS and Outlook for Android can now use AD FS Modern Authentication to access mailboxes in supported pure on-premises Exchange Server deployments.

Deployment context: AD FS Modern Authentication is intended for pure on-premises Exchange organizations that don't use Microsoft Entra ID or an Exchange hybrid configuration. Exchange hybrid organizations should continue to use Hybrid Modern Authentication (HMA) with Microsoft Entra ID.

Supported clients at a glance

Client	Supported release or OS	Administrator action
Outlook for Windows	Supported Microsoft 365 Apps channels and supported perpetual releases; Windows 11 22H2 or later	Install the required Windows update, trust the AD FS service URLs, and enable Exchange on-premises Modern Auth in Outlook.
Outlook for Mac	Outlook for Mac in Microsoft 365, build 16.106 or later; macOS Sequoia or later	Use Exchange Server Subscription Edition with the December 2025 or later Security Update, and configure ADFSAuthorizedURLs.
Outlook for iOS	Latest supported Outlook and iOS versions	Follow the Exchange and AD FS configuration guidance.
Outlook for Android	Latest supported Outlook and Android versions	Follow the Exchange and AD FS configuration guidance.
Native Mail app for iOS and macOS	iOS 17.6.1 or later; macOS Sequoia or later	Configure the documented native client application and permissions in the AD FS Outlook application group.

Updated documentation

We have updated the deployment documentation to make the supported-client requirements easier to review:

A new summary brings all supported clients and operating-system requirements together.
Outlook for Windows build, Windows update, registry, and AD FS trusted-domain requirements are grouped under the Windows client.
Outlook for Mac requirements include the ADFSAuthorizedURLs Terminal configuration, a multiple-namespace example, and the equivalent Mobile Device Management settings.

Learn more

For complete prerequisites and configuration steps, see Enable Modern Auth in Exchange Server on-premises.

For background on the earlier client expansion, see Update on Exchange Server ADFS Modern Authentication support.

The Exchange Server Team

Take control of your EWSAllowedAppIDs list before EWS access changes

The_Exchange_Team — Fri, 04 Sep 2026 14:47:38 GMT

As we prepare for the final phase of Exchange Web Services retirement, we are refining how EWSAllowedAppIDs setting (which you can use to define your EWS AppID allow list) will be applied. Our goal is to protect customers from unexpected disruption while keeping control of the allow list with each tenant administrator.

We strongly recommend that every customer review EWS usage and configure EWSAllowedAppIDs themselves. If an administrator has already configured EWSAllowedAppIDs, Microsoft will not overwrite or change the list. The customer-managed list remains authoritative.

What happens during rollout

Beginning October 1, 2026, Microsoft will start enabling the updated behavior as outlined in previous blog post. With this logic change, if the customer has EWSEnabled set to True, EWS will require an Allowed AppID list. The timing will depend on when the change reaches that tenant's environment.

If organization has:

EWSEnabled = True - Microsoft will ensure that each tenant has an EWSAllowedAppIDs list. If the customer has not created a list, Microsoft will populate one to reduce the risk of an outage when the cloud environment logic changes (and AppID allow list becomes required when EWSEnabled = True). The list will be based on the previous 60 days of usage, and so it may miss applications that run infrequently, and it may include apps you no longer want to have access. This will happen shortly before the logic change takes place.
EWSEnabled = Null - Microsoft will only populate EWSAllowedAppIDs, if the customer has not already done so. This will happen a few days before changing EWSEnabled to False during the per-tenant rollout of that setting. This means that tenants that did not change EWSEnabled property from Null could have no AppID allow list defined until later in October.

Customers that still require EWS should act now: configure EWSAllowedAppIDs to include only the applications that must continue using EWS, then set EWSEnabled to True. Continue planning to move applications from EWS to Microsoft Graph before EWS is retired. By controlling your own EWSAllowedAppIDs values, you can ensure that only applications that you really want to have EWS access after October rollouts start can still use EWS.

The Exchange Team

Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline

The_Exchange_Team — Wed, 02 Sep 2026 15:34:48 GMT

Several years ago, we announced Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online. Since then, we have been periodically updating the “oldest acceptable version” as we keep releasing more security updates for Exchange Server.

So far, these changes have been implemented silently. But, today, we are announcing that starting in the second week of September 2026, we will raise the oldest allowed version for Exchange 2016 or Exchange 2019 servers that connect to Exchange Online over an inbound connector type of OnPremises to at least the last available public update version, released in October 2025. This update level was released almost a year ago, and all organizations should have updated to it, since.

A very important implication of this change:

After going into effect, the oldest Exchange Server version allowed to send email to Exchange Online over the inbound OnPremises connector will be Exchange with October 2025 updates.
The next time we update the oldest allowed Exchange Server version for sending email to Exchange Online, the required version of Exchange Server 2016 or Exchange Server 2019 will be newer than any publicly available update.

When the next adjustment happens (we estimate in several months), only customers who were enrolled into our ESU program and customers who migrated to Exchange SE will have the required update versions to not be throttled or blocked when sending email to Exchange Online.

As a reminder, throttling and blocking of email from persistently vulnerable Exchange servers to Exchange Online:

Applies to servers that connect to Exchange Online over an inbound connector type of OnPremises.
DOES NOT apply to servers that send email to Exchange Online in other ways (different types of connectors etc.)
DOES NOT (currently) apply to “all servers in your organization”, but only to servers that connect to Exchange Online over an inbound connector type of OnPremises. This might change in the future.

Finally, we wanted to be clear that the fact that the “oldest version to avoid throttling and blocking in Exchange Online” is always older than the latest version available does not mean that we consider versions older than the latest security update “safe to use”. Anything older than the latest is vulnerable to everything we have fixed/released/announced since that older version. Especially in this calendar year, we have been releasing many security updates for Exchange Server and it is likely that we will continue to do so for the foreseeable future.

With a rapidly changing security landscape, no organization should consider it safe to run their organization's business email on an outdated version of Exchange Server. Please see Exchange Server update FAQ.

Additional reading: How to pause throttling and blocking of out-of-date on-premises Exchange Servers.

The Exchange Server Team

Tell us how you use ObjectGuid, SamAccountName, and DistinguishedName in Exchange Online

The_Exchange_Team — Wed, 02 Sep 2026 17:31:16 GMT

As Exchange Online continues its multi-year directory modernization, we are evaluating the future of several long-standing identifier properties: ObjectGuid (most would recognize this property as Guid), SamAccountName, and DistinguishedName.

Today, multiple properties can identify the same object in Exchange Online. While this has provided flexibility and compatibility, some of these identifiers reflect design decisions from an earlier era and can add complexity for customers building and maintaining automation, integrations, and administrative workflows.

As part of our modernization efforts, we are exploring whether a smaller and more consistent set of identifiers could better support the future of the service. No decisions have been made. Before determining a path forward, we want to better understand how these properties are used today, what the impact of potential changes could be, and what alternatives, notice periods, and migration assistance customers would need.

We are particularly interested in hearing from customers, partners, and solution providers who use these properties in scripts, automation, reporting, applications, provisioning systems, or operational processes.

The potential changes discussed in this survey apply only to the Exchange Online directory and do not represent changes to on-premises Active Directory or Exchange Server.

Please take a few minutes to complete our survey. Your feedback will help inform our evaluation and any future decisions in this area.

Take the Survey: Exchange Online Directory: Identifier Properties Survey – Fill out form

Thank you!
The Exchange Team

Help us shape Exchange Server on-premises to different online org Free/Busy after EWS retirement

The_Exchange_Team — Mon, 24 Aug 2026 16:57:31 GMT

As shared in Exchange Online EWS, Your Time is Almost Up, Exchange Web Services in Exchange Online will begin phased disablement in October 2026 and will be fully disabled in April 2027. As part of this work, we are addressing the remaining Exchange Server collaboration scenarios that currently depend on the Exchange Online EWS endpoint.

Most Exchange Server Free/Busy scenarios will not change. Free/Busy between two Exchange Server (purely on-premises) organizations will continue using Federation/DAuth and Organization Relationships. Exchange hybrid organization can continue sharing Free/Busy between Exchange Server and its own Exchange Online tenant using OAuth and IntraOrganizationConnectors through the dedicated Exchange hybrid app, with Graph replacing EWS in the modern hybrid flow.

The scenario requiring a new path is an Exchange Server organization retrieving Free/Busy or MailTips from another organization's Exchange Online tenant through an EWS-dependent Organization Relationship. For Exchange Server to external Exchange Online scenario, we are evaluating leveraging Microsoft 365 Cross-Tenant Access Policy which is also becoming the standard for Free/Busy, calendar, and MailTips collaboration between Microsoft 365 tenants.

Before finalizing the direction, we want feedback from customers and partners - particularly organizations that operate Exchange Server without an existing M365 tenant.

Please share your feedback on this approach through the form: Survey

This feedback request is specifically about Exchange Server (Organization A) to a different Exchange Online (Organization B) collaboration. Exchange Server-to-Exchange Server Organization Relationships (two purely on-premises organizations) are not in scope and will continue unchanged.

The Exchange Team

Notes from the field: testing EWSAllowedAppIDs safely

The_Exchange_Team — Thu, 20 Aug 2026 14:21:26 GMT

As customers prepare for the final phase of Exchange Web Services (EWS) retirement in Exchange Online, many are asking the same practical question: how can I prove that EWSAllowedAppIDs is working before I depend on it? This field guide walks through a controlled positive-and-negative test, explains what the result means, and highlights an important naming trap that we are already seeing in customer conversations.

A note from the field

The most common confusion is not about the PowerShell syntax. It is about two similarly named controls that operate at different layers. EWSAllowedAppIDs is the new application-ID control for EWS. The older EWSAllowList and EWSBlockList settings are user-agent controls associated with EwsApplicationAccessPolicy, and they can affect both EWS and REST traffic.

Understand the two controls before testing

EWSAllowedAppIDs is a tenant-level list of application (client) IDs. When EWS is enabled and the list contains one or more Application IDs, only the listed applications are permitted to access EWS. This is the control to validate when you are testing an application's EWS access during the retirement transition.

EWSAllowList and EWSBlockList are older, user-agent-based controls. Despite their names, the underlying access policy is not limited to EWS; it can also affect REST requests. Customers that already use these settings may still need them for REST access control after EWS retirement.

The controls are evaluated independently. In practical terms, an EWS request must pass the application-ID control and then any applicable user-agent control. A successful App-ID test therefore does not prove that a separate user-agent policy is configured correctly.

What the test proves

A valid before-and-after test demonstrates the EWSAllowedAppIDs behavior only when all of the following are true:

The application can obtain an OAuth token.
The application has EWS application permission and tenant-wide admin consent.
EWSEnabled is set to True for the test.
The test mailbox contains at least one item in the Inbox.
The App ID is present for the positive test and absent for the negative test.
At least 24 hours has elapsed after each allow-list change.

Before you start

Perform this procedure in a test tenant if you can. Removing an application from the list can stop a production workload from accessing EWS after the configuration change has propagated.

Prepare the following:

A test mailbox with at least one Inbox item.
An app registration in the same tenant as the mailbox.
EWS application permission with tenant-wide admin consent.
A client secret or certificate for application authentication. Treat a client secret as a password and do not place it in a shared script or source-control repository.
Exchange Online PowerShell access and permission to run Get-OrganizationConfig and Set-OrganizationConfig.
Download the Test-EWSAppAccess.ps1 script. This is a test script that you can use unless you want to test with a real app. Script documentation can be found at Testing EWS App Access.

Record the tenant ID, application (client) ID, test mailbox SMTP address, and the selected authentication material before starting.

Test 1: Confirm access while the app is allowed

Connect to Exchange Online PowerShell.

Connect-ExchangeOnline

Inspect the current EWS state and capture the complete existing App-ID list.

Get-OrganizationConfig | Format-List EWSEnabled Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

For a controlled test, set EWSEnabled to $null (all EWS allowed, AppID Allow List ignored).

Set-OrganizationConfig -EWSEnabled $null

Add the test App ID without overwriting any existing entries. The EwsAllowedAppIDs command writes the complete list, so preserve the current value.

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs $updated = @($current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ }; $appId) | Select-Object -Unique Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Verify that the App ID was written.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Wait for the change to propagate. Because of the Exchange Online configuration caching, this can take up to 24 hours.
Set EWSEnabled to True

Set-OrganizationConfig -EWSEnabled $true

Wait for 1 hour, for the change to become effective.
Download Test-EWSAppAccess.ps1 and run Test-EWSAppAccess.ps1 with application authentication. The Mailbox parameter is required when using application permissions.

.\Test-EWSAppAccess.ps1 -AppId $appId -TenantId $tenantId -Mailbox $mailbox -SecretKey $secretKey

A successful test should report that the application accessed the mailbox.

Application <appid> successfully accessed mailbox <mailbox></mailbox></appid>

Confirm that $LASTEXITCODE is 0 and save the output with your change record.

Test 2: Remove the app and confirm access is blocked

Remove only the test App ID, preserving every other entry.

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs $updated = $current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ -and $_ -ne $appId } Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Confirm that the App ID is no longer present.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Wait at least 24 hours before retesting. An immediate success can simply mean that an Exchange Online server still has the previous configuration cached.
Run the same Test-EWSAppAccess.ps1 command again.
After propagation, the expected result is a failure.

Application <appid> failed to access mailbox <mailbox></mailbox></appid>

Confirm that the process returns exit code 1. If the first test failed too, troubleshoot authentication, permissions, consent, mailbox access, and script dependencies before concluding that the allow list caused the failure.

Restore the test App ID to the full list, verify the configuration, wait for propagation, and repeat the successful-access test.

Do not leave a production tenant with an unintentionally empty or incomplete App ID allow list.

The fastest way to re-enable EWS after App ID blocking

Let’s say you are testing this process in a tenant and after setting both EWSEnabled = True and populating EWSAllowedAppIDs you do not see results that you expected and need the quickest way to undo your changes and re-enable the use of EWS in your tenant.

Changes to EWSAllowedAppIDs take ~24 hours to fully apply to your tenant.
Changes to EWSEnabled take about 1 hour.
EWSAllowedAppIDs (Allow List) is ignored if EWSEnabled is set to Null.

Therefore, the quickest way to re-enable EWS in an unrestricted way is to set EWSEnabled back to Null. One hour later, EWS will be unrestricted:

Set-OrganizationConfig -EWSEnabled $null

EWSEditor is another option

EWSEditor is also available for administrators and developers who prefer an interactive EWS API explorer. It can be useful for making a real EWS call against a test mailbox while using the same application identity you are validating.

You still need a correctly configured OAuth application, EWS permissions and consent, a controlled test mailbox, a recorded baseline, and enough time for EWSAllowedAppIDs changes to propagate.

Common pitfalls to avoid

Running the negative test immediately after removing the App ID.
Replacing the entire list instead of preserving existing App IDs.
Testing with an empty Inbox when the test script reads the first Inbox item.
Treating an OAuth, permission, consent, or credential failure as proof that EWSAllowedAppIDs blocked the request.
Confusing the user-agent-based EWSAllowList or EWSBlockList with the new App-ID-based EWSAllowedAppIDs control.
Adding an App ID for a workload that uses REST but does not call EWS.

Customer guidance in one paragraph

If an application calls EWS and requires temporary access during the retirement transition, validate its application ID with EWSAllowedAppIDs in a test tenant. If a tenant already uses EwsApplicationAccessPolicy, assess its EWSAllowList or EWSBlockList separately because those user-agent settings can also affect REST. The similar names do not make the controls interchangeable.

The simple rule: use EWSAllowedAppIDs for the new EWS application-ID gate; use EWSAllowList or EWSBlockList only for the older user-agent policy. Test each layer independently.

This distinction matters because we are already seeing customers assume that any setting beginning with “EWS” is part of the EWS retirement exception process. It is not. Making that mistake can create unnecessary configuration changes or interrupt REST workloads that were never using EWS.

Sources and further reading

Testing EWS App Access, PowerShell-EWS-Scripts Wiki: https://github.com/David-Barrett-MS/PowerShell-EWS-Scripts/wiki/Testing-EWS-App-Access
EWSEditor project: https://github.com/dseph/EwsEditor

David Barrett
(All-round good guy and Exchange development expert)

Understanding the new 100 GB mailbox entitlement for Microsoft 365 Business suites

The_Exchange_Team — Wed, 19 Aug 2026 20:25:03 GMT

Microsoft 365 Business Basic, Business Standard, and Business Premium now include an additional 50 GB of primary email storage for eligible users. This brings the supported primary mailbox entitlement from 50 GB to a maximum of 100 GB. We wanted to talk about this change, so Exchange Online administrators understand how this mailbox size increase is delivered. We will focus only on mailbox size in this post.

What changed for the Business suites

Microsoft announced an additional 50 GB of email storage for Microsoft 365 Business Basic, Business Standard, and Business Premium as part of the 2026 Microsoft 365 packaging updates. The packaging changes are rolling out June - September 2026, with customers receiving advance notice through Message Center before the changes became available in their tenant.

The additional storage changes the effective primary mailbox size for eligible Business suite users from 50 GB to 100 GB. The affected commercial product suites are:

Microsoft 365 Business Basic
Microsoft 365 Business Standard
Microsoft 365 Business Premium

After the rollout, all users that had the appropriate licenses assigned will have received a new service plan and the corresponding mailbox quota increase.

Please note: this mailbox size increase applies only to the above-mentioned suite licenses; there can still be licenses (such as standalone Exchange Online Plan 1) that have the maximum mailbox size set at 50 GB.

The supported quota outcome

The additional storage establishes a maximum effective quota of 100 GB for the eligible Business suite scenario.

A user whose highest applicable Exchange mailbox plan is the Business suite plan receives an effective 100 GB quota when the storage add-on is present.
A user who also has an Enterprise or standalone Exchange license that already provides a 100 GB mailbox remains entitled to 100 GB.
A user who has multiple licenses assigned, which contain multiple Exchange service plans (this is known as Concurrent Licensing), will be granted the maximum quota provided by a single product – the quotas are not additive across products. For example, a user with one of the Business Suite and a separate Enterprise license containing Exchange Online Plan 2, will still be entitled to 100 GB. The quota increase for the Business suites affects the base mailbox size only. It does not provide archive capabilities.

How the additional quota is implemented

The Business suite provides the total storage through a combination of service plans:

The Business suite Exchange plan is represented by BPOS_S_STANDARD, which grants 50 GB of storage.
The additional entitlement is represented by the EXCHANGE_STORAGE_50GB service plan, which adds +50 GB, increasing the total quota to 100 GB.

Both plans must be enabled for the user to have the full 100 GB.

In your Microsoft 365 admin center, this will look like the following – there is a “standard” license and there is an add-on:

Custom mailbox quotas are preserved

If an administrator has configured a custom mailbox quota, the additional storage logic does not overwrite that setting. Likewise, removing the add-on does not replace a later administrator-defined custom value. This protects deliberate tenant-level mailbox management choices.

For example, if an administrator configured the mailbox for user with a Business suite from the original default of 50 GB down to 20 GB, the user’s quota will remain at 20 GB even after the additional service plan is assigned to them.

Reviewing the user’s licenses and service plans

In the Microsoft 365 admin center, open Users > Active users, select the user, and review Licenses and apps. Confirm that the user has an eligible Microsoft 365 Business suite and that its included services are enabled. The Billing > Licenses page can also show whether the product was assigned directly or through group-based licensing.

Microsoft Graph PowerShell can provide a more detailed service-plan view. The following example retrieves the assigned license details and searches for the storage service plan:

$licenses = Get-MgUserLicenseDetail -UserId user@contoso.com $licenses.ServicePlans | Where-Object ServicePlanName -eq "EXCHANGE_STORAGE_50GB" | Select-Object ServicePlanName, ProvisioningStatus

Review the effective Exchange mailbox quota

Exchange Online PowerShell shows the quota values that Exchange presents for the mailbox. For example:

Get-Mailbox -Identity user@contoso.com | Format-List IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults

For an eligible Business suite user with the additional storage service plan and no custom quota, the effective maximum mailbox quota should be 100 GB.

Common license and quota scenarios

Business suite with the +50 GB storage add-on: user’s effective primary mailbox maximum is 100 GB.
Business suite without the +50 GB storage add-on: base Business mailbox quota continues to apply until the additional service plan is provisioned (should happen automatically).
Business suite plus an Enterprise or standalone plan that already grants 100 GB: effective maximum remains 100 GB because Exchange uses the highest applicable entitlement rather than adding the quotas.
Business suite plus a lower Exchange capability (for example, F3 license): Business plan remains the highest capability, so the add-on can raise the effective maximum to 100 GB.
Custom quota: administrator-defined values remain in effect and are not replaced by the automatic +50 GB boost.
+50 GB add-on explicitly removed: for a mailbox using default plan quotas, Exchange returns to the applicable plan default. A custom value set by an administrator remains custom.

Rollout and license propagation

The additional storage is represented through licensing data, so the service plan must be assigned and processed before Exchange can return the higher effective quota. During broad service-plan rollout or backfill operations, users in the same organization may not all reflect the change at the same time. It is possible that some of your users received additional 50 GB mailbox size increase while others did not – you should expect that this gets resolved automatically if users are licensed by one of affected business suite licenses.

Administrators should not remove and reassign an Exchange license solely to force a quota refresh unless Microsoft Support specifically directs that action. Removing a product license removes access to its services and starts the applicable data-retention lifecycle. Please keep using your normal license-assignment processes.

Exchange Online Team

Where is Exchange SE CU1 anyway?

The_Exchange_Team — Thu, 13 Aug 2026 21:05:31 GMT

We are getting questions from our customers on when they can expect us to release Exchange SE Cumulative Update 1 (CU1). After all, in the past we mentioned that it would be released by the end of the first half of calendar year 2026, later updated to “second half of 2026”. What is the deal? Where is CU1?

Over the last few months, various Microsoft execs made statements explaining how Microsoft is leveraging a variety of AI tools to help find vulnerabilities in our products (examples of such announcements can be found here, here and here).

It should come as no surprise that this is a Microsoft-wide initiative. Many teams, Exchange Server included, are working through reported issues – which includes validation that they are real security issues, reproducing, fixing, testing for regressions / issues after fixes are deployed and releasing updates monthly.

We have been releasing security updates for Exchange Server regularly: May, June, July, August. You can expect this increased pace of security releases to continue. We are prioritizing security above all else.

While all of that is happening, we are also working on CU1; we are regularly rolling our monthly security payload into our internal CU1 build and plan to release Exchange SE CU1 as soon as we get a reasonable stable point and have a month without pressing security payload. We really do not want to try to release a new CU1 and then immediately supersede the new CU with security updates as that would create double the update work for many organization administrators. Even internally, trying to ensure that two major releases (Security Update and a CU) get appropriately tested so we can ensure high quality and nothing falls through the cracks would be very challenging as CU1 must be all inclusive of everything that we released since the RTM.

In short: Exchange SE CU1 is coming; we do not have a date to give you. But we did not forget about it.

Until then, please keep Upgrading your organization to Exchange Server SE | Microsoft Community Hub and if you are already on Exchange Server SE, stay up to date!

The Exchange Server Team

Released: August 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 08 Sep 2026 20:41:07 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 August 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

OWA Light is disabled starting with this update

As we announced several weeks ago, this update (and any subsequent updates) permanently disables the OWA Light client when update is installed on an Exchange server. See related CVE-2026-62914 for more information.

Customers who are not able to install August 2026 (or later) update should disable OWA Light on their servers to address this particular CVE.

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

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.

Known issues with this release

Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support – to be addressed in an upcoming update.
If a backend mailbox server is updated to August 2026 SU, but the frontend server proxying the inbound MRS connection is on an older version, MRS migration might fail with TooManyTransientFailureRetriesPermanentException error. This can manifest on any MRS request, including Test-MigrationServerAvailability. Updating the front end server to the August 2026 SU should resolve this problem.
Published calendar (.ics) returns HTTP 500 for calendar applications | Microsoft Support
Hybrid Free/Busy over MS Graph drops the requester timezone | 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

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

Major updates to this post:

Sep 8, 2026: mentioned the correct known issue for August (Graph time zone issue)
Aug 28, 2026: Linked to the KB article talking about the anonymous calendar publishing known issue.
Aug 25, 2026: Added a known issue with anonymous calendar publishing failing to update after SU is installed, with a workaround.
Aug 24, 2026: Added a known issue that can happen with MRS migrations if not all servers are updated to August 2026 updat yet.

The Exchange Server Team

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

The_Exchange_Team — Fri, 04 Sep 2026 14:47:12 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-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.

Sharing Free/Busy with another organization hosted in Microsoft 365 via Availability Address Space (with AccessMethod OrgWideFBToken) does not depend on Exchange Web Services and is not impacted by EWS deprecation. However, you may still wish to migrate these configurations to Microsoft 365 Cross-Tenant Access Policy, which supports additional security features and more granular configuration options. Run this command to check your Availability Address Space configurations:

Get-AvailabilityAddressSpace | Format-List ForestName, AccessMethod

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 15, 2026
GCC	Early September 2026	September 30, 2026
GCC High	Early September 2026	September 30, 2026
DoD	Early September 2026	October 30, 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.

Our default Sharing Policy is defined (with a "{*:0}" wildcard domain) but is set to Enabled:False. This is because we want to prevent users from external calendar sharing. Do we need to migrate this policy?
No action is needed. No Cross-Tenant Access Policy will have an equivalent effect to default Sharing Policy being disabled.

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?
Availability Address Space (with AccessMethod OrgWideFBToken) does not depend on Exchange Web Services and is not impacted by EWS deprecation. However, you may still wish to migrate these configurations to Microsoft 365 Cross-Tenant Access Policy, which supports additional security features and more granular configuration options.

Major updates to this blog post:

9/3/2026: Removed a redundant section of the article.
8/28/2026: Various updates to the post; timeline changes, several clarifications made.
8/18/2026: Modified the FAQ related to AAS sharing with the 21Vianet cloud.
8/10/2026: Added a FAQ that clarifies that default sharing policy that is set to be disabled does not need migration.

The Exchange Online EWS Deprecation Team

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

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

The_Exchange_Team — Fri, 14 Aug 2026 18:21:08 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

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.

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

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.

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.

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

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

Upcoming retirement of OWA Light in Exchange Server

The_Exchange_Team — Thu, 13 Aug 2026 15:52:59 GMT

Update 8/13/2026: This retirement is now complete, please see Released: August 2026 Exchange Server Security Updates | Microsoft Community Hub. For customers who do not have access to August 2026 Exchange security updates, we recommend that you disable OWA Light as per instructions below.

We are announcing our plan to retire and disable the OWA Light experience in Exchange Server in a future update. OWA Light was created for a much earlier era of the web, when browser support, bandwidth, and accessibility technologies were very different from today. Going forward, we want to invest in modern Outlook on the web experience that provides the cross-browser, accessible, and security-focused experience.

Organizations that still rely on OWA Light must move users to the standard Outlook on the web experience and review any internal guidance, bookmarks, training material, helpdesk scripts, or accessibility workflows that reference OWA Light.

This is how OWA Light looks like:

What is changing

In an upcoming Exchange Server update (estimated in August 2026), we plan to disable and remove the OWA Light experience. After that change is introduced, users will no longer be able to choose or be redirected to OWA Light and should use the modern Outlook on the web experience instead.

This announcement applies to Exchange Server (on-premises). We announced deprecation of OWA Light in August 2024.

Why we are making this change

OWA Light served customers well for many years. It was designed for older browsers, slower connections, and scenarios where a simplified web interface helped users access mail in environments that could not support the full Outlook Web App experience.

The web has changed significantly since OWA Light was introduced. Modern browsers are more capable and more consistent, network conditions have improved for many customers, and security landscape has changed significantly. Maintaining a separate legacy OWA Light experience increases complexity. Each additional content rendering path, control surface, and compatibility layer must be evaluated as we strengthen defenses against modern web threats.

We recommend that Exchange Server administrators use this time to identify and prepare any users, processes, or documentation that still depend on OWA Light.

To block OWA Light right away, you can create or update an existing OWA mailbox policy:

Set-OwaMailboxPolicy -OwaLightEnabled $false

Make sure that the OwaMailboxPolicy is assigned to all mailboxes. You can assign a OwaMailboxPolicy by using the Set-CasMailbox -OwaMailboxPolicy cmdlet.

Additionally, disable the OWA Light selection menu on the OWA logon page. You can do that by running:

Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $false

More information can be found in the Set-OwaMailboxPolicy and Set-OwaVirtualDirectory documentation.

Summary

OWA Light was an important compatibility experience when the web needed it. Today, the full Outlook on the web experience is the right place for us to focus. Retiring OWA Light will help reduce legacy surface area, simplify ongoing engineering work, and allow us to continue improving the experience customers use every day.

The Exchange Server team

Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement

The_Exchange_Team — Fri, 04 Sep 2026 17:18:33 GMT

Exchange Web Services (EWS) retirement in Exchange Online is entering its final phase. Over the last several years, Microsoft has worked with product teams, independent software vendors (ISVs), and customers across the ecosystem to migrate workloads to Microsoft Graph and other modern APIs. Many of those migrations are complete, and many others are well underway.

As phased EWS disablement in Exchange Online approaches in October 2026, we are introducing a new capability to help administrators prepare in a controlled and predictable way: EWSAllowedAppIDs. This is the AppID Allow List functionality that we mentioned in Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub.

EWSAllowedAppIDs gives administrators a practical way to identify remaining dependencies, limit EWS access to approved applications, and reduce the risk of disruption as retirement enforcement begins.

This feature is starting to roll out now. All tenants should be able to view the parameter when running Get-OrganizationConfig, but they won’t be able to set the list until the roll out reaches the tenant.

What is EWSAllowedAppIDs?

EWSAllowedAppIDs is a tenant-level AppID allow list that lets Exchange Online administrators explicitly define which applications are still permitted to access EWS, based on their App ID.

When configured, only applications whose App IDs appear in the AppID allow list can continue using EWS in the tenant when EWSEnabled at the tenant level is set to True.

This feature is designed to support the final transition away from broad, unrestricted EWS access and toward tightly scoped, intentional usage during the retirement window.

Note: The EWSAllowList feature Exchange has had for many years is based on User Agent, not App ID (and it applies to REST/Graph not just EWS by the way). Both can work together, but they operate on different aspects of the calling application.

Administrators can use the feature to:

Identify which applications still require EWS
Restrict EWS access to only approved applications
Prepare for the final retirement of EWS in Exchange Online

How EWSAllowedAppIDs fits into the EWS endgame

We previously announced that phased EWS disablement in Exchange Online will begin in October 2026.

To understand why EWSAllowedAppIDs matters, it helps to look at how Exchange Online behavior changes before and after that date. The retirement model uses the existing EWSEnabled organization-level setting together with the new EWSAllowedAppIDs allow list. (Refresh yourself on how the EWSEnabled switch works and how to set it here)

Before October 2026, the behavior is intentionally permissive to give customers time to inventory dependencies, deploy an AppID allow list, and validate which applications still require EWS.

Before October 2026

EWSEnabled Value	AppID Allow List State	Behavior
Null (default)	Ignored	All EWS traffic allowed
True	Empty or Null	All EWS traffic allowed
True	Populated	Only listed applications allowed
False	Any	All EWS traffic blocked

This pre-October phase gives administrators room to deploy and test an AppID allow list without immediately breaking existing applications.

What changes in October 2026

Beginning in October 2026, Exchange Online starts transitioning tenants into retirement enforcement behavior.

At that point, enabling EWS without configuring an AppID allow list will no longer act as an unrestricted “allow everything” mode.

Starting October 2026

EWSEnabled Value	AppID Allow List State	Behavior
Null	Ignored	All EWS allowed (but tenant will have EWSEnabled set to False at some point as part of phased rollout by Microsoft)
True	Empty or Null	All EWS traffic blocked (Org Relationships as announced in MC1447678 will work. Please see Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy \| Microsoft Community Hub for more information)
True	Populated	Only listed applications allowed (Org Relationships as announced in MC1447678 will also work)
False	Any	All EWS traffic blocked

This is the most important behavioral change administrators need to understand: after enforcement begins, setting EWSEnabled=True without an AppID allow list effectively becomes a block-all configuration.

This change is intentional. The goal is not to keep EWS available indefinitely, but to require explicit acknowledgement that EWS is still needed and to scope that usage down to known, approved applications.

The goal of the retirement process is not simply to keep EWS “on” indefinitely, but to:

Force explicit acknowledgement that EWS is still required
Scope usage down to known, approved applications
Accelerate migration to Microsoft Graph and modern APIs

What happens if a tenant admin does nothing?

Today, many tenants still have EWSEnabled unset (Null), which behaves as unrestricted access.

As the phased retirement rollout starts in October 2026, those tenants will have EWS disabled (EWSEnabled set to False) as part of the staged shutdown process.

Administrators who still require EWS at that point will need to take explicit action.

The recommended path is:

Configure or validate the EWSAllowedAppIDs allow list (remember, we said we would populate this for tenants who have not done so – read more here – but the admin owns ensuring it’s correct).
Set EWSEnabled=True

Customers who complete this work proactively will be significantly less likely to experience disruption during the broader retirement rollout.

Why we strongly recommend enabling this feature now

Customers should not think of EWSAllowedAppIDs as a feature intended only for October 2026. Its greatest value is in the preparation period before enforcement begins.

Deploying and validating the AppID allow list now gives administrators time to find unknown dependencies, remove obsolete applications, engage vendors that still rely on EWS, and begin migrations to Microsoft Graph.

Discover unknown EWS dependencies
Remove obsolete applications
Contact vendors still requiring EWS
Begin migrations to Graph APIs
Validate which applications truly still require exceptions
Reduce future support escalations and outages

Administrators who wait until they are already impacted by phased disablement will have a much smaller remediation window and a significantly higher likelihood of disruption.

Recommended next steps for administrators

We strongly recommend that Exchange Online administrators begin this work now:

Inventory EWS usage

Identify all applications and services currently using EWS in your organization. Use EWS usage reports where available in your tenant, and review Message Center posts that summarize tenant usage. Please see Notes From the Field: Finding and Remediating EWS App Usage Before Retirement | Microsoft Community Hub.

Build an AppID allow list

Create an EWSAllowedAppIDs allow list containing only applications that are known to still require EWS. This includes Microsoft first-party client apps such as Office, Power Query for Excel etc. If the app shows up in your usage report, and you want to keep using it, you need to add it to the list.

If an administrator already knows which applications they want to permit, they can create a new AppID allow list directly by specifying one or more App IDs.

For example:

Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

This replaces the current value with the specified set of allowed applications.

After setting the value, administrators can confirm the configured list using:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The use of “RetrieveEwsOperationAccessPolicy” is required for performance reasons – we only want to retrieve this list if the admin explicitly asks for it.

Changes to this list can take up to 24 hours to take effect. Again, for performance reasons, servers only refresh their in-memory cache once every 24 hours.

Administrators should be aware that setting the property writes the full list value. If the property already contains App IDs, they will be replaced unless included in the new command. See more below on this.

Test thoroughly

Validate that all applications on your AppID allow list continue to work as expected, and check for any missed dependencies. If you need to add or remove an App ID, you must read the current list, compute the updated list, and then write the full value back. Today, this cmdlet does not support incremental add or remove operations.

Here are two examples that show how to update the list:

Example: add a new App ID

The common pattern is to read the current list, append the new App ID, and then write the full combined list back.

# Read the current allow list $current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs) # Define the new App ID to add $newAppId = "99999999-8888-7777-6666-555555555555" # Combine existing and new values $updated = @($current, $newAppId) # Write the updated allow list back Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Example: remove an App ID

Because there is no single-item removal operation today, removal also requires recomputing the full list.

# Read the current allow list $current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs) # Define the App ID to remove $removeAppId = "99999999-8888-7777-6666-555555555555" # Split the comma-separated list into individual App IDs $appIds = $current -split "," # Remove the specified App ID $updated = $appIds | Where-Object { $_ -ne $removeAppId } # Write the updated allow list back Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

The bigger picture

EWS served the Exchange ecosystem for nearly two decades.

However, modern requirements for security, reliability, compliance, and scale call for a more modern API platform. Microsoft Graph is the long-term strategic platform for most Exchange Online integration scenarios.

EWSAllowedAppIDs is designed to make the final transition manageable and predictable while still encouraging rapid migration off EWS.

Organizations that prepare early will navigate this transition most smoothly. Administrators who inventory dependencies now and validate their AppID allow lists well before October 2026 will be far better positioned to avoid disruption as phased retirement begins.

The time to prepare is now.

For the latest on the overall plan, status on parity gaps and links to resources, please check the Deprecation of Exchange Web Services in Exchange Online page.

AppID Allow List FAQs

Can we set EWSEnabled=True in August without creating our own AppID Allow List?
Yes, but we’d rather your tenant admin creates it, to ensure it’s exactly meeting your needs. We will be populating AppID Allow Lists for our customers automatically (based on each tenant’s usage). If you only set EWSEnabled=True in August and we will populate your AppID Allow List for you, we might also include apps in there you weren’t aware of (if they show usage). We recommend that admins create their own AppID Allow Lists to control exactly which EWS applications they want to allow after October 2026. See Take control of your EWSAllowedAppIDs list before EWS access changes | Microsoft Community Hub for more information.

If we create our own AppID Allow List, will Microsoft change it during automatic AppID Allow List processing for all tenants?
No. If you create your own AppID Allow List, our automated process will not change your already created AppID Allow Lists. Your AppID Allow List will stay unchanged.

If Microsoft auto-populates the list in for a tenant, can an administrator manually overwrite or append to that list via PowerShell afterward?
Yes, Administrators will be able to change the content of AppID Allow List.

What about the EWSAllowList setting? Should we add application IDs there?
EWSAllowList and EWSBlockList settings are related to the EwsApplicationAccessPolicy feature that has existed for long time. This is not related to EWS deprecation in Exchange Online. EwsApplicationAccessPolicy is an older EWS application access control feature and requires USER AGENTS instead of AppIDs. Modifying EwsApplicationAccessPolicy simply adds additional "gate" a client application needs to pass to connect to Exchange Online, and application can pass it only after it has passed the AppID Allow List mentioned above. So, if you start to use this with EWSAllowedAppIDs, both the App ID and the correct User Agent for the request must both pass their individual logic, otherwise the request will be denied due to EWS being blocked.

Updates to this blog post:

9/4/2026: Modified the FAQ and text to reflect the timing that we have published about when Microsoft will create the AppID allow list for tenants who have not done so yet. See Take control of your EWSAllowedAppIDs list before EWS access changes | Microsoft Community Hub.
9/1/2026: Added FAQs related to AppID Allow List / EWSAllowedAppIDs property
9/1/2026: Clarified all mentions of "Allow list" to be "AppID Allow List" (the allow list that takes Application IDs, as opposed to user agent strings used by EwsApplicationAccessPolicy and it's EWSAllowList setting).
8/14/2026: Updated the Allow List table to specify what happens when EWSEnabled = True and Allow List is populated.
8/7/2026: Added a link to Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy | Microsoft Community Hub related to Org Relationship announcement in MC1447678
8/6/2026: Added a mention of Organization Relationships and that that EWS traffic is not related to or blocked by the state of Allow List (related to MC1447678)

The Exchange Team

Released: June 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 14 Jul 2026 17:23:34 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 June 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes as well as CVE-2026-42897 that we announced: Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub.

Update to ensure continued function of Exchange Emergency Mitigation (EM) and Feature Flighting services

Due to service-side change, the Exchange Emergency Mitigation (EM) and Exchange Flighting services will be unable to use configuration files released in July 2026 or later, unless Exchange is updated to June 2026 update (or newer). Any mitigations already downloaded and applied will keep working, but servers will not be able to use any new mitigations starting in July 2026 unless updates are installed. Please see Exchange mitigation and flighting services fail due to "Unknown Issuer" error for more details.

CVE-2026-42897 mitigations after installation

As part of our ongoing efforts to strengthen security and improve defenses across environments, we continue to enhance protections for cross-site scripting attacks. We recommend that customers keep CVE-2026-42897 mitigation in place. The mitigation provides an additional layer of defense and helps ensure continuous protection as further improvements are released. Additional updates will be shared as they become available - now available, please see Released: July 2026 Exchange Server Security Updates | Microsoft Community Hub.

Installing the June 2026 update does not automatically remove already applied CVE-2026-42897 mitigations. Therefore, if you choose to remove mitigations after installation, you should:

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

Block the mitigation M2.1.0 from re-applying. Because of our recommendation to keep the CVE-2026-42897 mitigation in place, we are not yet updating the mitigation to not apply to servers that are updated to June 2026 SU. Therefore, at this time, you must block the mitigation from re-applying first.
Remove the mitigation M2 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

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.

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 mitigations were released, there were several reported known issues. Are those solved in the CVE-2026-42897 fix (June 2026 SU)?
Yes, when June 2026 SU is installed and mitigation is removed, known issues should be resolved too. But note that mitigations do not get removed automatically after installation of the SU (and we recommend that you keep then enabled for a little while longer).

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 June 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.

We updated our servers to June 2026 (or newer) update, but we still have trouble with known issues caused by mitigations. Why is this?
Installing the June 2026 (or newer) update does not automatically remove mitigations. Please see the post above. Currently, we recommend that mitigations stay in place but they can be removed as per the above.

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

Significant updates to this post:

7/14/2026: Added a link to Released: July 2026 Exchange Server Security Updates | Microsoft Community Hub. When installed, remove the CVE-2026-42897 mitigation to address known issues
7/13/2026: Added a Known issues section
6/15/2026: Clarification of mitigation blocking
6/11/2026: Removed the banner with documentation publishing issues (now resolved)

The Exchange Server Team

How to determine which Resource Mailboxes are being actively used

The_Exchange_Team — Fri, 26 Jun 2026 13:57:46 GMT

Today we wanted to take a few minutes to discuss a topic that has come up several times. Consider the scenario where your organization has created Resource mailboxes, and you want to know which ones are actually being used. Seems like a fair request.

This would include Room and Equipment mailboxes as well as Workspaces. Unfortunately, there are no native reports (at the time of this writing) that include details on Resource mailbox utilization. We are going to provide a few options you can use to find this information out, and you can choose which one works for you.

Option 1: Use Get-CalendarViewDiagnostics

Get the ID of a meeting - Exchange | Microsoft Learn

This will check the calendar of the specified mailbox and will provide the output of all meetings on the calendar during the specified time window.

The following example will provide a list of meetings on the calendar going back 6 months in the past and 6 months in the future:

Get-CalendarViewDiagnostics resource@contoso.com -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6)

This returns data quickly and only targets the calendar. The possible downside of this approach is that the meeting subject is not a property that is exposed. But if you are only looking to see which rooms have meetings scheduled, or get an overall count, this should work great for you.

The upside to this approach is that Exchange Online PowerShell has rich filtering capabilities, so for example you could easily target your command to all Room mailboxes or all Equipment mailboxes.

Example:

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox $roommailboxes | ForEach { Write-Host “Processing Mailbox $($_.Displayname)” ; Get-CalendarViewDiagnostics $_ -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6) }

Option 2: Use Graph to get the details of calendar events.

List calendarView - Microsoft Graph v1.0 | Microsoft Learn

On the bottom of the article, see example requests. To use this with PowerShell, you need the Microsoft.Graph.Calendar module and you need an Entra ID App registration which has the appropriate Graph permissions added.

You can either use Delegated permissions or Application permissions.

Delegated permissions mean Graph API is being accessed using a user account and will prompt for sign-in information.
Application permissions would be used for non-interactive applications/scripts where a sign-in prompt cannot be used.

Example using Application permissions:

Create Entra ID App registration
Add Graph Application Calendars.Read API permission. This allows the application to read calendar data from all mailboxes.
Create either a client secret or upload a certificate to be used for authentication. If you use a certificate, note that it can be a self-signed certificate.
Launch PowerShell and import the Graph moduleImport-Module Microsoft.Graph
Connect to Graph using PowerShell with a certificateConnect-MgGraph -ClientId <app id=""> -TenantId <your tenant="" id=""> -CertificateThumbprint <cert thumbprint=""></cert></your></app>
or

Connect to Graph using a client secret
Connect-MgGraph -ClientSecretCredential -TenantId <your tenant="" id=""></your>
Display a list of calendar items for a given time period and specify a few properties to show, such as the Organizer, Subject and Start/End time. We will use the same example as with Get-CalendarViewDiagnostics, going back 6 months in the past and 6 months in the future.Get-MgUserCalendarView -UserId resource@contoso.com -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}

Graph does have filtering capabilities, though for me it isn’t quite as easy as filtering in Exchange Online PowerShell. If you can connect to both Exchange Online PowerShell and Graph PowerShell in the same session, you could combine the two and run your command against the list of mailboxes in your variable.

Example:

Get the list of mailboxes from Exchange Online PowerShell:

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox

Then use Graph PowerShell to get the Calendar events:

$roommailboxes | foreach {Write-Host "Processing Mailbox $($_.DisplayName)"; Get-MgUserCalendarView -UserId $_.PrimarySmtpAddress -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}}

Note that there are additional properties available in addition to what was provided in the example above. You would need to determine which ones you want to show. Some of them (like Organizer and Start/End) are Type properties, so you must build an expression to handle them like we did above. Graph is also exposed to many other languages as well (HTTP, C#, Java, etc.)

Using the Graph solution, it is also possible to restrict access to only certain mailboxes (such as only Resource mailboxes).

Role Based Access Control for Applications in Exchange Online | Microsoft Learn

This would allow you to control which mailboxes the Entra ID app could pull calendar details from.

It involves configuring a management scope that defines the list of mailboxes (via a recipient filter). Once that is done, the Graph permissions in Entra ID needs to be removed, and they can then be granted in Exchange Online via RBAC (New-ManagementRoleAssignment).

Option 3: Use Get-MailboxFolderStatistics

For a very simplistic approach to checking resource mailbox usage, Get-MailboxFolderStatistics might provide what you need. Using the IncludeOldestAndNewestItems along with the FolderScope allows you to target the Calendar folder.

Example:

Get-MailboxFolderStatistics resource@contoso.com -IncludeOldestAndNewestItems -FolderScope Calendar

Similar to Get-CalendarViewDiagnostics, you have the ability to run in bulk against multiple recipients.

Example:

$roommailboxes | Foreach { Get-MailboxFolderStatistics $_ -IncludeOldestAndNewestItems -FolderScope Calendar}

Do not use Get-CalendarDiagnosticObjects for this purpose!

One last method that we’ve seen customers try use is using Calendar Diagnostic Logs with the Get-CalendarDiagnosticObjects cmdlet. Please DON’T use this method.

Get Calendar diagnostic logs for Exchange Online mailboxes - Exchange | Microsoft Learn

While it technically will work to pull meeting details, it really was not designed for bulk gathering of calendar events. Instead, it was designed to help troubleshoot problems with individual meetings. Calendar Diagnostic Log data includes not only data from the Calendar, but also all other folders where calendar-related information can be stored, including the Inbox, Sent Items, Deleted Items and Recoverable Items folders such as Calendar Logging. Querying even for a single meeting can sometimes produce in excess of 1000 logs. As such, running this in bulk for lots of meetings against a mailbox may fail, might timeout or produce errors. If you are using this method and reach out to Support because you have issues (which is very likely), we will direct you to one of the other options.

In summary, although there are no native reports available to check on which Resource Mailboxes are being used, there are several options available. If you are already connected to Exchange Online PowerShell, using Get-CalendarViewDiagnostics may be the simplest option for you. If you need more properties than what is exposed with Get-CalendarViewDiagnostics or want to be able to use a custom application that uses a different language, we recommend the Graph approach.

Ben Winzenz

Replacing IIS SMTP virtual server with Exchange Edge Transport

The_Exchange_Team — Tue, 19 May 2026 14:14:31 GMT

Years go by and we continue to see customers still relying on the IIS 6.0 SMTP virtual server feature, which has been out of support for a looong time. To give you an idea just how old this component is, the built-in IIS SMTP virtual server stack was tied to Windows Server 2003. This blog post aims to present practical options to help you retire IIS SMTP and replace it with supported Microsoft solutions (because IIS SMTP virtual server is long unsupported).

Historically, we have encouraged customers to retain their last Exchange on‑premises server in certain scenarios. One of the most common scenarios is on‑premises applications still depend on Exchange for email relay, even after all mailboxes have been migrated to Exchange Online.

Then there are also cloud‑only Exchange Online customers who have already decommissioned their last on‑premises Exchange server (or never had one at all) and, for various reasons, are unable to configure their applications, Fax and printers to relay email directly through Exchange Online. When this scenario applies, the most straightforward and supported way to eliminate the use of IIS SMTP is to replace it with a standalone Exchange Edge Transport Server. This also helps with centralized administration of one or few Edge servers instead of several applications and devices individually.

You might not know this, but running a standalone Exchange Edge Transport server can be done with minimal overhead.

It’s important to clarify what “standalone” means in this context. A standalone Edge Transport server is not subscribed to an Active Directory site. Whether or not the server is domain‑joined is irrelevant here; what truly matters is that the Edge Transport server is not Edge‑subscribed to Active Directory. In this configuration, Active Directory is effectively unaware of this Exchange server’s existence.

Why does this matter? Because subscribing an Edge Transport server to an AD site introduces additional complexity such as EdgeSync, dedicated certificates for Direct Trust, and extra operational considerations. The goal of this blog post is to provide a simple, low‑effort, and supported solution that allows you to finally retire use of legacy IIS 6.0 SMTP server without introducing unnecessary complexity into your environment.

Let’s see the following flowchart to understand the big picture of options you have:

¹ It is important to consider if the application and devices send email to only Exchange online mailbox or also send to external domains. Based on the requirement, you will need to evaluate your options mentioned in this article. If you want to send emails to external domains which essentially is relaying through Exchange online, you can:

Configure a TLS certificate-based connector for SMTP relay - this is a secure way to relay email. You need a certificate where the Subject or Subject Alternate Name (SAN) fields contain an accepted domain in Microsoft 365.

Or you can

Configure an IP address-based connector for SMTP relay - this is a less secure way to relay and is not recommended. With this method, the sender domain mentioned in the MAIL FROM must match one of the accepted domains of the tenant.

Whether you use Certificate based or IP Based connector, make sure you meet the requirements mentioned in this article.

Is it feasible to redirect all on-premises applications to Exchange Online?

There may be multiple blockers, such as:

Applications that are not allowed to perform outbound external connectivity
Legacy applications with unknown ownership or configuration
Limited ability to update or reconfigure existing applications

There are several challenges to send or relay email directly from Application and devices. Applications and devices may not support TLS/STARTTLS, and managing certificates across multiple endpoints – such as printers in branch offices – can introduce significant operational complexity and potential security risks.

A more suitable solution in this case is to deploy a standalone Edge Transport server. This allows you to centralize SMTP relay functionality and securely send messages to Exchange Online or external domains without requiring individual devices or applications to meet strict TLS and certificate requirements.

What type of authentication is used by these applications?

For example, Basic Authentication or NTLM. If either is in use:

SMTP Basic Authentication is being deprecated in Exchange Online
NTLM is not supported with Exchange Online for SMTP scenarios

As a result, reliance on these authentication methods may prevent Exchange Online use.

IIS 6.0 SMTP Assessment

Once you decide to replace your IIS SMTP server, one of the first and most critical steps is to perform a thorough assessment of its current usage.

If logging is not already enabled, ensure it is configured by navigating to:
IIS → SMTP Virtual Server → Properties → Enable Logging → Properties → Advanced

From there, select all relevant extended logging fields that will help you identify which applications and systems are relying on the IIS SMTP server.

It is recommended to allow logging to run for a sufficient period to capture a representative volume of data. This ensures that intermittent or less frequently used applications are also identified.

Additional aspects that should be assessed include:

Access tab → Authentication
Verify which authentication methods are enabled, such as:

Anonymous access
Basic Authentication
Integrated Windows Authentication

Access tab → Relay Restrictions

Confirm whether relay access is restricted to a defined list of IP addresses and review the scope of those restrictions.

Delivery tab → Advanced

Determine how outbound email is being routed:

Whether the server uses a smart host or performs direct DNS lookups

If a smart host is configured:

Go back to Access tab → Outbound Security
Verify whether authentication is required and which method is being used to connect to the smart host

To map these configurations to Exchange Edge Transport, keep the following in mind:

Settings configured under the “Access” tab in IIS SMTP will typically correspond to the Receive Connector on the Edge Transport server.
Settings configured under the “Delivery” tab will map to the Send Connector on the Edge Transport server.

Once IIS SMTP logging has been enabled and sufficient data has been collected, the next step is to analyze the logs to identify key usage patterns, such as:

Source IP addresses of applications relying via the IIS SMTP server
Sender SMTP addresses
Recipient SMTP addresses
Email volume per application and per day

IIS SMTP logs are not particularly user-friendly for analysis, especially at scale. As a result, you have few options to process and extract meaningful insights from this data:

Develop your own SQL query using Log Parser and Log Parser Studio or
Share your IIS SMTP logs with Copilot and ask it to parse according to your needs

Another important aspect to assess is how applications are configured to connect to the IIS SMTP server:

Do applications reference the IIS SMTP server via a hard-coded IP address, or via a DNS alias? The alias could be either a CNAME or a host (A) record.

If applications are using a DNS alias, the transition to Exchange Edge Transport is typically straightforward. In this case, you can redirect mail flow by simply updating the IP address associated with the alias in DNS. However, if applications are configured with a hard-coded IP address, the transition becomes more complex. In this scenario, you have two main options:

Update each application individually: Replace the IIS SMTP server IP with the Exchange Edge Transport IP. This is the cleanest approach; however, it is often the most time-consuming and operationally challenging.
Reuse the existing IIS SMTP IP address: Assign the same IP address to the Exchange Edge Transport server as a secondary IP. While Microsoft generally discourages IP reuse in Exchange environments, this guidance primarily applies to AD-integrated Exchange roles. In this case, since the Edge Transport server is standalone and does not store objects on Active Directory, IP reuse can be acceptable if carefully planned and executed.

Once all relevant IIS SMTP data has been collected and analyzed, you can proceed with the Exchange Edge Transport deployment.

If additional details are required for the assessment phase, refer to the FAQ section, where common caveats and IIS SMTP-specific considerations are covered.

Exchange Edge Transport considerations

Assuming you have decided to decommission IIS SMTP and use the Exchange Edge Transport role for email relay, the next key decision is whether the Edge Transport server should be deployed on a domain-joined machine.

Microsoft generally recommends deploying the Edge Transport role on a non-domain-joined server. However, this guidance applies primarily to traditional Exchange environments where Edge Transport is installed in the perimeter network and is subscribed to an Active Directory site that includes Mailbox servers.

In a scenario where no Exchange Mailbox role is present, the decision should be driven by your authentication, security, and management requirements. To help guide this choice, consider the following questions:

Do you need to enforce Basic Authentication or Integrated Windows Authentication using domain service accounts? If yes, deploying the Edge Transport on a domain-joined server is needed.
Can you rely on local accounts for authentication (e.g., Basic Authentication without domain dependencies)? If yes, a non-domain-joined server is sufficient.
Do you need to apply Group Policy Objects (GPOs) or centralized security baselines? If yes, consider a domain-joined deployment to enable centralized management and compliance enforcement.

Note that whether you install Edge on a domain joined machine or not, because you are not creating a subscription to Active Directory, installation of Edge will not require extending the schema and preparing AD for Exchange Server.

Requirements

Once the decision has been made, proceed with the installation of the Exchange Edge Transport role on an up-to-date server. Follow the official prerequisites documentation to prepare the environment. Note that only a limited set of components is required:

.NET Framework
Visual C++ 2012 Redistributable
Active Directory Lightweight Directory Services (AD LDS)

No additional Exchange roles or dependencies are needed.

Network and security:

TCP port 25 must be permitted between the Edge server and applications or devices that will use Exchange Edge Transport for email relay. Typically, it should not be exposed to internet assuming that these applications or devices are placed within the internal network.
Outbound TCP port 25 must be permitted between the Edge server and external networks to enable SMTP mail flow.
Ensure the server is properly hardened, following standard security best practices.
Refer to this article for Antivirus running on Exchange Server. The “Servers” column can be used to distinguish the necessary exclusions related to Edge Transport.

If high availability is required, consider deploying two standalone Edge Transport servers behind a load balancer, or DNS round-robin. This approach helps minimize service disruption during maintenance activities such as Windows or Exchange patching.

Accepted domain

Since the installation of the Exchange Edge Transport role is relatively straightforward, it will not be covered in this article. At this stage, we assume that the Edge Transport server has already been successfully deployed and is fully operational.

The first step is to configure the Accepted Domains on the Edge Transport server. You can refer to the relevant documentation for the exact command syntax and parameters required.

It is important to note that a standalone Edge Transport role does not have Resolve engines (e.g., no recipient or sender validation against Active Directory or ADAM). Because of this behavior, the distinction between Authoritative and Internal Relay domains does not have a functional impact on the Edge Transport server in this scenario.

Receive connector

Once the Edge Transport is installed, it will automatically create a Receive Connector as described in this article.

To customize the Receive connector to satisfy your needs, you will need to understand how the IIS SMTP was used by your application for email relay. Assuming that your only Accepted Domain is contoso.com:

If your applications are sending unauthenticated to contoso.com recipients (app1@contoso.com sends to john@contoso.com): Use the default connector, no need to create a new one.
If your applications are sending authenticated emails through Basic Auth or Integrated Windows using contoso.com as sender SMTP address to any recipient (app1@contoso.com sends to john@contoso.com and adele@fabrikam.com):

Create a new Receive Connector with ExchangeUsers Permission Group, assign the Authentication mechanism as BasicAuth and/or Integrated and add the IP or range of your applications to RemoteIPRanges:

New-ReceiveConnector -Name "BasicAuth" -AuthMechanism BasicAuth -RemoteIPRanges "192.168.0.1" -PermissionGroups ExchangeUsers -Custom -Bindings 0.0.0.0:25

And add the permission ms-Exch-SMTP-Accept-Authoritative-Domain-Sender to the connector. As mentioned before, since Edge Transport doesn’t have Resolve engine, it cannot validate the primary SMTP address of the authenticated user, otherwise you will get the “550 5.7.60 SMTP; Client does not have permissions to send as this sender” error.

Get-ReceiveConnector BasicAuth | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"

If your applications require an open relay, although not recommended, you can follow the steps described in this article.

Send connector

In a fresh Exchange Edge Transport installation, no Send connector is created by default. Therefore, you will need to configure it from scratch.

As highlighted earlier, it is essential to first understand how your existing IIS SMTP server handles outbound relay. This includes determining whether it uses:

Direct DNS resolution, or a smarthost (and any associated Basic authentication)
Whether you want to have different routes per domain

This information will directly influence the configuration of your Send connector on the Edge Transport server. You can refer to the relevant documentation for detailed guidance on the required commands and parameters to properly create and configure the Send Connector.

Switch the mail flow

At this stage, the IIS SMTP assessment should already be complete, and you should understand how applications connect to it – a DNS record or a hard-coded IP address.

If a DNS alias is used (e.g., CNAME or A record):
The transition is typically straightforward. You can redirect mail flow by updating the DNS record to point to the Exchange Edge Transport server.
If applications use a hard-coded IP address:
Consider reusing the existing IIS SMTP IP address. The process is relatively simple:
- Disable the network interface (NIC) on the IIS SMTP server
- Assign the IIS SMTP server IP address as a secondary IP on the Exchange Edge Transport server
- Update the existing DNS A record associated with the IIS SMTP server to point to the Exchange Edge Transport server

As a best practice, always validate mail flow with a subset of applications before performing the full cutover. This helps identify potential issues early and ensures a smooth transition.

(Optional) Setting Exchange Online as a smarthost

If you have Exchange Online tenant, you can use your standalone Edge Transport to relay emails through Exchange Online by configuring your tenant MX as a smarthost in the Edge’s Send connector. Although not required, we encourage you to bind a certificate with the same domain name that you have in your Exchange Online as Accepted Domain. This would ensure a proper message attribution process and your emails coming from Edge Transport will be marked as Originating.

First, you need to figure out what is the MX record of your tenant, please follow this appendix to get this information.
Add the value to your Send connector as a smarthost
Import the certificate to the Personal computer container and assign the SMTP service to it
Bind the certificate to the Send connector

$Cert = Get-ExchangeCertificate -Thumbprint "<new certificate thumbprint>"

$TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)"

Set-SendConnector -Identity "Send Connector Identity" -TlsCertificateName $TLSCertificateName

Set the following properties on the connector:

Set-SendConnector -Identity "Send Connector Identity" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.protection.outlook.com

Now we need to create the Inbound connector in Exchange Online to attribute these messages coming from the Exchange Edge Transport:

New-InboundConnector -Name "FromEdgeTransport" -ConnectorType OnPremises -SenderDomains * -RequireTls $True -TlsSenderCertificateName "Your Certificate CN"

Lastly, ensure to add the EOP and your Edge Transport public IP to the SPF record in the public DNS as described here. This is an important step to avoid either external recipients marking your emails as spoofing or the EOP itself marking emails from your Edge as spoofing. If you want to increase your security posture, you can also enable DKIM and create your DMARC policy for your domains.

FAQ

How to figure out domain or local accounts being used on IIS SMTP to send using Basic Authentication?
Unfortunately, the IIS SMTP logs will not show what account has been used to perform basic authentication when sending emails. The following XML query can be used to filter Security event viewer logs:

<QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
    *[System[(EventID=4624)]]
    and
    *[EventData[Data[@Name='LogonType']='3']]
    and
    *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\inetsrv\inetinfo.exe']]
   </Select>
  </Query>
</QueryList>

What’s the benefit of getting rid of IIS 6.0 SMTP and moving to an Exchange Edge Transport?
IIS 6.0 is no longer supported, and therefore you should not expect any security updates or assistance from Microsoft Support. From a technical perspective, the Exchange Edge Transport role provides significantly more capabilities and control over mail flow, including:

Enhanced logs such as message tracking logs and pipeline tracing
Improved security and control mechanisms
The ability to implement transport rules (although more limited compared to a full Exchange Mailbox role)

Overall, Exchange Edge Transport represents a more modern, secure, and manageable solution compared to legacy IIS SMTP.

Can we use Address Rewrite feature in a standalone Edge Transport?
Yes, but there are important caveats to consider.

Inbound Address Rewrite is supported and works as expected on a standalone Edge Transport. You can safely follow the standard procedure described in the documentation to implement it.

The Outbound Address Rewrite has some limitations that you should be aware of. This feature depends on the Address Rewriting Outbound Agent, which is only triggered when the MAIL FROM is treated as authenticated. Specifically, the agent relies on the presence of the header: X-MS-Exchange-Organization-AuthAs: Internal.

At first glance, you might assume that using Basic Authentication or Integrated Windows Authentication would satisfy this requirement. However, this is not the case for a standalone Edge Transport deployment. Regardless of the authentication method used when submitting messages to a standalone Edge Transport, the header X-MS-Exchange-Organization-AuthAs is always stamped as Anonymous.

As a result, the Outbound Address Rewrite agent is never triggered under normal conditions.

The only supported workaround to force the standalone Edge Transport to treat messages as internal – and therefore enable outbound address rewriting – is to configure the receive connector with the ExternalAuthoritative authentication mechanism. This effectively promotes the AuthAs value to Internal.

Enabling ExternalAuthoritative effectively turns the receive connector into an open relay. You must therefore implement appropriate restrictions (such as IP scoping and strict access controls) to secure the connector and prevent abuse. Refer to this article for further information.

How does Microsoft 365 IP throttling deal with messages coming from a standalone Edge Transport?
In the same way as it handles in Hybrid mail flow if you followed our recommendation stated on “Setting Exchange Online as smarthost” section. If you had a Hybrid Exchange on-premises and are moving to a standalone Edge Transport, our advice is to keep the same public IP used by your previous Exchange Server on the new Edge Transport since this IP will have a sending history and clean reputation.

Can we deploy a standalone Edge Transport as an Azure VM?
You can but consider that outbound SMTP on Azure VMs is only supported if you have Enterprise Agreement or Microsoft Customer Agreement for enterprise (MCA-E) subscriptions. For more information see this article. Additionally, you may need to establish proper network connectivity from your applications to the Azure VM. This typically requires configuring network routing – such as Azure ExpressRoute – to enable your on-premises traffic to reach the Edge Transport VM securely and reliably.

Edge Transport is configured to use Exchange Online as smarthost but emails are being received as “AuthAs:Anonymous”. Can we change this behavior marking messages as Internal?
The Edge Transport role does not perform header promotion regardless if Edge is subscribed to a Mailbox Exchange Server or standalone. It is up to the Mailbox role to promote Organization headers to CrossPremises and then the Edge just honors the promotion. Refer to this article to find more information about header promotion. The only way to enforce “AuthAs:Internal” on messages coming from an Edge Transport is enabling TreatMessagesAsInternal attribute on Exchange Online Inbound connector. This option works only if sender domain matches an accepted domain in Exchange Online.

Thanks to Arindam Thokder for his support and review of this article.

Denis Vilaça Signorelli
Cloud Solution Architect

Exchange Team Blog articles

Released: September 2026 Exchange Server Security Updates

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

Known issues with this release

Issues resolved in this release

Update installation

FAQs

Exchange Server AD FS Modern Authentication: Expanded Outlook client support

Supported clients at a glance

Updated documentation

Learn more

Take control of your EWSAllowedAppIDs list before EWS access changes

What happens during rollout

Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline

Tell us how you use ObjectGuid, SamAccountName, and DistinguishedName in Exchange Online

Help us shape Exchange Server on-premises to different online org Free/Busy after EWS retirement

Notes from the field: testing EWSAllowedAppIDs safely

A note from the field

Understand the two controls before testing

What the test proves

Before you start

Test 1: Confirm access while the app is allowed

Test 2: Remove the app and confirm access is blocked

The fastest way to re-enable EWS after App ID blocking

EWSEditor is another option

Common pitfalls to avoid

Customer guidance in one paragraph

Sources and further reading

Understanding the new 100 GB mailbox entitlement for Microsoft 365 Business suites

What changed for the Business suites

The supported quota outcome

How the additional quota is implemented

Custom mailbox quotas are preserved

Reviewing the user’s licenses and service plans

Review the effective Exchange mailbox quota

Common license and quota scenarios

Rollout and license propagation

Where is Exchange SE CU1 anyway?

Released: August 2026 Exchange Server Security Updates

OWA Light is disabled starting with this update

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

Known issues with this release

Update installation

FAQs

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

Is your organization impacted by this change?

What's changing, and why

How the new model works

How to check your sharing configurations?

The rollout schedule for Cross-Tenant Access Policy

What happens if you do nothing?

Not ready by October? You have a runway

What you need to do

Further reading

Frequently Asked Questions

Major updates to this blog post:

Writeback for Cloud-Managed Remote Mailboxes: Now Generally Available

A quick recap

What's new at GA

Support for up to 600,000 cloud-managed mailboxes

Writeback for the MAIL attribute

Existing Public Preview configurations require one update

Important reminder about tenant-wide SOA

A path towards removing the last Exchange Server

Get started

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

Released: July 2026 Exchange Server Security Updates

Check for presence of legacy Exchange security groups

Remove CVE-2026-42897 mitigations after installation

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

Known issues with this release

Update installation

FAQs

Cross-Tenant Message Recall in Exchange Online

The intra-tenant boundary

Introducing cross-tenant Message Recall

How it works

Configuring with Exchange Online PowerShell

What senders and recipients see

Availability