Hybrid free/busy not working: OAuth, the dedicated hybrid app and Test-OAuthConnectivity

Hybrid free/busy fails in one direction far more often than in both, and the fix depends entirely on which hop broke: DNS, the firewall, the OAuth trust, a connector, or the recipient object itself. Since late 2025 there is also a new moving part, the dedicated Exchange hybrid application, and since October 2026 the EWS retirement in Exchange Online adds another. In this post I'll lay out how the lookup flows, where it usually breaks, and a test sequence that pins the failure to a single component.

Symptoms#

• Scheduling Assistant shows hash marks ("No information") for the other side's users; Outlook on the web gives an error code when you hover: 5039 (attendee's server couldn't be found), 5016 (couldn't be contacted) or 5037 (no permission to see free/busy).
• Opening a shared calendar across premises fails with "Could not update", and MailTips for cross-premises recipients disappear.
• It works for on-premises users looking at other on-premises users, and for cloud users looking at cloud users, but not across the boundary, often in only one direction.

Why it happens#

Each direction is a separate lookup. When a cloud user asks for an on-premises person's availability, Exchange Online finds the synced mail user, reads its target address (your on-premises SMTP domain), matches that domain to a connector or relationship, sends an Autodiscover request to your external Autodiscover URL, and then calls EWS on your server. When an on-premises user asks about a cloud mailbox, Exchange Server reads the remote mailbox's remote routing address (in tenant.mail.onmicrosoft.com), matches it to its own connector or relationship, authenticates to Exchange Online and queries it. With OAuth, the modern method, the Hybrid Configuration Wizard (HCW) creates an IntraOrganizationConnector on each side; with DAuth, the older federation-based method, it creates Organization Relationships. Microsoft recommends OAuth and notes that DAuth with Exchange Online stops working once EWS is retired.

The usual breakpoints are:

• Autodiscover and EWS reachability: external DNS not pointing at the hybrid server, a firewall or reverse proxy doing pre-authentication, no ExternalUrl on the EWS virtual directory, or (for DAuth) WSSecurity not enabled.
• The OAuth trust: an expired or rotated Exchange Auth Certificate that was never uploaded to the cloud, TLS 1.2 misconfiguration, server time more than five minutes off, or an outbound proxy the server doesn't know about (InternetWebProxy).
• The dedicated Exchange hybrid app: since 31 October 2025, EWS calls through the old shared service principal are permanently blocked. Free/busy, MailTips and photos only work from servers on a supported build (Exchange SE, or 2019 CU14/CU15 and 2016 CU23 with the April 2025 hotfix) with the dedicated application configured and enabled by setting override.
• Connector or relationship settings: IntraOrganizationConnector disabled or missing a domain in TargetAddressDomains; Organization Relationship missing your vanity domain in DomainNames, FreeBusyAccessEnabled False or an access level that hides details.
• Recipient objects: a remote mailbox with the wrong RemoteRoutingAddress, or a cloud mail user with the wrong ExternalEmailAddress, sends the lookup to the wrong place. Calendar folder permissions below "Free/Busy time" for Default also return nothing.
• EWS retirement: from October 2026 the on-premises servers' EWS calls to Exchange Online need the tenant's EwsEnabled set to True and the dedicated hybrid app's ID in EwsAllowedAppIDs, unless you have moved Exchange SE (May 2026 hotfix or later) to the Graph-based flow.

How to fix it#

1. Establish direction and scope. Test on-premises to on-premises and cloud to cloud first; if either fails, you don't have a hybrid problem yet. Then test both cross-premises directions with two known-good users, in Outlook on the web to rule out client caching, and note the error code.
2. Run the ready-made checks. The Free/Busy test in the Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) exercises Autodiscover and EWS from outside. Microsoft's FreeBusyChecker.ps1 from the CSS-Exchange repository compares your OAuth and DAuth configuration on both sides against the expected defaults.
3. Check the cloud side.
   PowerShell

   Connect-ExchangeOnline
   Get-IntraOrganizationConnector | Format-List Name, Enabled, TargetAddressDomains, DiscoveryEndpoint, TargetSharingEpr
   Get-OrganizationRelationship | Format-List Name, Enabled, DomainNames, FreeBusyAccessEnabled, FreeBusyAccessLevel,
       TargetAutodiscoverEpr, TargetSharingEpr
   Get-MailUser -Identity onprem.user@contoso.com | Format-List ExternalEmailAddress

   The connector should be enabled with your on-premises SMTP domains and your external Autodiscover URL. A missing domain is fixed with Set-OrganizationRelationship -Identity "<name>" -DomainNames contoso.com (the parameter sets the whole list, so include every domain) or with Set-IntraOrganizationConnector -TargetAddressDomains on the connector; FreeBusyAccessLevel is normally LimitedDetails.
