rss.livelink.threads-in-node

Released: June 2026 Exchange Server Security Updates

The_Exchange_Team — Thu, 11 Jun 2026 12:19:27 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.

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

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.

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

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.

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.

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

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

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

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

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

Significant updates to this post:

6/11/2026: Removed the banner with documentation publishing issues (now resolved)

The Exchange Server Team

Exchange SE HU6: PDF attachments truncated to 13 KB via Outlook Desktop — OWA unaffected

BrewDrew — Tue, 09 Jun 2026 10:10:16 GMT

We've spent days isolating this and ruled out everything we could touch. The corruption survives agent disabling, Bitdefender removal, and BypassFiltering — and the message tracking logs show exactly where it happens.

Environment: Exchange Server SE, Build 15.2.2562.41 (HU6 / KB5081755), Windows Server 2025

Problem: PDF attachments sent internally via Outlook Desktop (MAPI) arrive corrupted at ~13 KB (original: ~32 KB, no xref/EOF). All PDF sizes, all internal recipients affected. Started 21 May 2026.

Key finding — OWA works, Outlook Desktop doesn't: Sending the identical email via OWA → attachment arrives intact. Outlook Desktop → truncated.

Message tracking proof: Both paths deliver the message at full size (~42 KB) via STOREDRIVER DELIVER. Only the Outlook Desktop delivery shows an additional X-SDDS=0.106 step in the STOREDRIVER latency breakdown. That step does not appear in the OWA delivery. The corruption happens inside that MAPI/TNEF store write step — not in transport.

Systematically ruled out:

All transport agents disabled → still 13 KB
Exchange Malware Agent + Set-MalwareFilteringServer -BypassFiltering $true → still 13 KB
Bitdefender GravityZone fully uninstalled from server → still 13 KB
EEMS mitigations: only PING1 and M2.1.0 applied, neither affects MAPI delivery

Temporal correlation: Three Windows updates installed 21.05.2026: KB5087051 (.NET Framework 4.8.1), KB5087539 (Windows Server 2025 CU), KB5089717 (Servicing Stack). Exchange SE HU6 (KB5081755) was installed around the same period.

Workaround: Sending via OWA works. Not acceptable long-term.

Has anyone seen this? Is this a known regression in HU6 or KB5087051?

Will server to server migration work cross-domain/cross-active directory?

Ted_Mittelstaedt — Thu, 04 Jun 2026 05:51:41 GMT

Back in 2016, I upgraded a client from Exchange 2008R2 to Exchange 2016. The way I did it was "the textbook way" I built the new Exchange 2016 server on the same network as the 2008R2 server, and migrated the mailboxes from the old server to the new server, using the migration tool in the ECP interface, then deinstalled the server. It was a pretty cake migration except for one problem - the internal AD domain name was "wonkulating.com" however the client had failed to maintain public registration for that domain, and had registered "wonkulatinggronkulator.com" for use on the Internet. So I set it up so that all internal and external access was to "email address removed for privacy reasons" User were happy, and the IT dept was able to kick the migration can down the road again.

