Blog Post

Exchange Team Blog
6 MIN READ

Exchange Server Security Changes for Hybrid Deployments

The_Exchange_Team's avatar
The_Exchange_Team
Platinum Contributor
Apr 18, 2025

As a part of Microsoft's Secure Future Initiative (SFI), security remains our top priority. In alignment with SFI, Exchange Server is implementing several changes to enhance the security of Exchange Server hybrid deployments. This blog post outlines the current and upcoming changes that apply specifically to Exchange Server hybrid deployments. If your organization does not have any form of Exchange hybrid configured, this post does not apply to you.

Change 1: Transitioning to a dedicated Exchange hybrid application

To enable Exchange hybrid deployment features such as calendar Free/Busy, MailTips, and user profile picture sharing (we call this “rich coexistence”), Exchange Server currently uses a shared service principal with the same application as Exchange Online. The name of this application is Office 365 Exchange Online, and it has the application ID 00000002-0000-0ff1-ce00-000000000000. This configuration is put in place by initial run of Hybrid Configuration Wizard (HCW) and is used to authenticate and secure the communication between Exchange Server and Exchange Online.

Beginning with the April 2025 HU release, Exchange Server is starting the transition to using a dedicated Exchange hybrid application in your tenant’s Entra ID. By October 2025, all current and new Exchange Server hybrid deployments that require rich coexistence features must move to using the dedicated Exchange hybrid app, as Exchange Online service will no longer allow the use of shared service principals beyond that date.

There are changes that administrators will need to make to enable and use the dedicated Exchange hybrid app. Please refer to the documentation for more information.

Change 2: Deprecation of EWS calls and switch to REST-based Microsoft Graph API calls for Exchange hybrid

The retirement of Exchange Web Services (EWS) in Exchange Online is coming. To maintain Exchange hybrid features, Exchange Server will (later this year) start supporting Microsoft Graph API as a replacement for EWS calls from Exchange Server to Exchange Online. This feature will release through an update for Exchange Server 2019 and Exchange Server 2016 in Q3 2025. In line with the transition to Microsoft Graph, the API permissions of the dedicated Exchange hybrid application will be revised to utilize more granular Graph API permissions. A blog post and documentation containing additional information will be published once that release is available.

Important: Microsoft Graph for Exchange Server hybrid requires the dedicated Exchange hybrid app (see Change 1 above) and will not use the current shared service principal approach. This change doesn’t affect the EWS API availability in Exchange Server (on-premises) and will only replace EWS calls from Exchange Server to Exchange Online with REST-based Microsoft Graph API calls.

Who needs to take action, and when?

If your organization uses the following Exchange hybrid functionality…

The action you should take is…

Customers who require rich coexistence between users with on-premises mailboxes and users who have Exchange Online mailboxes (specific features: Free/Busy lookups, MailTips and profile picture sharing).

You MUST take the steps outlined in the documentation and switch to using the dedicated hybrid app (before October 2025) and then switch your hybrid to using Graph API (when available but before October 2026), or else rich coexistence features will break.

After all servers are updated and are using the dedicated app, run “Service Principal Clean-Up Mode”.

Customers using any other hybrid features only (migrations, SMTP relay, recipient management etc.) – but no rich coexistence required

To help harden your hybrid configuration, we recommend that you use the provided script, to remove the organization certificate from the shared “Office 365 Exchange Online” application. See “Service Principal Clean-Up Mode” in the documentation.

You do not need to create the dedicated hybrid app if you don’t need rich coexistence features.

Exchange Hybrid customers who require rich coexistence must act

Step 1 – Switching your Exchange hybrid from using the shared service principal to using the dedicated Exchange hybrid app, before October 2025. This change can be done in two different ways:

  • Option 1 (recommended): configure the dedicated Exchange hybrid app by installing April 2025 HU (or later) and running the ConfigureExchangeHybridApplication.ps1 script to switch Exchange hybrid from current “shared principal” configuration to using the dedicated Exchange hybrid app. Please see documentation.
  • Option 2: we released an updated version of the Hybrid Configuration Wizard (HCW). Re-run HCW to configure the dedicated Exchange hybrid app. Please note that the script (Option 1) remains a more robust solution for working with the new hybrid app.

