When deploying an Exchange Hybrid configuration, one of the most critical components to publish externally is the Autodiscover service. Autodiscover enables seamless client connectivity and hybrid functionality between on-premises Exchange and Exchange Online, including mailbox moves, free/busy lookups, and Outlook profile configuration. However, publishing Autodiscover to the Internet can become a complex challenge when requests are terminated or inspected at Layer 7 by a load balancer or Web Application Proxy (WAP).
In a properly configured Exchange environment, the Autodiscover service is designed to provide clients and other Exchange components with configuration data automatically, without manual setup. When an Outlook client (or Exchange Online during a hybrid connection) attempts to locate Autodiscover, it follows a well-defined discovery sequence. But if we focus on the Exchange Online (EXO) aspect, the Intra Org Connector has a specific namespace that it wants to connect to. And this may not be the name that you expect to see...
Cross-Premises Free/Busy Overview
There are notable differences in how free/busy etc. work with Exchange Hybrid nowadays compared to the initial days of hybrid and rich coexistence. The newer solution is OAUTH versus the original DAUTH method.
-
Delegated Auth (DAuth) – Delegated authentication occurs when a network service accepts a request from a user and can obtain a token to act on behalf of that user to initiate a new connection to a second network service
-
Open Authorization (OAuth) - OAuth is an authorisation protocol - or in other words, a set of rules - that allows a third-party website or application to access a user’s data without the user needing to share login credentials
One key point is that if both OAUTH and DAUTH are configured and enabled, then only OAUTH will be used. There is no fallback. This means that the new OAUTH and IntraOrganizationConnector is what will be used.
For more details please refer to: Deep Dive: How Hybrid Authentication Really Works
The different aspects and moving parts for OAUTH and DAUTH are outlined here:
Demystifying Hybrid Free/Busy: what are the moving parts? | Microsoft Community Hub
Autodiscover Publishing Woes
Now that we have recapped all that free/busy publishing entails, let's look at the unexpected issue that broke free/busy from EXO to on-premises. Publishing on-premises to EXO is typically the hardest thing to get working. Allowing the Exchange server access to the tenant is much easier as that is typically just ensuring that the Exchange server has Internet access. Yes, there are definitely times where I've been burned by proxy and network devices in that scenario, but they are much fewer than the EXO -> on-premises issues.
Exchange hybrid was configured using the Hybrid Configuration Wizard (HCW). Nothing special was done, and there were no issues. After running the HCW all the mail flow tests were good, and on-premises mailboxes could see free/busy in EXO. But EXO was unable to see calendar information for any on-premises mailbox. You could open a browser and hit https://autodiscover.domain.com/Autodiscover/Autodiscover.xml all of that worked just as expected. The customer was getting frustrated as they had hired a consultant for the deployment, and just could not get this working. They said that all of the troubleshooting steps had been reviewed and nothing apparently was wrong.
After looking at the configuration, one thing was apparent. Look at the Autodiscover endpoint used by the IntraOrganizationConnector.
Get-IntraOrganizationConnector | FL TargetAddressDomains, DiscoveryEndpoint, Enabled
Note the address of the discovery endpoint – in the environment it was found to be:
https://mail.contoso.com/autodiscover/autodiscover.svc
Is that what you would have assumed it to be? Probably not.
We have been conditioned since the Exchange 2007 days to expect Autodiscover to be available at https://autodiscover.domain.com/autodiscover
This was an issue in this environment as the external load balancer operated at layer 7, and was configured to only allow certain URLs. This was not one of them. The same issue can occur if you use WAP to publish Exchange. Below is a screenshot from WAP. Note that the https://mail.tailspintoys.ca/autodiscover URL was added to allow the cross-premises traffic from EXO. This was done rather than updating the DiscoveryEndpoint as that would reset when re-running the HCW. Sure you could change the IOC's DiscoveryEndpoint but you need to do that every time the HCWE is executed. Chances are that people will overlook having to change it and the issue will arise again.
Bootnote
Why did the HCW set the set the DiscoveryEndpoint to use that URL?
The HCW set the DiscoveryEndpoint to the EWS URL appended with /autodiscover.
As you can see in the WAP publishing rules, the EWS virtual directory is specified as https://mail.tailspintoys.ca
This is why the IOC's DiscoveryEndpoint was https://mail.tailspintoys.ca/autodiscover/autodiscover.svc
Note that the .svc is for the web services implementation of Autodiscover. The original incarnation was Plain Old XML (POX) and was at the /autodiscover.xml location.
Troubleshooting Free Busy References
The below outlines steps for troubleshooting Free/Busy
Troubleshooting Calendar KB Articles
The below were referenced whilst onsite:
Test-OrganizationRelationship
This cmdlet was used to test of the Organization Relationship was working.
Need to specify the actual Organization Relationship as the -identity parameter.
Cheers,
Rhoderick
