HCW8064: the Hybrid Configuration Wizard finishes but OAuth is not set up

Fix it now

The wizard reached the end of its run and could not complete the OAuth portion. Microsoft’s documented response is short: run the Hybrid Configuration Wizard again, or configure OAuth manually using the published procedure. Before you do either, make sure you are running the current wizard, because an out-of-date one produces a related failure that no amount of rerunning fixes.

Get-AuthConfig | Format-List CurrentCertificateThumbprint
Get-AuthServer | Format-List Name,Enabled,IsDefaultAuthorizationEndpoint
Get-IntraOrganizationConnector | Format-List Name,Enabled,TargetAddressDomains
Get-PartnerApplication | Format-List Name,Enabled,ApplicationIdentifier

1. Install the current Hybrid Configuration Wizard from aka.ms/hybridwizard before rerunning anything. If yours is version 16.x or earlier it does not update itself and has to be uninstalled and reinstalled.
2. Rerun the wizard. That is the first option Microsoft gives for this warning, and a transient failure during the OAuth step is common enough to be worth one retry.
3. If it fails again, check the objects above. Missing AuthServer, IntraOrganizationConnector or PartnerApplication objects tell you which part of the OAuth configuration did not land.
4. Check the auth certificate has not expired: read the thumbprint from Get-AuthConfig, then check its NotAfter with Get-ExchangeCertificate -Thumbprint <value> | Format-List NotAfter.
5. Test the trust in the direction that matters: Test-OAuthConnectivity -Service EWS -TargetUri <remote EWS URL> -Mailbox <a mailbox>.

Microsoft’s second documented option is to configure OAuth by hand using its published procedure for OAuth authentication between Exchange and Exchange Online. Use that procedure rather than assembling the objects from memory.

If free/busy and cross-premises moves work afterwards, stop here. If the wizard fails at the same step every time, the next section covers what it is trying to do.

Why it happens

Microsoft’s page for this condition quotes the wizard’s own words: 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 the published steps. The cause it gives is broad – an issue occurred that prevented OAuth from being configured, either transient or permanent. That vagueness is deliberate, and it is why rerunning is the first documented option rather than a shrug.

It matters more than the wording suggests, because the rest of hybrid can look correct while OAuth is broken. Mail flows, the shared namespace works, and then free/busy lookups, cross-premises mailbox moves and the features that depend on server-to-server trust fail quietly, days later, in a way nobody connects back to the wizard run.

The number HCW8064 is worth a note of its own. Microsoft does not publish it: the page that documents this condition does not carry the code at all. The condition is documented, the code is not, and the same is true of HCW8072 and HCW8028 – a search of Microsoft’s documentation for either returns nothing. Use the codes to correlate lines in your own log; do not look for an authoritative meaning that has not been published.

One neighbouring error is fully documented and is worth ruling out first because its fix is trivial. AADSTS50011 – the reply URL specified in the request does not match the reply URLs configured for the application – is caused by one of the wizard’s old reply URLs having been retired while the installed wizard still uses it. The fix is to install the current wizard, and versions 16.x and earlier will not update themselves, so they need uninstalling first.

Full reference

What OAuth carries, and what breaks without it

• Cross-premises free/busy lookups in both directions.
• Cross-premises mailbox moves and the tooling that drives them.
• Features that depend on server-to-server authentication between the on-premises organisation and Exchange Online, rather than on a user’s own credentials.
• None of these fail at the moment the wizard finishes, which is why an OAuth warning gets dismissed and then investigated a fortnight later as a free/busy problem.

The objects the wizard should have created

Read them before you change anything. Which objects are missing tells you where in the sequence the wizard stopped, and that is far more useful than the log line that names the step.

Codes in this family, and what is actually published

This is not a reason to ignore the numbers. They are stable within your own wizard log and they let you correlate a failure across runs. It is a reason to distrust any source that tells you exactly what HCW8072 means.

Replacing the auth certificate by hand

1. New-ExchangeCertificate to create the replacement. This role uses a self-signed certificate, not one from a public authority.
2. Set-AuthConfig -NewCertificateThumbprint <thumbprint> -NewCertificateEffectiveDate <date> to stage it as the next certificate.
3. Set-AuthConfig -PublishCertificate to roll it over immediately and deploy it to the Client Access servers.
4. Set-AuthConfig -ClearPreviousCertificate to clear the certificate saved as the previous one.
5. Restart the Microsoft Exchange Service Host service and IIS, then allow replication before testing from another Exchange server.

Cleaning up after several failed runs

Removing hybrid objects on a system that is partly working interrupts free/busy and cross-premises operations while you rebuild. Record what exists before you start, remove objects one at a time, and check after each removal rather than sweeping.

• Inventory both sides before touching either. The on-premises objects are listed above; the tenant has its matching connector.
• Remove only what clearly belongs to the failed attempt. A partly cleaned hybrid is harder to diagnose than a broken one.
• Rerun the wizard rather than hand-building the remainder, so both organisations end up describing the same arrangement.
• Keep a note of what you removed and when, because the next person to look at this will need it.
• Where the wizard genuinely cannot complete OAuth, use Microsoft’s published manual procedure rather than assembling the objects from memory.

Every code this article covers

Confirm the fix worked

1. Get-AuthServer, Get-IntraOrganizationConnector and Get-PartnerApplication all return the objects you expect on premises.
2. Get-AuthConfig returns a thumbprint whose certificate has a NotAfter date in the future.
3. Test-OAuthConnectivity -Service EWS -TargetUri <uri> -Mailbox <mailbox> succeeds.
4. A free/busy lookup across the hybrid boundary returns real availability rather than hash marks.
5. A test mailbox move in the direction you need starts without an authorisation failure.

Questions people ask about this