Step 2 – Changing Exchange hybrid to use Graph API calls and updating dedicated app permissions to a more granular Graph permission model, before October 2026:

  • In Q3 2025, when Graph API update for Exchange Server is made available, all customers who require rich coexistence (even those who already performed the above Step 1) will need to install an Exchange 2016/2019 update and switch the dedicated Exchange hybrid app permissions to a more granular Graph API permission model. This must be done before October 2026. Documentation will be provided at release.

The following illustration shows what will be needed for organizations that use rich hybrid coexistence and when, related to Changes 1 and 2 mentioned above:

Exchange hybrid customers who require rich coexistence with Exchange Online must act between April 2025 HU release and October 2025. Unless you follow the steps to update to dedicated Exchange hybrid app (before October 2025) and then update it to Graph permission model (before October 2026), some Exchange hybrid functionality will break (Free/Busy sharing between on-premises and Exchange Online users, MailTips, profile picture sharing).

We strongly recommend that other Exchange hybrid customers do the following

Even if rich coexistence features are not in use, if the organization ever ran and completed the Exchange Hybrid Configuration Wizard (HCW) or followed the steps outlined in the Configure OAuth authentication between Exchange and Exchange Online organizations documentation – the organization certificate was uploaded to the shared service principal as a part of the HCW run.

To help harden your hybrid configuration, we strongly recommend that you use the provided script, to remove the organization certificate from the shared “Office 365 Exchange Online” application. See “Service Principal Clean-Up Mode” in the documentation.

You do not need to create the dedicated hybrid app if you don’t need rich coexistence features. Running of the script does not depend on a specific version of Exchange to be installed on-premises (you can run the script independently from installing Exchange Server updates on premises).

An overview of the process

We created the following flowchart that should help you visualize the steps that are needed to switch to the dedicated Exchange hybrid app:

Notes for steps marked on the flowchart:

  1. Configure OAuth authentication between Exchange and Exchange Online organizations.
  2. ‘Rich coexistence’ enables Free/Busy lookups, MailTips, and user profile picture sharing between Exchange on-premises and Exchange Online mailboxes.
  3. Setting the setting override as a separate step needs to be done only if the dedicated hybrid app was created using HCW or you used the script in the Split Execution Configuration mode.

Frequently Asked Questions

The Frequently Asked Questions (FAQ) on this subject have now been moved to feature documentation.

Major changes to this blog post:

  • 8/11/2025: Added a flowchart with the overview of the process
  • 8/7/2025: Added direct links to the ConfigureExchangeHybridApplication.ps1 script in the blog post
  • 8/6/2025: Hybrid Configuration Wizard (HCW) is now updated to support creation of dedicated Exchange hybrid app; relevant updates done
  • 8/4/2025: We moved the FAQ on the subject to feature documentation
  • 7/31/2025: Clarified the recommendation for customers who do not use "rich coexistence" features
  • 5/16/2025: Added a FAQ about multi-forest on-premises configuration
  • 4/24/2025: Added a FAQ about renaming of the dedicated hybrid app
  • 4/22/2025: Added a FAQ about no requirement to install April HU to clean up security principal only using the script

The Exchange Team

Updated Aug 11, 2025
Version 11.0