Well fast forward a decade. Now I'm an employee for the former client and worse I manage the IT group there - so my can-kicking bandaid has come back to haunt me now that it's time to update to exchange SE. (it also adds to the fun that there's a couple hundred more users on the network than there were a decade ago) I decided to cut the Gordion knot and kill off "wonkulating.com" since there's not a snowball's chance in hades we could afford to buy it now. So I built a new AD for wonkulatinggronkulator.com, and did the jiggery pokery with the DNS servers and setup trust between the forests and so on and now, servers on both domains are happy happy, I can apply both wonkulating.com and wonkulatinggronkulator.com security objects to server filesystems, users can login to either domain at any workstation regardless of what domain the workstation was joined to, and so on, and we are getting ready to migrate the users and workstations off the old AD and on to the new AD.

My question to all of you is this. I'm planning on installing Exchange SE into the new AD forest wonkulatinggronkulator.com and we will move the users over in groups of 10 or 20 or so, so that staff can make sure everyone is happy, can login, get at their files, etc. But what I am wondering is if the exchange servers will cooperate with each other. I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers. (we are too big now for the come-in-on-weekend-and-hose-everything-up-in-a-mad-rush-migration-fueled-with-pizza-and-mountain-dew routine) It would be very nice to just kick off a migration job on one of the mailservers and have the inbox copied over, but if I have to I can tear out the mailbox on the old server into a PST file and jam it into the new server via import.

Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic. Like most orgs we have a bastion host mailserver that touches the actual Internet, the exchange server is only allowed to provide OWA services to the Internet, while the bastion host server (running Linux, by the way) does the actual heavy lifting of spam scanning and filtering out scam mails. Only cleaned mail is passed to the on-prem exchange server. So if the servers -won't- cooperate cross-forest, then I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on.

Technically, the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser, so the servers SHOULD be smart enough to know they are different userIDs - except that the server on wonkulating.com was hacked up by me a decade ago to believe it was authoritative for BOTH "email address removed for privacy reasons" and "email address removed for privacy reasons" email addresses and that they were the same userID basically. So, I don't know what's going to happen until I try it and all of the documentation I can find on this matter is pretty fluffy, as it assumes you are moving from a domain name you own to a different domain name you own because you bought a company or something, or you are moving from one mailserver to the other inside of the same forest/domain.

Lastly, suggestions to install Exchange SE into wonkulating.com then move it later into wonkulatinggronkulator.com will be /dev/nulled immediately, I'm done kicking the can down the road. There's more than 20 years of garbage in the wonkulating.com AD and the nonsense described here is just the tip of the iceberg. (you should see the GPO's in wonkulating.com, simply horrifying)

Thanks!

Reporting Recent Distribution List Changes

TonyRedmond — Tue, 02 Jun 2026 09:15:43 GMT

A recent discussion about reporting changes to Microsoft 365 groups provoked the question about how to report distribution list changes. The answer is that the same structure can be taken in a PowerShell script to fetch and report data, including the audit records containing the information about the changes, but the actual code is very different. Distribution lists Exchange Online objects and not Entra ID groups…

https://office365itpros.com/2026/06/02/distribution-list-changes/

FIX - Outlook 2013,2016,2019 fails open mailbox Exchange 2019 on-prem in offline LAN

MaVy — Mon, 01 Jun 2026 10:44:38 GMT

Exchange 2019 on-prem + Outlook 2013/2016/2019 in offline LAN

Symptoms:

- OWA works

- ECP works

- Autodiscover works

- Test-MAPIConnectivity is successful

- Outlook profile can be created

- Outlook fails to open the mailbox / “Cannot start Microsoft Outlook” / “The set of folders cannot be opened” / “The attempt to log on to Microsoft Exchange has failed”

- Environment has no internet connection

Root cause:

The Windows client had a default gateway configured, but the gateway IP did not respond to ping. In our case the client received 192.168.1.1 as default gateway, but this IP was unreachable in the offline network.

Fix:

Set the client default gateway to an existing reachable IP address, for example the Exchange/DC server IP 192.168.1.5. Internet access is not required, but the default gateway must be reachable/responding.

After changing:

Default gateway: 192.168.1.5

DNS: 192.168.1.5

mail/autodiscover DNS or hosts pointing to Exchange 2019

Result:

Outlook 2013, Outlook 2016 and Outlook 2019 connected to Exchange 2019 successfully.

HVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale

Lucaraheller — Wed, 27 May 2026 16:42:46 GMT

Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online.

This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines.

But HVE should not be misunderstood.

It does not mean that every mailbox in Exchange Online should now be used for mass email.

It does not mean Exchange Online has become a general-purpose marketing platform.

And it does not remove the need for proper outbound email governance.

Why HVE Matters

For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications.

That approach creates several problems.

Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse.

HVE introduces a more appropriate model for specific high-volume scenarios.

Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios.

What HVE Is Designed For

HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant.

Examples include:

Internal application notifications.

Line-of-business system messages.

Device-generated messages.

Operational alerts.

Security advisories.

Internal workflow communications.

Monitoring platform alerts.

IT service notifications.

Large-scale internal announcements generated by systems.

This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow.

In practical terms, HVE is useful when the sender is not a human user, but a controlled business system.

What HVE Is Not

HVE is not a replacement for marketing platforms.

HVE is not a general-purpose internet bulk email engine.

HVE is not a way to bypass Exchange Online sending limits for external campaigns.

HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email.

For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform.

When to Use HVE

Use HVE when the workload matches these characteristics:

The sender is an application, device, service, or business system.

The recipients are primarily internal users in the Microsoft 365 tenant.

The volume is higher than what should be sent from a standard mailbox.

The workload is operational, automated, or transactional.

The organization needs centralized Microsoft 365 administration and reporting.

The organization wants to avoid impacting user mailbox sending limits.

The use case is approved, documented, monitored, and governed.

Good examples:

A security platform sending internal security advisories.

A monitoring system sending infrastructure alerts to internal teams.

A business workflow system sending high-volume approval or status notifications.

An IT service platform sending internal notifications.

A service management platform sending ticket updates to internal users.

A device management system sending operational messages to internal teams.

When Not to Use HVE

Do not use HVE when the workload is external bulk email.

Avoid HVE for:

Marketing campaigns.

Newsletters to customers.

Promotional email.

Mass external invitations.

External transactional email at scale.

Customer invoices and receipts in high volume.

OTP or password reset flows for external users.

External portal notifications.

Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required.

Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance.

Who Should Be Allowed to Use HVE

HVE should not be enabled casually for every team or every application.

It should be treated as a controlled platform capability.

Recommended eligible senders:

Approved line-of-business applications.

Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams.

Managed devices or services with a clear business purpose.

Internal platforms that send operational messages to employees.

Applications with documented ownership, authentication, monitoring, and expected volume.

Recommended non-eligible senders:

Normal users.

Shared mailboxes used by humans.

Marketing teams sending to external audiences.

Unmanaged scripts.

Legacy systems with no owner.

Applications with unknown volume.

Systems that send to external recipients at scale.

Any application using HVE just to avoid standard mailbox limits.

The core principle is simple:

HVE should be enabled for workloads, not for convenience.

Governance Model

Before enabling HVE, organizations should define a governance model.

At minimum, each HVE account should have:

A named business owner.

A technical owner.

A documented purpose.

Expected daily and monthly volume.

Recipient scope.

Authentication method.

Monitoring process.

Incident response path.

Decommissioning criteria.

Review frequency.

HVE accounts should not become invisible service accounts that nobody owns.

They should be treated as privileged communication identities.

Security and Authentication

HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications.

This is important because organizations should avoid broad, uncontrolled access.

They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose.

For example:

One HVE account for security alerts.

One HVE account for monitoring systems.

One HVE account for IT service notifications.

One HVE account for internal operational communications.

This separation improves visibility, investigation, accountability, and risk containment.

HVE vs Standard Exchange Online Mailboxes

A standard Exchange Online mailbox should be used for normal human communication.

A shared mailbox should be used for collaborative business processes.

An HVE account should be used for approved high-volume internal system email.

A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email.

Scenario	Recommended Platform
Human business email	Exchange Online mailbox
Team or department mailbox	Shared mailbox
Low-volume application notifications	Standard Exchange Online, if approved
High-volume internal system notifications	HVE
Internal operational alerts at scale	HVE
Marketing campaigns	Marketing platform
External transactional email	Transactional email service
Customer newsletters	Marketing automation platform
OTP/password reset for external users	Dedicated transactional platform
External bulk email	Dedicated bulk email provider

HVE and the Mailbox External Recipient Rate Limit Cancellation

Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely.

However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending.

Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit.

That distinction is important.

The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture.

Exchange Online still has service limits.

Outbound spam controls still apply.

Tenant-level protections still matter.

And HVE is still not a marketing engine.

Practical Architecture Decision

Before enabling HVE, ask these questions:

Who is sending?

Is the sender a human, shared mailbox, application, or device?

Who are the recipients?

Are they internal or external?

What is the expected volume?

Is the workload operational, transactional, promotional, or human communication?

Does the business need Microsoft 365 mail flow and governance?

Does the use case require bounce handling, unsubscribe, tracking, or reputation management?

Is the application properly authenticated and monitored?

Who owns the account?

Who approves the sending pattern?

Who responds if the account is abused?

If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer.

If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform.

Recommended Enablement Approach

Organizations should enable HVE in phases.

First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending.

Second, classify each workload as internal, external, operational, transactional, marketing, or human communication.

Third, migrate only approved internal high-volume workloads to HVE.

Fourth, move external high-volume workloads to dedicated email delivery platforms.

Fifth, monitor usage and review HVE accounts regularly.

This avoids turning HVE into another uncontrolled sending layer.

Conclusion

High Volume Email for Microsoft 365 is an important addition to Exchange Online.

It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic.

But HVE is not a free pass for bulk email.

It is not a marketing platform.

It is not a replacement for transactional email services.

And it should not be enabled for every mailbox or every application.

The right approach is workload classification.

Use Exchange Online for corporate communication.

Use HVE for approved high-volume internal system messaging.

Use dedicated platforms for external bulk, marketing, and transactional email.

The question is not only:

“Can this system send email through Microsoft 365?”

The better architectural question is:

“What type of email is this, who is the audience, and what is the correct platform for this workload?”

That is where proper email architecture begins.

Tenant-to-Tenant Migration with Orchestrator – Technical Overview (Microsoft 365 | Preview)

Lucaraheller — Wed, 27 May 2026 16:29:18 GMT

Tenant-to-tenant migration with Orchestrator in Microsoft 365 introduces a native, API-driven, and highly validated approach for cross-tenant migrations. It is designed for enterprise scenarios where sequencing, dependencies, and governance are critical.

Note: This capability is currently in preview. Features and behavior may change before GA.

Architecture and execution model

Migration is executed through batches (jobs) managed via Microsoft Graph (Beta)
User-level execution: one user failing validation does not block others in the same batch
Mandatory Standalone Validation before migration submission
Date-driven cutover using completeAfterDateTime

Supported workloads (actual scope)

Exchange Online
Microsoft Teams
ODSP (OneDrive for Business)

Important clarification on SharePoint Orchestrator does not migrate shared SharePoint content such as Team sites, Channel sites, or collaboration sites. The ODSP workload covers personal user data (OneDrive) only. SharePoint team/workload sites remain out of scope and require separate tooling or processes.

Critical prerequisites

Identity Mapping (CTIM) is mandatory and must remain stable during migration
Target users must not have Exchange mailboxes or OneDrive sites provisioned before migration
Licenses must be assigned only after Identity Mapping (ExchangeGuid stamping)
Migration apps and service principals (Teams, Meetings, CTMS) must be correctly provisioned
Organization Relationships and Migration Endpoints must be in place
Exchange autoforwarding must be enabled for Meetings migration

Validation and lifecycle

Standalone Validation acts as a full “what-if” check
Key states include:
Cancellation or user removal is possible only before cutover

Post-migration cleanup

After completion, tenants must be returned to a non-migration state:

Remove Identity Mapping data
Remove Organization Relationships
Remove Migration Endpoints
Revoke migration app permissions and service principals
Decide whether to retain or remove MailUsers in the source tenant

Skipping cleanup leaves the tenant in an exception state.

When this approach fits

Mergers and acquisitions
Divestitures and tenant splits
Regulated environments requiring strict control
Scenarios where dependency-aware sequencing matters more than speed

Technical conclusion

Orchestrator is not a one-click solution. It delivers native orchestration, deep validation, and predictable execution when Identity Mapping, licensing order, and scope boundaries are fully understood.

For experienced administrators and architects, it represents a major step forward in tenant-to-tenant migrations within Microsoft 365, even while still in preview.

How to determine which Resource Mailboxes are being actively used

The_Exchange_Team — Thu, 21 May 2026 13:38:55 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 module

Import-Module Microsoft.Graph

Connect to Graph using PowerShell with a certificate

Connect-MgGraph -ClientId <App ID> -TenantId <your tenant ID> -CertificateThumbprint <cert thumbprint>

Connect to Graph using a client secret

Connect-MgGraph -ClientSecretCredential -TenantId <your tenant ID>

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

Writeback for Cloud-Managed Remote Mailboxes: Now in Public Preview

The_Exchange_Team — Fri, 15 May 2026 17:37:57 GMT

In our previous posts, we announced the Public Preview and the General Availability of Cloud-Managed Remote Mailboxes – a key step toward retiring the 'last Exchange Server' in your organization. The response from the community has been incredible, and your feedback continues to shape the roadmap.

Today, we're excited to share two new milestones in this journey:

Writeback for Cloud-Managed Remote Mailboxes is now in Public Preview.
For customers with no remaining dependency on their last Exchange Server, a guide for decommissioning your last Exchange Server is now published on Microsoft Learn.

Writeback for Cloud-Managed Remote Mailboxes: Public Preview

When you set IsExchangeCloudManaged to True on a directory-synchronized mailbox, the Exchange-attribute Source of Authority (SOA) transfers to Exchange Online. The SOA for identity attributes (name, department, and so on) stays on-premises in Active Directory, but the Exchange-related attributes (proxy addresses, hide-from-address-book, custom attributes, and similar) become editable in the cloud.

Until now, after transferring Exchange-attribute SOA to cloud those Exchange attributes were edited cloud-side only – they didn't flow back to on-premises AD. That gap was a problem for organizations whose on-premises line-of-business applications still read attributes like proxyAddresses, custom attributes, and similar directly from AD. Once SOA flipped to the cloud, the on-premises AD copy of these attributes would start drifting out of sync with the cloud.

Writeback closes that gap. With writeback enabled, changes made in Exchange Online to designated Exchange attributes are automatically pushed back to on-premises Active Directory through Microsoft Entra Cloud Sync. Your on-premises AD stays current, and your line-of-business applications keep working – even after the Exchange-attribute SOA has moved to the cloud.

How it works

Writeback uses Microsoft Entra Cloud Sync as the transport from Exchange Online back to on-premises AD. If you already use Microsoft Entra Connect Sync, you do not need to uninstall or replace it. Cloud Sync runs alongside Connect Sync – Connect Sync continues to handle your directory synchronization exactly as before, and Cloud Sync only handles the Exchange attribute writeback. There is no impact on your existing mailboxes, users, or sync configuration.

Steps to install the Cloud Sync provisioning agent, configure the writeback synchronization job, and verify the round-trip flow are all in the documentation: Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments.

Public Preview limits and GA timeline

During Public Preview, writeback supports tenants with fewer than 200,000 cloud-managed mailboxes. We will raise this limit at General Availability, currently targeted for the end of June 2026.

The complete list of attributes supported for writeback – which attributes flow back to AD and which don't – is available in Identity, Exchange Attributes and Writeback.

New Documentation: Decommission the Last Exchange Server

Once your mailboxes are cloud-managed (and writeback is in place if your applications need it), the next question is the one this whole effort has been about: how do you actually retire the last Exchange Server?

We've published a new end-to-end guide that walks through exactly that: Decommission the last Exchange Server after transferring SOA to cloud.

The guide covers:

Prerequisites – confirming all mailboxes and public folders have moved to Exchange Online, all directory-synchronized mailboxes are cloud-managed, DNS and mail routing point at Exchange Online, and you've migrated any SMTP relay dependencies.
Pre-removal verification – re-verifying each prerequisite immediately before starting, since the environment may have drifted.
Hybrid cleanup (while Exchange is still running) – removing the Hybrid Configuration object, HCW-created intra-organization connector, hybrid connectors, organization relationship, federation trust and certificate, OAuth service principal credentials, and the Hybrid Agent (modern hybrid only).
Uninstall the last Exchange Server – final pre-uninstall checks and running Setup /m:Uninstall.
Hybrid cleanup in Exchange Online (post-uninstall) – removing orphaned hybrid objects from the cloud side that the on-prem uninstall doesn't clean up.

If you've been holding off on removing your last Exchange Server because the procedure wasn't clearly documented end-to-end, this is the article you've been waiting for.

Get started

If you've been waiting for Writeback Public Preview to start your decommissioning journey, now is the time:

Review the updated documentation for the writeback setup walkthrough and the full attribute list.
Read the new decommissioning guide for the end-to-end uninstall procedure.
In case the limit of 200k for Writeback feature blocks your adoption, please reach out to us through this form. As communicated, we will increasing the limit by GA timeframe, but it would be good to know what scale would unblock you.
Share your experiences and suggestions in the comments below – your feedback shaped the previous releases, and we want it for this one too.

The era of maintaining an Exchange server "just because we sync our AD" is coming to an end.

Exchange Online Management and Exchange Hybrid teams

Addressing Exchange Server May 2026 vulnerability CVE-2026-42897

The_Exchange_Team — Tue, 09 Jun 2026 17:13:57 GMT

UPDATE June 9, 2026: Please see our release blog post for June 2026 Security Update for more information on this CVE: Released: June 2026 Exchange Server Security Updates | Microsoft Community Hub.

On May 14, 2026, Microsoft disclosed CVE-2026-42897, a reported vulnerability affecting Exchange Outlook Web Access (OWA). An attacker could exploit this issue by sending a specially crafted email to a user. If the user opens the email in Outlook Web Access and certain interaction conditions are met, arbitrary JavaScript can be executed in the browser context.

The following on-premises Exchange Server versions are impacted:

Exchange Server 2016 (any update level)
Exchange Server 2019 (any update level)
Exchange Server Subscription Edition (SE) (any update level)

Exchange Online is not impacted by this vulnerability.

Mitigations

Option 1 (recommended): Exchange Emergency Mitigation (EM) Service

For customers who have the Exchange EM Service enabled, Microsoft released the automatic mitigation for Exchange Server 2016, 2019 and SE. The mitigation is already published and is enabled automatically.

As a reminder – EM Service was released in September 2021 and is enabled by default. More information on this service can be found in Exchange Emergency Mitigation Service (Exchange EM Service) | Microsoft Learn.

Customers with EM Service enabled can verify that their servers have applied the mitigation for CVE-2026-42897 (the ID of mitigation is M2.1.x) by doing the following:

Follow the steps outlined in the documentation: Viewing Applied Mitigations.
To quickly check the status of EM Service and applied mitigations in your organization, you can run Exchange Health Checker script: https://aka.ms/ExchangeHealthChecker. The HTML report will include a section on EEMS check results.

Using EM Service is the best way for your organization to mitigate this vulnerability right away. If you have EM Service currently disabled, we recommend you enable it right away.

Please note that EM Service will not be able to check for new mitigations if your server is running Exchange Server version older than March 2023 as per this article. To check the exact version of Exchange currently in use, utilize Option 1 or Option 2 mentioned on this page: Exchange Server build numbers and release dates | Microsoft Learn.

Option 2: Scripted application of mitigation

For customers who are unable to use the EM Service (for example, disconnected or air-gapped environments), we are providing the following process to enable this mitigation:

Download the latest version of the Exchange on-premises Mitigation Tool (EOMT) from:

https://aka.ms/UnifiedEOMT

Apply the mitigation on a per server base or on all servers at once by running the script via an elevated Exchange Management Shell (EMS):

Single server:

.\EOMT.ps1 -CVE "CVE-2026-42897"

All servers:

Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Please note that mitigations do not work if the client that is used to access OWA is Internet Explorer or Microsoft Edge using Internet Explorer Mode. Internet Explorer does not support Content Security Policy (CSP).

Known issues when mitigation is applied

We are aware of following known issues once CVE-2026-42897 mitigation is applied (using either option above):

OWA Print Calendar functionality might not work. As a workaround copy the data or screenshot the calendar you want to print or use Outlook Desktop client.
Inline images might not display correctly in the recipients OWA reading pane. As a workaround, send images as email attachments or use Outlook Desktop client.
OWA light (OWA URL ending in /?layout=light) does not work properly. Please note that this feature has been deprecated several years ago and is not intended for regular production use.
OWACalendar.Proxy healthset might start showing unhealthy once the mitigation is in effect. This can cause alerts if you use various monitoring solutions for your Exchange Server. If you see this problem, we recommend ignoring those alerts within your monitoring platform until the fix is out and mitigation is removed.
Published calendars might not work with error 500.
We are aware of the mitigation showing the "Mitigation invalid for this exchange version." in mitigation details. This issue is cosmetic and the mitigation DOES apply successfully if the status is shown as "Applied". We are investigating on how to address this.

Addressing the vulnerability permanently

Microsoft is working on and will release and announce a security update for impacted versions of Exchange Server in the future. Please read more about the update released: Released: June 2026 Exchange Server Security Updates | Microsoft Community Hub.

Please note that Exchange SE update will be released as a publicly available security update. Exchange 2016 and 2019 updates will be released only to customers who are enrolled in the Period 2 Exchange Server ESU program as per Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program. Period 1 only ESU customers will not receive this update as that ESU program ended in April 2026.

Updates to this blog post:

6/9/2026: Update to reflect Released: June 2026 Exchange Server Security Updates | Microsoft Community Hub
5/20/2026: Added a published calendars known issue.
5/18/2026: Added a note that mitigations do not protect Internet Explorer or Microsoft Edge with Internet Explorer mode clients.
5/17/2026: Added a known issue with OWACalendar.Proxy healthset showing unhelathy (impact if using Exchange Server monitoring).
5/14/2026: Added a known issue with OWA Light.
5/14/2026: Added the mitigation ID (M2.1.x).
5/14/2026: Added a known issue with mitigation details displaying incorrect Description.

The Exchange Server Team

Offboarding mailboxes fails with “PropTagToPropertyDefinitionConversionException.”

ba50992 — Tue, 12 May 2026 17:45:58 GMT

Hybrid M365 setup, just recently upgraded the on-prem server from Exchange 2019 to Exchange SE. After doing so, migrations from Exchange Online back to Exchange On-prem fail at 10% with the error “PropTagToPropertyDefinitionConversionException.”

I opened a case with M365 exchange support, and after some time, they came back to tell me that the Exchange Online portion of the process is not at fault, and that I have to engage the on-premise support team (this seems a little nuts to me, as its all connected and all supported, but I've been in this business for 30 years now, and it's not the first time I've seen buck-passing), and/or ask this community for help.

Hence, this post.

That error appears exactly two places on the internet, as far as I can tell: a blog (in German) from an Exchange expert doing cross-tenant migrations, and a page at

https://west.jcteams.info/bhit11/docs/EX1232513.html that seems to describe my exact issue. Neither had useful suggestions - mostly, they say this:

Set-MoveRequest -Identity "<UserPrincipalName>" -SkipMoving FolderRestrictions
Resume-MoveRequest -Identity "<UserPrincipalName>"

That didn't actually work, but when I tried the same parameters with Set-MigrationBatch, they worked as long as I ignored the message "The SkipMoving parameter is deprecated. Use the MoveOptions parameter instead. If you have any scripts that use the SkipMoving parameter, update them to use the MoveOptions parameter."

So what was a simple process is now a more cumbersome workaround. Does anyone have an idea on how to troubleshoot "PropTagToPropertyDefinitionConversionException?"

No Exchange Server Security Updates for May 2026

The_Exchange_Team — Thu, 14 May 2026 17:07:44 GMT

We wanted to let the Exchange Server community know that there are no security releases for any version of Exchange Server in May 2026, for customers with Exchange SE, or Exchange 2016 or 2019 ESU.

Please keep upgrading your organizations to Exchange SE.

Update 5/14/2026: While there is no security release (Security Update) in May 2026, please see our later blog post mentioning a mitigation for an Exchange Server CVE disclosed on May 14: Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub

The Exchange Team

About Command Return Values

daisuke1 — Mon, 11 May 2026 10:19:41 GMT

When I ran the following command in PowerShell, it used to return an `Object` type,

but recently it has started returning a `System.Collections.ArrayList` type.

Does anyone know why this is happening?

------------------------------------------------------------------

$dg = Get-DistributionGroup -Identity "Group Name"

$dg.AcceptMessagesOnlyFromSendersOrMembers.GetType().FullName

Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026

The_Exchange_Team — Fri, 08 May 2026 17:40:11 GMT

We are announcing the deprecation of Exchange ActiveSync (EAS) certificate-based authentication (CBA) directly to Exchange Online. By the end of 2026, Microsoft will no longer support direct CBA connections from EAS mobile email clients to Exchange Online. After that date, any EAS clients using CBA will need to authenticate via Microsoft Entra ID rather than sending client certificates directly to Exchange Online.

With immediate effect, we will roll out blocks so no new tenants can use the legacy flow, ensuring they can take advantage of the benefits of using the Entra ID flow from the very start.

Important: This change does not affect other Exchange Online authentication scenarios such as Outlook Mobile or Exchange Server/on-premises. It is specific to Exchange ActiveSync (EAS) clients (such as native built-in mobile email apps) using CBA against Exchange Online. This retirement is part of our ongoing efforts to strengthen security by eliminating legacy auth patterns in Exchange Online.

Why Are We Retiring Direct EAS CBA?

Certificate-based authentication for EAS was introduced as a way for organizations to allow mobile device access without passwords, using client certificates for a highly secure, passwordless sign-in experience. With CBA, each user has a certificate verified by the tenant's root certificate authority, and the user can authenticate via a TLS handshake using the public key of that certificate – meaning no private key or password is ever sent over the network, providing a more secure alternative to basic authentication. The previously published guidance for this config is here.

However, the current direct-to-Exchange implementation of EAS CBA is considered a legacy authentication method. In the present flow, user certificates are pushed to mobile devices during configuration. When users connect to EAS to sync email, Exchange receives the certificate and does all the onward processing and validation itself.

This design presents a significant concern as the client itself never obtains a standard OAuth access token – a departure from modern authentication practices – and Exchange relies on this internal, high-privilege mechanism to access data. Furthermore, Azure AD classifies direct certificate-based authentication between the client and Exchange Online as a form of "legacy authentication," meaning it will be blocked by any Azure AD conditional access policies that block legacy authentication. This creates an all-or-nothing challenge for administrators trying to enforce modern security controls while still allowing CBA.

The new model requires EAS clients to perform certificate-based authentication directly via Microsoft Entra ID, just as other client apps do. The proposed secure flow works as follows: the client sends its certificate to Entra ID (Azure AD) for validation; Entra ID validates the certificate and returns an OAuth access token to the client; the client then presents this OAuth token to Exchange Online for authentication. By moving certificate authentication fully into Microsoft Entra ID, admins can uniformly enforce modern security controls and policies for all client access, with no exceptions for certain protocols.

This change also continues our ongoing effort to modernize Exchange Online authentication stack. Over the past few years, we have phased out older authentication methods like Basic Auth, and we recently introduced dedicated ActiveSync CBA endpoints – such as outlook-cba.office365.com for worldwide multi-tenant, outlook-dod-cba.office365.us for DoD, and outlook-cba.office365.us for GCC-High – to support TLS 1.3 and strengthen security and reliability. Requiring Entra-based CBA is the next logical step in this journey, closing one of the last remaining gaps in legacy auth removal.

How do I know if I am Impacted?

If you aren’t sure if you use Exchange ActiveSync CBA or Entra-Based CBA, there’s a couple of ways you can figure that out.

Firstly, ask the person who manages your Mobile Device Management (MDM) configuration. If the auth type used is set as Certificate, rather than OAuth, that could indicate you use this configuration.

The other method is to check Entra’s sign-in event logs. Requests using Exchange CBA show up with the client app of ‘Exchange ActiveSync’, and Authentication Details will show a certificate is being used. Here’s how that flow looks in Entra’s sign-in logs reports:

"Certificate” would be shown as Authentication method:

We will send Message Center posts to tenants using Exchange CBA in the next week calling attention to this change. We’ll update this post once those posts have been sent.

Please note that CBA authentication is something that you must configure deliberately and if your organization never configured it, this deprecation does not impact you.

How to Migrate to Entra-Based CBA

We understand that some organizations have been relying on CBA with Exchange ActiveSync to enhance mobile device security. To ensure a smooth transition, we recommend administrators start planning now to move those devices to the new Entra ID-based CBA method well before the end-of-2026 deadline. The PKI and CA setup for Entra CBA and EAS CBA are fundamentally the same, which should simplify the transition. Below are key steps and considerations for a successful migration:

Enable Microsoft Entra CBA for your Tenant: Ensure your certificate authorities (CA) are configured in Microsoft Entra ID. At least one CA and any intermediate CAs must be configured, each user needs access to a certificate issued from a trusted PKI, and each CA should have a certificate revocation list (CRL) referenceable from an internet-facing URL. Microsoft provides detailed guidance on setting up Entra CBA in documentation.
Prepare User Certificates: Verify that each user's client certificate contains the correct identity information. For Exchange ActiveSync clients specifically, the certificate must include the user's routable email address in Exchange Online, in either the Principal Name or the RFC822 Name value of the Subject Alternative Name (SAN) field. Microsoft Entra ID maps the RFC822 value to the Proxy Address attribute in the directory. More info here. If your current certificates were used for direct EAS CBA, they likely already meet this requirement – just verify the presence of the user's email in the certificate's SAN.
Update Device Configuration: Plan how your mobile devices will perform certificate authentication against Entra ID. In many cases, this may involve updating the device's email profile or MDM/Intune device configuration profiles. The new flow might require collaboration with third-party client vendors to support the change. Consult your mobile device or mail app vendor for specific instructions on enabling Entra (Azure AD) authentication with client certificates. When the feature is configured, users will see a certificate selection prompt during sign-in rather than entering a password.
Test and Monitor: We recommend testing the new Entra CBA login flow with a pilot group of devices and users before broad rollout. Monitor your Entra ID sign-in logs and Exchange ActiveSync device reports to identify any remaining devices using the legacy CBA method. Proactively reach out to users still on the old method and assist them in moving to the updated configuration.
Deprecation Timeline: Keep the end-of-2026 deadline in mind for planning. We suggest completing the transition well in advance of this date to avoid any service disruption. In the interim, we will share more details through the Message Center to directly impacted tenants, and update documentation as needed to support your migration.

Conclusion

We strongly encourage any customer still using direct Exchange ActiveSync CBA to begin planning the move to Entra-based CBA now. The Microsoft Entra method offers equal or better security – it's certificate-based, phishing-resistant, and passwordless, but with far better integration into our modern authentication ecosystem and security controls. This change will help protect your organization's data by ensuring all Exchange Online connections follow the most up-to-date security standards, and it eliminates the reliance on internal high-privilege tokens that carry unnecessary elevated rights.

We understand that making changes to your authentication infrastructure can be challenging, which is why we've set a long runway until the end of 2026 for this transition. We'll continue to provide guidance and support throughout this period. Thank you for your cooperation in adopting these security improvements – together, we can ensure a safer, more secure Exchange Online experience for all our customers. If you have any questions or need assistance with setting up Entra CBA, please reach out to Microsoft Support (Entra / Identity) or your account team. We're here to help make this transition as smooth as possible.

The Exchange Online Team

General Availability of Mailbox Import and Export Microsoft Graph APIs

Nino_Bilic — Fri, 08 May 2026 14:21:17 GMT

As a part of our continuing march to Exchange Web Service (EWS) deprecation in Exchange Online (see Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub) - the Microsoft Graph Team announced another milestone in enabling developers to efficiently manage, migrate, and integrate mailbox data in Exchange Online through Microsoft Graph:

Announcing general availability of the mailbox import and export Microsoft Graph APIs - Microsoft 365 Developer Blog

If you develop applications that access mailbox data, you might be very interested in that. Please see the post for more details on current scope and production expectations.

Nino Bilic

Update Your Exchange SE Hybrid On-premises Rich Coexistence to Graph

The_Exchange_Team — Fri, 08 May 2026 14:36:18 GMT

About a year ago, we announced Exchange Server Security Changes for Hybrid Deployments. This change impacted Exchange hybrid customers who host some of their mailboxes on-premises and their on-premises users need access to “rich coexistence” features (Free/Busy lookups, MailTips and profile picture sharing with Exchange Online users).

This change was planned in two stages:

Stage 1: transitioning to dedicated Exchange hybrid application. Completed in October 2025. Exchange hybrid customers who host mailboxes on-premises now must create the dedicated Exchange hybrid application to maintain rich coexistence features for their on-premises users.
Stage 2: deprecation of EWS calls and switch to REST-based Microsoft Graph API calls for Exchange hybrid. This is the stage that we are in now. Please note that not all rich coexistence scenarios are fully supported yet and not every cloud environment might support Graph API hybrid calls yet (please see documentation).

Deprecation of Exchange Web Services (EWS) in Exchange Online is nearing final stages – see Exchange Online EWS, Your Time is Almost Up. Because of this, all customers who require rich coexistence (even those who already finalized Stage 1) will need to install an Exchange Subscription Edition (SE) update on premises and switch the dedicated Exchange hybrid app permissions to a more granular Graph API permission model. This must be done before October 2026 (as we will turn off EWS by default then) with the latest date of April 2027 (when we will permanently turn off EWS in Exchange Online).

The following illustration shows the timeline of hybrid security improvements, Stage 2:

Exchange Hybrid customers who want to start using Graph API in hybrid workflow should:

Step 1 – install the May 2026 Hotfix Update for Exchange SE (or newer) on your on-premises Exchange SE servers:

Released: May 2026 Exchange Server Hotfix Update

Step 2 – once all your on-premises Exchange SE servers have the update installed, follow the steps as outlined in the documentation to enable the Graph API hybrid workflow for supported scenarios. Note that if you ran the script in the past, you need to re-run it again after installing the new update to activate new functionality.

Note: Exchange 2016 and 2019 are out of support. We are not releasing an update for those versions to use Graph API hybrid calls (even updates released under Exchange 2016 or 2019 ESU will not contain this functionality). Customers who are still using Exchange 2016 or 2019 servers to host mailboxes on premises will have to keep allowing EWS use in their tenant past October 2026 and must upgrade all servers to Exchange SE by April 2027 (when EWS is disabled in Exchange Online). Rich coexistence features on those unsupported versions will permanently stop working in April 2027. Please upgrade your on-premises environments from unsupported versions ASAP. By running unsupported versions, you might be putting your environment at risk!

The FAQ related to creation and use of dedicated hybrid app can be found in feature documentation.

Updates to this post:

5/8/2026: Clarified that the script needs to be re-run to enable new functionality (Step 2 above) even if it was ran in the past already.

The Exchange Team

Released: May 2026 Exchange Server Hotfix Update

The_Exchange_Team — Fri, 08 May 2026 20:31:09 GMT

Microsoft has released Hotfix Update (HU) for:

Exchange Server Subscription Edition (SE)

HU is available for the following specific version of Exchange Server:

Exchange SE RTM

The May 2026 HU does not contain any new Exchange Server security updates but contains new functionality. Please see the release KB article for more information.

Updating your Exchange rich hybrid coexistence to Graph API calls

May 2026 hotfix update contains functionality that will allow you to start switching your Exchange Server hybrid rich coexistence from using Exchange Web Services (EWS) to REST-based Microsoft Graph API calls. This is a continuation of work we announced in Exchange Server Security Changes for Hybrid Deployments.

More information can be found in Update Your Exchange SE Hybrid On-premises Rich Coexistence to Graph and Deploy dedicated Exchange hybrid app.

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 Fix failed Exchange Server updates. Also please see File version error when you try to install Exchange Server updates.

Hotfix Update FAQs

Why did Microsoft decide to release this HU at the start of the month? Is this urgent?
Hotfix releases are not tied to the “patch Tuesday” release schedule as they do not contain security updates. Exchange Hotfix Updates are optional.

We installed the last Security Update. Should we install the later Hotfix Update?
Exchange Server HUs are optional updates, but they might introduce features or fixes that your organization can benefit from. Please see the release KB article for more details.

We did not yet install the earlier Security Update. Do we have to install the last available SU first before installing the later HU?
All of Exchange updates (HUs or SUs) are cumulative. Therefore, a newer SU or HU will contain all the changes that a previous, older SU or HU has. If you have not installed the older updates yet, you can install the newer one directly and skip the older one.

Our Exchange servers update automatically through Windows / Microsoft Update. Will our servers automatically install the HU update?
This HU is an optional update for your servers and the update will be shown as an optional update on Windows / Microsoft update a few days after general release on Download Center.

Will the new features and fixes released in the HU also be rolled into future updates, or must we install this specific HU to get them?
Content of this HU will be included in subsequent updates for Exchange Server SE.

Can HUs be uninstalled (if the need arises)?
Yes. HUs, like SUs, can be uninstalled.

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

Updates to this post:

5/8/2026: Updated the FAQ related to Windows / Microsoft Update availability

The Exchange Server Team

Exchange on-prem license

Filip77 — Mon, 04 May 2026 09:07:31 GMT

Hello,

I have installed ExchangeServerSE x64 iso file its in trial version i want to license it.

What kind of license do i need?

I have the following information from the EAC:

Version 15.2 ‎(Build 2562.17)‎

Standard Trial Edition

Trial

and from powershell:

Edition : StandardEvaluation

AdminDisplayVersion : Version 15.2 (Build 2562.17)

Since i've installed the ExchangeServerSE x64 is this the correct license i should require?

Exchange Server Subscription Edition (SE) license

5 × Exchange Server Standard CALs (one per user/mailbox)

Environment details:

Exchange version: 2019 (Version 15.2)

Number of mailboxes: 5

Is this valid and the correct license?

Kind regards,

Filip M

Exchange2019-KB5074993

mkanaan — Sun, 03 May 2026 07:22:54 GMT

I need the download link for Exchange2019-KB5074993-x64-en.exe.