4. Check the on-premises side. In the Exchange Management Shell:
   PowerShell

   Get-IntraOrganizationConnector | Format-List Name, Enabled, TargetAddressDomains, DiscoveryEndpoint
   Get-OrganizationRelationship | Format-List Name, Enabled, DomainNames, FreeBusyAccessEnabled, TargetAutodiscoverEpr
   Get-WebServicesVirtualDirectory | Format-List Name, Server, ExternalUrl, ExternalAuthenticationMethods
   Get-RemoteMailbox -Identity cloud.user | Format-List RemoteRoutingAddress
   Get-AuthConfig | Format-List CurrentCertificateThumbprint, NextCertificateThumbprint
   Get-AuthServer | Format-List Name, Realm, Enabled, ApplicationIdentifier
   Get-ExchangeServer | Format-List Name, InternetWebProxy

   The remote routing address must be in tenant.mail.onmicrosoft.com; the EWS ExternalUrl must be set and reachable; the Auth Certificate must be valid (check its expiry with Get-ExchangeCertificate); and after the dedicated app is configured, the EvoSTS auth server's ApplicationIdentifier should be the app's ID rather than empty.
5. Prove the OAuth trust. Microsoft's documented verification is to run, on an on-premises server:
   PowerShell

   $result = Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com -Mailbox onprem.user@contoso.com
   $result.ResultType
   $result.Detail

   ResultType should be Success, and the detail should contain the app ID of your dedicated hybrid application. A 401 here points at the certificate, the app configuration or an unsupported build; a transport error points at TLS or the proxy. You can test the other direction from Exchange Online PowerShell with Test-OAuthConnectivity -Service EWS -TargetUri https://mail.contoso.com/ews/exchange.asmx -Mailbox cloud.user@contoso.com.
6. Fix what the tests exposed. Renewed or replaced the Auth Certificate? Upload it with .\ConfigureExchangeHybridApplication.ps1 -UpdateCertificate. Never configured the dedicated app? Run the script with -FullyConfigureExchangeHybridApplication (or finish the HCW path with the documented New-SettingOverride), then allow up to 60 minutes. Disabled connector or wrong domain list? Correct it with Set-IntraOrganizationConnector. Missing ExternalUrl? Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)" -ExternalUrl https://mail.contoso.com/ews/exchange.asmx. Firewall pre-authentication must be bypassed for /autodiscover/autodiscover.svc and /ews/exchange.asmx. If you re-ran HCW with the OAuth option after setting up the dedicated app, run the script's service principal clean-up again.
7. Account for the EWS retirement. If any on-premises server still uses the EWS flow (all 2016/2019 servers do, and Exchange SE does until you enable the Graph flow), confirm Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs shows True and the hybrid app's ID. On Exchange SE with the May 2026 hotfix, re-run the configuration script to add Graph permissions and enable the Graph-based flow; keep the EWS permission if you still rely on scenarios Graph doesn't cover yet, such as on-premises mailboxes with cloud archives.

Verify the fix#

• Repeat the Scheduling Assistant test in both directions with the same two users; hash marks should turn into real availability.
• Test-OAuthConnectivity returns Success from both sides, and the Remote Connectivity Analyzer Free/Busy test passes.
• In the Microsoft Entra admin center, Sign-in logs › Service principal sign-ins shows successful sign-ins for the dedicated hybrid application when on-premises users query cloud calendars.
• On the hybrid server, the IIS logs contain Autodiscover and EWS requests from Exchange Online for the cloud-to-on-premises direction.

Prevent it next time#

• Monitor the Auth Certificate expiry (Microsoft's MonitorExchangeAuthCertificate script does this) and treat uploading the renewed certificate to the dedicated app as part of the renewal runbook.
• Keep every hybrid server on a supported build; one old server in the pool produces intermittent failures that are hard to reproduce.
• Record the expected values of your connectors and relationships so a drift (someone disabling a connector "temporarily") is obvious.
• Plan the move to the Graph-based hybrid flow on Exchange SE before April 2027, when EWS in Exchange Online is fully retired.

References#

• Troubleshoot free/busy issues in Exchange hybrid environment (Microsoft Learn)
• Deploy dedicated Exchange hybrid app (Microsoft Learn)
• Test-OAuthConnectivity (Microsoft Learn)