Can we check free busy from exchange online to exchange on premises?

Question

Can we check free busy from exchange online to exchange on premises?

Anna 40

I have installed the exchange server 2019 inside a VM having a domain test.lab, will i be able to see the free busy from my Microsoft demo tenant to my on-premises exchange user (eg. ******@test.lab). If yes, then how can I do so. what all configurations I have to do.

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Hi Anna,

Yes, Exchange Online can show free busy for an on-premises Exchange 2019 user, but not if that user only has a non-routable address like user[at]test.lab. You must use a public, verified SMTP domain and publish Autodiscover and EWS on that domain, then run Hybrid Configuration so OAuth and the org relationships are created. Otherwise Exchange Online has nothing to discover and no trusted path to your VM, so lookups will fail. Microsoft's guidance is to add a routable domain and enable OAuth with HCW for hybrid free busy.

Here is a way to make your demo work.

First, add a public domain you own, for example contoso.com, to both sides. In Microsoft 365, add and verify contoso.com. In on-prem Exchange, add contoso.com as an accepted domain and stamp your on-prem mailbox with an SMTP address on that domain, ideally as the primary SMTP. Also add a matching UPN suffix in Active Directory so the user can have a cloud-routable identity such as anna[at]contoso.com. This step is required when your forest uses a non-routable suffix like .lab or .local.

Second, publish the on-prem endpoints on that same public namespace and use a public CA certificate. You need external DNS for autodiscover.contoso.com and a name for your Exchange virtual directories, for example mail.contoso.com, and your certificate must include those names. The Autodiscover and EWS URLs must be reachable from the internet over TCP 443.

Third, run the latest Hybrid Configuration Wizard from the Exchange Online Admin Center or the HCW bootstrap. Choose a minimal hybrid if you only need coexistence, or full hybrid if you also want secure mail flow and moves. HCW will configure OAuth trust and the required sharing objects such as the IntraOrganizationConnector or Organization Relationship that enable free busy and MailTips between Exchange Online and on-prem.

Fourth, because it is now late 2025, accept the prompt in HCW to create the Dedicated Exchange Hybrid App in Microsoft Entra ID. Microsoft is retiring the legacy shared service principal path for these hybrid features. The dedicated app is now the supported way for free busy and related EWS-based lookups from Exchange Online to your on-premises server. If you skip this, free busy from cloud to on-prem can break.

Finally, test. From an Exchange Online mailbox that knows your on-prem user as anna[at]contoso.com, open the Scheduling Assistant and check availability. If it fails, validate OAuth with Test-OAuthConnectivity against your EWS URL and confirm the IntraOrganizationConnector exists and is enabled. You can also use the Microsoft Remote Connectivity Analyzer to verify your external Autodiscover and EWS are published correctly.

If you would like, tell me the public domain you can use and the external names you want for Autodiscover and EWS, and I will give you the exact DNS and certificate names plus the precise HCW selections to click.

Answer 2

Anna 40

Hi @Francisco Montilla ,

I have a DNS zone(eg anna.qsftdemo.com) hosted on azure portal. Can i make use of that?
Because i verified that domain under my tenant and also added that as accepted domain in my on premises ECP.
Also added as UPN in active directory and created the on prem user using that domain.

Anna 40 Reputation points

2025-11-03T13:53:40.3066667+00:00

Also I ran the hybrid wizard but it didn't worked for me. And I used the certificate which I created using Lets Encrypt which do include SAN -> mail.anna.qsftdemo.com & autodiscover.anna.qsftdemo.com.
Francisco Montilla 20,185 Reputation points Independent Advisor

2025-11-04T11:10:40.07+00:00

You can use the public DNS zone anna.qsftdemo.com, just make sure the zone is properly delegated on the internet, and that the public DNS records autodiscover.anna.qsftdemo.com and mail.anna.qsftdemo.com both point to the public IP that forwards port 443 to your Exchange 2019 VM.

Your certificate is valid as long as it includes mail.anna.qsftdemo.com and autodiscover.anna.qsftdemo.com as SANs and the full chain includes ISRG Root X1. If the Hybrid Configuration Wizard (HCW) or clients report trust issues, fix the certificate chain on the server. Set the external URLs in Exchange so they match the certificate names (for EWS and Autodiscover) and then restart IIS. After that, run the latest Hybrid Configuration Wizard and accept creation of the new Dedicated Exchange Hybrid app in Entra ID, since this is required for modern OAuth-based free/busy in 2025.