79 Comments

  • John Krick's avatar
    John Krick
    Copper Contributor

    We currently have Exchange 2019 with the April HU installed, but HMA is not enabled. I saw the comment above that indicates creating the dedicated hybrid app has no impact on HMA. Can we enable HMA at a later date after the dedicated hybrid app is created? I suspect HMA is not a prerequisite for the dedicated hybrid app, or it would have been stated above. Also, has Microsoft set an enforcement date for HMA on-premises?

  • SteveTH's avatar
    SteveTH
    Brass Contributor

    Hi The_Exchange_Team​ 
    What to consider if we have a 'Hybrid deployments with multiple forests' scenario. Can you make another FAQ entry here! Can we run the script per forest? What about deleting the old app? Please provide information about this scenario.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      Added the FAQ about this now. You should run the script once per on-premises organization which will create multiple hybrid apps in the tenant.

      Note that there is no "deleting the old app". Rather - you can delete the certificate from the old app only, and this should not be done until all forests are ready to work with their respective dedicated hybrid apps.

  • AAChicago's avatar
    AAChicago
    Copper Contributor

    The table above for "Customers who require rich coexistence" mentions between "users with on-premises mailboxes" and "users who have Exchange Online mailboxes", but what about using MailTips on on-prem DLs that are synced to EXO (all our users have mailboxes in EXO)? Does that qualify as rich co-existence if the MailTip is on an on-prem DL instead of an on-prem mailbox?

  • Googol's avatar
    Googol
    Brass Contributor

    how can you verify if there is a certificate uploaded? we never setup oauth both ways, as we migrated everything and dont need rich coexistance, not sure if certificate was ever uploaded. is there a way?

  • Rob_R's avatar
    Rob_R
    Brass Contributor

    I've recently run the HCW and received an error related to OAuth. I had GA permission assigned to the account at the time the HCW was run. I've been manually validating OAuth authentication per this MS document: https://learn.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help?redirectedfrom=MSDN

    The test run from on-prem is successful (after having to manually enable the Intra-org connectors) but I'm receiving the following error when testing from Exchange Online: "A server side error has occurred because of which the operation could not be completed. Please try again after some time. If the problem still persists, please reach out to MS support". I've run the test multiple times over the past couple of days with the same error. I had just renewed the auth certificate in January and receive a message indicating that the current cert is valid when running the upload cert script provided in the article. 

    I'm curious if anyone else is having this same issue and if it might be expected behavior or an unintended consequence of the EWS deprecation efforts. I've opened a support case.

    UPDATE: I ran the Test-OAuthConnectivity cmdlet again this morning and received this message: Test-OAuthConnectivity: The cmdlet has been disabled due to internal failure. Please email to us at email address removed for privacy reasons or contact Microsoft Support to report this issue.

    I guess its a good thing that I already have a support case open...

    • ykhan152's avatar
      ykhan152
      Copper Contributor

      I'm also getting this same error. Test-OAuthConnectivity cmdlet doesnt seem to work with Exchange Online Module.

  • Before 2025 Oct. if customer create the dedicate exchange hybrid app in entra, how could they confirm the feature works as expected? 

  • DavidH38's avatar
    DavidH38
    Copper Contributor

    so trying to run the script from and exchange 2019 CU15 with Hotfix on and get the following error

    Start-Process : This command cannot be run due to the error: Class not registered.
    At C:\ExDev2019Build\ConfigureExchangeHybridApplication.ps1:1364 char:9
    +         Start-Process -FilePath $authCodeRequestUrl

    And there is nothing in the log to help using .\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication 

    am i missing somthing the server is also in full hybrid

    • LukasSMSFT's avatar
      LukasSMSFT
      Icon for Microsoft rankMicrosoft

      DavidH38 it looks like you've tried running the script in all-in-one configuration mode on Windows Server Core. Can you confirm that? If so, running the script in this mode on Server Core doesn't work. Instead, you need to run in in split-execution mode (https://learn.microsoft.com/en-us/Exchange/hybrid-deployment/deploy-dedicated-hybrid-app#split-execution-configuration-mode).

      The steps are as follows (the documentation explains them with more context and examples):

      1. Export the public key of the auth certificate
      2. Run the script on a Windows Client or Server with GUI to create the application and upload the certificate
      3. Run the script on Windows Server Core to enable the feature
      • DavidH38's avatar
        DavidH38
        Copper Contributor

        Yes i'm running server core as MS Best practice, thats means your recomended way is wrong as most people would of deployed on core

  • Is it supported for admins to rename the enterprise app created so they can follow the enterprise naming convention?

    "ExchangeServerApp-XXXXXXXXXXXXX" is not very explicit...

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      During the CreateApplication part of the run, the dedicated app will be created and it will be called:

      ExchangeServerApp-{Guid of the organization}

      So each organization's app will have a unique name because of the organization GUID will be unique to your organization. Specific place in the doc that mentions this: Deploy dedicated Exchange hybrid app | Microsoft Learn