In a significant shift for hybrid Exchange environments, Microsoft has announced that, starting October 2025, it will discontinue support for the shared application used to access free/busy calendar information: https://techcommunity.microsoft.com/blog/exchange/exchange-server-security-changes-for-hybrid-deployments/4396833
Organizations that use hybrid configurations between on-premises Exchange and Exchange Online must now deploy a dedicated application to maintain this functionality.
Microsoft provides the ConfigureExchangeHybridApplication.ps1 script, which you can run in two ways: either as a one-step process from an Exchange server with internet access, or in multiple steps using different accounts. The split approach offers more control and helps you better understand each phase of the configuration
This article provides a comprehensive step-by-step guide to help you configure the new dedicated Exchange hybrid app with the split approach . Additionally, it explores the potential security implications associated with this change, helping you understand the risks.
Export Exchange Auth certificate
Start by exporting the Auth certificate from one of your on-premises Exchange Mailbox servers. This certificate plays a key role in establishing trust between your on-premises and cloud environments. You can export it using the graphical interface in MMC or by running the PowerShell script provided by Microsoft (included just below).
If you choose to use Microsoft’s script, make sure to run it within an Exchange Management Shell. This is crucial because the script relies on the Get-AuthConfig cmdlet, which is only available in the Exchange PowerShell environment with the right admin permissions .
# Change the path if you want to export the certificates to a different location
$exportFilePath = "C:\AuthCertExport"
$authConfig = Get-AuthConfig
New-Item -Type Directory -Path C:\AuthCertExport -Force | Out-Null
if (-not([System.String]::IsNullOrEmpty($authConfig.CurrentCertificateThumbprint))) {
$thumbprint = $authConfig.CurrentCertificateThumbprint
Write-Host "[+] Auth Certificate thumbprint: $thumbprint"
try {
$currentAuthCertificate = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
Export-Certificate -Cert $currentAuthCertificate -FilePath "$exportFilePath\$thumbprint.cer" -Type CERT | Out-Null
Write-Host "[+] Certificate was successfully exported to: $exportFilePath"
} catch {
Write-Host "[+] We hit the following exception: $_" -ForegroundColor Red
}
}
if (-not([System.String]::IsNullOrEmpty($authConfig.NextCertificateThumbprint))) {
$thumbprint = $authConfig.NextCertificateThumbprint
Write-Host "[+] Next Auth Certificate thumbprint: $thumbprint"
try {
$currentAuthCertificate = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
Export-Certificate -Cert $currentAuthCertificate -FilePath "$exportFilePath\$thumbprint.cer" -Type CERT | Out-Null
Write-Host "[+] Certificate was successfully exported to: $exportFilePath"
} catch {
Write-Host "[+] We hit the following exception: $_" -ForegroundColor Red
}
}
The result of this operation will be a .CER file containing the Exchange Auth certificate — specifically, the public key portion.
Creation of a new dedicated Exchange app
You will use Microsoft’s ConfigureExchangeHybridApplication.ps1 script (https://microsoft.github.io/CSS-Exchange/Hybrid/ConfigureExchangeHybridApplication) to create the application dedicated to hybrid deployment in your tenant. The only required parameter is the certificate that was exported in the previous step. This certificate will be configured within the registered application. This action requires a Microsoft 365 tenant admin account to create the application and approve the application-level permission consent.
.\ConfigureExchangeHybridApplication.ps1 -CreateApplication -UpdateCertificate -CertificateMethod "File" -CertificateInformation "C:\LTR\Hybridation\CF2F1AB8818554377CD56C6F2CC49976DA9BB76C.cer"
The script will provide you the application’s ID (Client ID).
You can find the application that the script created under the “App Registrations” section in the Entra (Identity) admin portal. There, you can also locate the Client ID and review the application’s properties.
The application uses the Auth certificate as its credential.
It is granted the full_access_as_app application permission, which provides EWS full access to all mailboxes in the tenant. This aspect will be addressed at the end of this article in the security-related note.
Configuration of Exchange on-premises
Now that the application exists in your Microsoft 365 tenant, you need to configure your on-premises servers to use it. Run the same Microsoft script (ConfigureExchangeHybridApplication.ps1) from an Exchange PowerShell session. Provide the following parameters: your Tenant ID, the application’s Client ID, and the domain name used as the external address on your remote mailboxes (usually <tenant>.mail.onmicrosoft.com). You need to use an Exchange on-premises admin account to update the OAuth2 configuration. Run these actions from an Exchange PowerShell session connected to backend Exchange servers (DAG members).
.\ConfigureExchangeHybridApplication.ps1 -ConfigureAuthServer -EnableExchangeHybridApplicationOverride -CustomAppId <your_app_clientid> -TenantId <your_tenantid> -RemoteRoutingDomain <tenant>.mail.onmicrosoft.com -ConfigureTargetSharingEpr
Note: A “RemoteRoutingDomain” is a remote domain with TargetDeliveryDomain property equal $true.
Next, to verify that all is well, you can check the ApplicationIdentifier of the AuthServer object:
Free/busy tests and log checks
Now you can verify that free/busy from on-premises to online works correctly.
You can check the application’s sign-ins logs to confirm that it connects and accesses the “Office 365 Exchange Online” service. This is one of the key benefits of using a dedicated, manageable application within your tenant.
Retirement of the Legacy System
You can remove the old configuration that used a shared application by running the following command: .\ConfigureExchangeHybridApplication.ps1 -ResetFirstPartyServicePrincipalKeyCredentials. This step helps clean up legacy settings and ensures that only the new dedicated application remains active.
Security warnings and risks
When configuring the new hybrid application, it’s important to evaluate the security implications. Previously, Exchange relied on a shared multi-tenant application, which limited the ability to apply tenant-specific Conditional Access policies. With the new dedicated and manageable application, administrators can now assign Conditional Access rules tailored to their environment.. It’s a progress.
However, this new setup introduces a significant consideration: the application requires the full_access_as_app permission. This level of access allows the application to open any mailbox in the tenant—not just retrieve free/busy information. If someone within the organization gains access to the Auth certificate and its private key (which remains exportable in PFX format from Exchange servers), they could potentially use it to authenticate and access all mailboxes data via EWS.
Additionally, if that person requests a token without Continuous Access Evaluation (CAE)—a scenario that my free tool token365.exe can simulate—they could generate a token that bypasses Conditional Access policies and use it outside the organization.
So, before implementing this new free/busy integration via EWS, consider whether it’s worth deploying now or waiting for the upcoming Graph-based version, which will likely use an application with more limited permissions. If your organization still hosts a significant number of on-premises user mailboxes, you may need to proceed with the current solution. In that case, make sure to secure the new APP as much as possible: apply Conditional Access policies (using workloads id licensing) and enforce CAE to reduce the risk of token exfiltration.
Balancing functionality and security remains a key challenge in this transition.
By Lionel TRAVERSE
Microsoft 365 Certified Administrator Expert / Microsoft Certified Trainer