Exchange Hybrid: HCW8064 OAuth configuration couldn't get performed
At the end of the Hybrid Configuration Wizard (HCW) I received the following warning message:
HCW8064 - The HCW has completed, but was not able to perform the OAuth portion of your Hybrid configuration. If you need features that rely on OAuth, you can try running the HCW again or manually configure OAuth using these manual steps.
The link “more information” links to https://support.microsoft.com/en-us/help/3089172/hcw-has-completed-but-was-not-able-to-perform-the-oauth-portion-of-you. If you lookup what OAuth is used for, this article comes up. There you can read OAuth is needed for cross-premises eDiscovery searches. Since these functions were not relevant in the project, I ignored them for the time being. By the way, running HCW again did not set up OAuth propely as well.
OAuth can also be used for authentication for cross-premise sharing of Free/Busy information. The linked OAuth-article mentions only eDiscovery - which is also the section of the documentation where the article resides. More OAuth-scenarios are not explained there. Free/Busy is not mentioned in the article about configuring OAuth for Exchange Hybrid either.
No Free/Busy available
After the first test users were migrated to Exchange Online, it turned out that the cross-premise access to Free/Busy information did not work. There are two very good articles in the Exchange Team Blog explaining Hybrid Free/Busy:
- Demystifying Hybrid Free/Busy: what are the moving parts?
- Demystifying Hybrid Free/Busy: Finding errors and troubleshooting
Intra-Organization Connector (IOC)
You can check both on-premise and in Exchange Online whether an
Intra-Organization Connector (required for Hybrid OAuth) is present. Since the configuration via HCW failed, no working IOC configuration should be stored.
Get-IntraOrganizationConnector | fl
The attribute “Enabled” is set to
False, therefore no OAuth is used. Just as expected.
Organization Relationship (ORG REL)
The next step is to check if an Organization Relationship exists.
Get-OrganizationRelationship | fl
In my case, an Organization Relationship was returned. So DAUTH is in use.
I’ve actually only scratched the surface here. After some troubleshooting it turned out that authentication via DAUTH really isn’t working in this case. I have tried to check the cross-premise availability in Outlook on the Web (OWA). In the browser developer console (accessible via “F12”) under “Network” you can filter for “GetUserAvailabilityInternal”.
The relevant information I could find there:
AADSTS901124: Application ‘fydibohf25spdlt.example.com’ does not exist.
The details of the Free/Busy Troubleshooting are also available in Exchange Team Blog: Demystifying Hybrid Free/Busy: Finding errors and troubleshooting. Since the non-existent application and the code “AADSTS901124” seemed to be no standard scenario, I actually wanted to open a ticket at Microsoft. But since OAuth is the modern and recommended authentication method anyway, one can also do troubleshooting for that.
Setting up OAuth manually
Basically the manual setup of OAuth is described in the article Configure OAuth authentication between Exchange and Exchange Online organizations. I’m not going to repeat it all here. What was different for me, though:
Exchange Server Auth Certificate expired and renewed
In the section “Step 3: Export the on-premises authorization certificate” it’s described how the Microsoft Exchange Server Auth Certificate can get exported. In the next step it would get imported into Exchange Online. Since the Exchange 2013 system has been in operation at the customer’s site for over 5 years, the certificate has already been replaced once. Since Hybrid and OAuth have never been used here, the new certificate was never stored for authentication.
At the German site msxfaq.de there is a good article about Exchange OAuth. It describes, among other things, how per
Set-AuthConfig the new certificate can be applied:
Set-AuthConfig -NewCertificateThumbprint <myCertThumbprint> -NewCertificateEffectiveDate (Get-Date)
After that an
iisreset is also required.
Configuring Intra-Organization Connector
Afterwards I could proceed according to the documentation (Step 3, 4 and 5). Step 6 and 7 didn’t apply anymore. There was no need to create the IOC, they just had to get enabled by
Get-IntraOrganizationConnector | Set-IntraOrganizationConnector -Enabled $true. Step 8 didn’t play a role, because there were no pre-Exchange 2013 SP1 servers in the environment.
Afterwards I could successfully perform the following tests:
OAuth Test using PowerShell
Execute in the On-Premise Exchange Management Shell:
Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List
Execute in Exchange Online PowerShell:
Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List
Retrieving Free/Busy times (Cross-Premise)
Actually, it was possible to retrieve cross-premise free/busy times - in both directions. Here is an example screenshot showing the query from an Exchange Online mailbox to an Exchange On-Premise mailbox.
- Demystifying Hybrid Free/Busy: what are the moving parts? (Exchange Team Blog)
- Demystifying Hybrid Free/Busy: Finding errors and troubleshooting (Exchange Team Blog)
- Configure OAuth authentication between Exchange and Exchange Online organizations (docs.microsoft.com)
- Exchange OAuth article (msxfaq.de)