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-premis...
Updated Aug 31, 2026
Version 6.0
Blog Post
How can we verify after running the script to switch from EWS to Graph API that the hybrid connection is actually using Graph API to connect instead of EWS - other than removing the EWS permissions via the script and testing to verify cross-premise functionality still works?
BTW here (https://learn.microsoft.com/en-us/Exchange/hybrid-deployment/deploy-dedicated-hybrid-app#enable-graph-api-based-hybrid-flow) there is a section for verifying the configuration using Test-OAuthConnectivity but that script is using EWS as the Service parameter and Graph does not seem to be a valid value for the Service parameter. When I run this script currently, it shows Success but appID not found. We have had the dedicated hybrid app in place for over a year and the cross-premise functionality works. We have not switched to Graph API yet. So not sure why it shows appID not found though the functionality works. Any ideas on that?
You can check the sign-in logs for the application in Entra. Go to Enterprise apps, search for ExchangeServerApp, then select what's returned. Click Sign-in logs, then switch to the Service principal sign-ins tab. When it's using EWS, the "Resource" shows "Office 365 Exchange Online". When it's using Graph, "Resource" will show "Microsoft Graph".
That being said, I'm testing this in our lab environment, and after switching to Graph, free/busy no longer works. After hours of digging and arguing with Copilot, I found a way to disable the setting override (as opposed to deleting it), and now free/busy works again. About to open a support case ...
Get-SettingOverride -Identity "EnableRouteThroughMSGraphFeature" | Set-SettingOverride -Parameters "Enabled=false" -Confirm:$false