Finally, verify that the IntraOrganizationConnector in Exchange Online points to your EWS URL (https://mail.anna.qsftdemo.com/EWS/Exchange.asmx). Test connectivity using the Microsoft Remote Connectivity Analyzer and Test-OAuthConnectivity from your Exchange server. Once EWS responds correctly and OAuth works, free/busy information for on-prem users will display in Exchange Online.

ALso, avoid using the Hybrid Agent for this setup, EWS-based free/busy requires the classic HTTPS endpoints, and SSL inspection on port 443 must be disabled.
Anna 40 Reputation points

2025-11-04T13:17:58.9266667+00:00
@Francisco Montilla

I’m using anna.qsftdemo.com as my root domain, and there are no subdomains configured for it. Both autodiscover.anna.qsftdemo.com and mail.anna.qsftdemo.com resolve correctly to the public IP of my Exchange VM (verified via nslookup from outside the VM). The certificate chain also includes ISRG Root X1.

I’m trying to run the Hybrid Configuration Wizard (HCW), but it isn’t completing successfully. The IntraOrganizationConnector, which initially didn’t have the EWS URL configured — although I have now set it as you suggested.
Also, there are missing parameters in Organization relationship as well.

Additionally, OAuth authentication doesn’t seem to be configured properly. I attempted to configure it manually following this Microsoft article: Configure OAuth authentication between Exchange and Exchange Online.

When I ran the following command in on premises:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List

…it completed successfully.

However, when I ran this command in exo powershell:

Test-OAuthConnectivity -Service EWS -TargetUri https://mail.anna.qsftdemo.com/metadata/json/1 -Mailbox ExchangeOnlineBox1 -Verbose | Format-List

…it failed with the following information and exception details:

Information: [OAuthCredentials:Authenticate] send request to 'https://mail.anna.qsftdemo.com/ews/Exchange.asmx' Token: {"alg":"none","typ":"JWT"}."iss": "00000002-0000-0ff1-ce00-000000000000@ad9ce29-649e-4cc3-9d13-9e19eff8347e" ... Exception: System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@ad9ce29-649e-4cc3-9d13-9e19eff8347e", token_types="app_asserted_user_v1 service_asserted_app_v1", error="invalid_token", Basic realm="mail.anna.qsftdemo.com", Negotiate, NTLM'.

As a result, the test fails with ResultType : Error, although the IsValid property still shows True.

Could you please help me with the required configuration to enable Free/Busy sharing from Exchange Online to on-premises users? A checklist or key steps to verify would be very helpful.
Francisco Montilla 20,185 Reputation points Independent Advisor

2025-11-05T17:13:45.01+00:00
Anna, the error shows Exchange Online is still using the old shared service principal (client_id 00000002-0000-0ff1-ce00-000000000000), and your on-prem Exchange is rejecting it as invalid_token. This happens when OAuth isn't updated to the new dedicated Exchange hybrid app and Exchange Online isn't pointing directly to your on-prem EWS. The fix is to reconfigure hybrid OAuth using the 2025 method and set Exchange Online's IntraOrganizationConnector to your EWS URL. Microsoft now supports only the dedicated hybrid app with TargetSharingEpr, not legacy partner apps.

First, make sure your Exchange 2019 is on a supported build: CU15 or CU14 with the April 2025 HU. Run Get-ExchangeServer and check AdminDisplayVersion. If you’re below that, install the April 2025 HU first, since older builds can't use the dedicated app and will keep failing with invalid_token.

Then set up the dedicated Exchange hybrid app with Microsoft’s script in All-in-one mode. Run it on your Exchange 2019 VM using an account with both Exchange Organization Management on-prem and Global Admin in the tenant.

cd C:\Temp .\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication

The script creates the dedicated app in Entra ID, uploads your OAuth cert, updates EvoSTS, enables the Exchange override, and sets TargetSharingEpr if Autodiscover resolves. If anything's missing (like consent or outbound access) the script will tell you.

Next, make Exchange Online explicitly target your EWS.

Connect-ExchangeOnline Get-IntraOrganizationConnector | fl Name,Enabled,TargetSharingEpr,TargetAddressDomains Set-IntraOrganizationConnector -Identity "O365 to OnPrem" -TargetSharingEpr https://mail.anna.qsftdemo.com/EWS/Exchange.asmx Set-IntraOrganizationConnector -Identity "O365 to OnPrem" -TargetAddressDomains anna.qsftdemo.com

TargetSharingEpr is now the supported 2025 method to ensure Exchange Online talks to your on-prem EWS correctly.

Then test OAuth from both sides. From Exchange Online, run:

Test-OAuthConnectivity -Service EWS -TargetUri https://mail.anna.qsftdemo.com/metadata/json/1 -Mailbox <EXO mailbox> -Verbose | fl

Success shows ResultType as Success and your dedicated hybrid appId instead of 00000002-0000-0ff1-ce00-000000000000.

Finally, use Microsoft's Remote Connectivity Analyzer to test Autodiscover and EWS for https://mail.anna.qsftdemo.com/EWS/Exchange.asmx. Fix any TLS or name mismatches. Once EWS responds on 443 and OAuth works both ways, Exchange Online's Scheduling Assistant will show free/busy for on-prem users.

Your earlier test failed because Exchange Online sent a token from the old shared app, which your on-prem couldn't validate. After switching to the dedicated app and setting TargetSharingEpr, Exchange Online will request a token for your tenant's dedicated app, which your on-prem trust will accept.

If you want me to confirm what's missing, share the outputs of these commands:

On-prem EMS: Get-AuthServer | fl Name,ApplicationIdentifier,Realm,IssuerIdentifier EXO PowerShell: Get-IntraOrganizationConnector | fl Name,TargetSharingEpr,TargetAddressDomains EXO PowerShell: Test-OAuthConnectivity -Service EWS -TargetUri https://mail.anna.qsftdemo.com/metadata/json/1 -Mailbox <EXO mailbox> -Verbose | fl

Anna 40

I was running Exchange Server 2019 CU15, but on an older build. As suggested, I updated it to the April build. After the update, I executed the following command:

cd C:\Temp
.\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication

During execution, the following warnings were displayed:

WARNING: We did not find the 'Exchange Online' partner application in your on-premises environment.
WARNING: It seems like your OAuth configuration is invalid - are you using DAuth instead of OAuth?
WARNING: The following Setting Override(s) already exist:
         [Setting Override] Name: 'EnableExchangeHybrid3PAppFeature' Feature enabled? 'true'
WARNING: Run this command to remove existing overrides if needed:
         Get-SettingOverride | Where-Object {$_.ComponentName -eq "Global" -and $_.SectionName -eq "ExchangeOnpremAsThirdPartyAppId"} | Remove-SettingOverride -Confirm:$false
WARNING: The dedicated hybrid application feature is enabled, but your OAuth configuration appears to be incomplete.
WARNING: Please review your OAuth configuration or run the Hybrid Configuration Wizard (HCW).

However, the PartnerApplication does include Exchange Online:

Get-PartnerApplication "Exchange Online" | fl

Output:

Enabled                             : True
ApplicationIdentifier               : 00000002-0000-0ff1-ce00-000000000000
AuthMetadataUrl                     :
Realm                               : ad9ce29-649e-4cc3-9d13-9e19eff8347e
UseAuthServer                       : True
AcceptSecurityIdentifierInformation : True
...
Name                                : Exchange Online
IsValid                             : True

After verification:

Get-AuthServer:

Name            IssuerIdentifier                                              Realm                                TokenIssuingEndpoint
----            ----------------                                              -----                                --------------------
WindowsAzureACS 00000001-0000-0000-c000-000000000000                          ad9ce29-649e-4cc3-9d13-9e19eff8347e https://accounts.accesscontrol.windows.net/ad9ce29-649e-4cc3-9d13-9e19eff8347e/tokens/OAuth/2
evoSTS          https://sts.windows.net/ad9ce29-649e-4cc3-9d13-9e19eff8347e/ ad9ce29-649e-4cc3-9d13-9e19eff8347e https://login.windows.net/common/oauth2/token

Get-IntraOrganizationConnector:

Name                 : HybridIOC - 1e19dd-a1fb-4a3c-800f-aaadc13f8ca8
Enabled              : True
TargetSharingEpr     : https://mail.anna.qsftdemo.com/EWS/Exchange.asmx
TargetAddressDomains : {anna.qsftdemo.com}

Finally, when running Test-OAuthConnectivity, the same error persisted:

System.ServiceModel.Security.MessageSecurityException:
The HTTP request is unauthorized with client authentication scheme 'Anonymous'.
The authentication header received from the server was 'Bearer ... error="invalid_t

In the browser’s network tab (Developer Tools) while checking free busy from exo user to on prem user, the following error details were captured:

"error": {
    "message": "ProxyWebRequestProcessingException: Proxy web request failed. Inner exception: The request failed with HTTP status 401: Unauthorized. Diagnostics: 2000005; reason=\"The user specified by the user-context in the token does not exist.\"; error_category=\"invalid_user\" LID: 43532",
    "responseCode": "5016"
}

Francisco Montilla 20,185 Reputation points Independent Advisor

2025-11-07T02:15:24.3466667+00:00
You are very close. That 401 invalid_token with reason invalid_user tells us Exchange Online is generating a valid OAuth call, but your on-prem Exchange cannot map the EXO requester in the token to a security principal in your local AD.

In other words, identity mapping for the requester is missing or inconsistent, and the hybrid trust still shows leftovers that confuse OAuth. Microsoft documents this invalid_user category for hybrid Free/Busy, and the fixes revolve around two things only: a clean dedicated-hybrid OAuth trust and a requester that exists in the target directory.

Do this in one pass and then retest.

First make the hybrid OAuth trust clean and dedicated. Stay on the latest Exchange 2019 hotfix build, then recreate the Dedicated Exchange Hybrid App and refresh the trust your server uses. In Exchange Management Shell on-prem, remove any old SettingOverride for the dedicated app id exactly as the script suggested, then run the current ConfigureExchangeHybridApplication.ps1 to fully configure the dedicated hybrid application. After it completes, verify evoSTS is the active AuthServer and that the PartnerApplication named Exchange Online exists and is healthy, including a LinkedAccount. Use these four checks and expect no blanks in the key fields.

# Clear any stale override the script warned about Get-SettingOverride | Where-Object {$_.ComponentName -eq "Global" -and $_.SectionName -eq "ExchangeOnpremAsThirdPartyAppId"} | Remove-SettingOverride -Confirm:$false # Recreate the dedicated hybrid app trust end-to-end cd C:\Temp .\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication -ForceRecreate -Verbose # Verify evoSTS and ACS are present and evoSTS is in use Get-AuthServer | fl Name,IssuerIdentifier,Realm,TokenIssuingEndpoint,IsDefaultAuthorizationEndpoint # Verify the partner app Get-PartnerApplication "Exchange Online" | fl Name,ApplicationIdentifier,IssuerIdentifier,AuthMetadataUrl,UseAuthServer,LinkedAccount,IsValid

If LinkedAccount is empty on that PartnerApplication, set one as Microsoft shows for Free/Busy. Create or pick a low-privilege AD user for the link, then attach it and recycle IIS:

Set-PartnerApplication "Exchange Online" -LinkedAccount "yourdomain.local/users/Exchange Online-ApplicationAccount" iisreset /noforce

Microsoft's dedicated app guidance and the hybrid security changes notes back up this exact flow and the requirement to move to the dedicated app on current builds.

Next make sure the requester is known on-prem. The error you captured in the browser DevTools says The user specified by the user-context in the token does not exist. That is the smoking gun. For EXO to on-prem Free/Busy over OAuth, the cloud requester must resolve to a real user object in your local AD. In labs this often breaks when the EXO test mailbox was created cloud-only. The fix is to make the EXO test user a synchronized identity, not cloud-only.

Create a corresponding AD user and hard-match it to the existing EXO account, or, if this is a demo, create the mailbox in EXO from on-prem with New-RemoteMailbox so the linkage exists from the start. Microsoft's hybrid Free/Busy troubleshooting pack calls out invalid_user when the token's user cannot be resolved or where duplicates exist. If you already sync identities, also search AD for any duplicate UPN or SMTP that could cause ambiguous user in the same invalid_user category.

After the two items above are corrected, validate the IOC and endpoints are what Exchange Online will actually use. From Exchange Online PowerShell, ensure the IOC towards on-prem lists your anna.qsftdemo.com domain and that DiscoveryEndpoint is your public Autodiscover URL. Then run the OAuth test again from both sides:

# In Exchange Online PowerShell Get-IntraOrganizationConnector | fl Name,Enabled,DiscoveryEndpoint,TargetAddressDomains Set-IntraOrganizationConnector -Identity "HybridIOC*" -DiscoveryEndpoint https://autodiscover.anna.qsftdemo.com/autodiscover/autodiscover.svc -TargetAddressDomains @{add="anna.qsftdemo.com"} # Test from EXO towards on-prem EWS Test-OAuthConnectivity -Service EWS -TargetUri https://mail.anna.qsftdemo.com/ews/Exchange.asmx -Mailbox EXORequesterUPN -Verbose | fl # Test from on-prem towards EXO EWS Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox OnPremMailboxUPN -Verbose | fl

If you still see 401 after these changes, check two environmental items that routinely block Free/Busy. First confirm TLS 1.2 is fully enabled end-to-end on the Exchange server and any reverse proxy. Second ensure there is no SSL offload in front of Autodiscover or EWS, which breaks OAuth audience validation for hybrid. Microsoft's Free/Busy guide covers both.

Two final sanity checks that often save time:

Make sure your on-prem IOC or OrganizationRelationship contains the right domain names, for example anna.qsftdemo.com on the EXO side and your tenant cloud domain where needed.

Also confirm Autodiscover and EWS names and your Let’s Encrypt cert chain are presented exactly as configured, which you already verified. A Microsoft's Free/Busy resolver article shows the expected relationship values.

Once the dedicated hybrid app is clean and the requester is represented in local AD, the 401 invalid_user goes away and EXO can read on-prem Free/Busy normally. If anything in the outputs above looks off, paste just the four verification snippets back, and I will pinpoint the exact field to fix.
Anna 40 Reputation points

2025-11-07T12:36:11.2266667+00:00
I cleared any stale overrides that the script warned about using the following command:

Get-SettingOverride | Where-Object {$_.ComponentName -eq "Global" -and $_.SectionName -eq "ExchangeOnpremAsThirdPartyAppId"} | Remove-SettingOverride -Confirm:$false

Then I re-created the dedicated hybrid app trust end-to-end:

cd C:\Temp .\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication -ForceRecreate -Verbose

After that, I verified the authorization servers and partner application configuration:

Get-AuthServer | fl Name,IssuerIdentifier,Realm,TokenIssuingEndpoint,IsDefaultAuthorizationEndpoint Get-PartnerApplication "Exchange Online" | fl Name,ApplicationIdentifier,IssuerIdentifier,AuthMetadataUrl,UseAuthServer,LinkedAccount,IsValid Set-PartnerApplication "Exchange Online" -LinkedAccount "yourdomain.local/users/Exchange Online-ApplicationAccount" iisreset /noforce

However, even after running these commands, it still didn’t work initially.

Also, I had synced the on-premises users to Exchange Online using Azure AD Connect, but I wasn’t sure how to do the reverse — that is, syncing Exchange Online (cloud) users back to the on-premises Active Directory. Because of that, there were no Exchange Online users present in the local AD.

Following your suggestion, I manually created the same Exchange Online user in the on-premises Active Directory. After doing that, the OAuth test from exo to on prem worked successfully, and I was able to view the free/busy information from that Exchange Online user to the on-prem user.

Now, I’m wondering why it’s necessary to have the cloud user to be present in the local AD. Also, if we don’t want to create these users manually, is there any way or tool to automatically sync cloud users to the on-premises AD?
Francisco Montilla 20,185 Reputation points Independent Advisor

2025-11-07T18:25:06.6466667+00:00

You needed that cloud user in your local AD because Exchange on-prem only authorizes Free/Busy requests when the caller in the OAuth token can be resolved to a real security principal in your on-prem directory.

There is no supported feature that auto-creates on-prem AD users from cloud-only users. Microsoft Entra Connect and Cloud Sync are designed with on-prem AD as the source of authority, with limited writeback for things like passwords, devices, groups and Exchange hybrid attributes, but not user objects. Even the new Entra Cloud Sync scenario that provisions from Entra to AD is focused on group writeback to AD DS rather than creating users. That is why your manual creation plus sync worked and why there is not a toggle to push cloud users down automatically.

The way to avoid this in the future is to convert any cloud-only accounts that must query on-prem resources into synced identities. Do it once per account and you are done. If the UPNs and SMTP addresses already match, use UPN matching so the cloud account becomes managed by your on-prem AD after the next sync. If UPNs cannot match, do a hard match by stamping the cloud user's ImmutableId to the base64 of the on-prem user's objectGUID, then let Entra Connect link them on the next run. Both flows are documented by Microsoft for existing tenants.

One practical blueprint that scales is this. Create the user in on-prem AD first, stamp the same UPN and proxyAddresses the cloud user has, then let Entra Connect link them by UPN (soft match). If soft match cannot work, calculate the on-prem object's ImmutableId and stamp it on the cloud user, then run a delta sync to complete the hard match.

For clarity on what does write back, Exchange hybrid writeback covers a set of Exchange attributes so cross-premises features work smoothly, but it does not create users in AD.
Anna 40 Reputation points

2025-11-10T06:03:25.0033333+00:00

Thank you so much for all your help.

Share via

Can we check free busy from exchange online to exchange on premises?

1 additional answer

Your answer