🧩Consider the following scenario:

• Exchange 2019 CU12 in Hybrid Configuration (also reproduced in older versions), configured in Full Classic mode with Hybrid Configuration Wizard
• User has on-prem mailbox and cloud online archive
• User can access his Archive in Outlook
• User cannot access his Archive in OWA and see error below while expanding it:

🧩Some additional verification steps to check, that OAUTH is working in hybrid mode as expected:

1. Run following command in your on-prem Exchange powershell:

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

2. Run following command in your Exchange online powershell:

Test-OAuthConnectivity -Service EWS -TargetUri https://mail.contoso.com/metadata/json/1   -Mailbox   <Exchange Online Mailbox>   -Verbose | Format-List

Note. To verify OAUTH in on-prem you need to use on-rem mailbox. To verify OAUTH in cloud  – you should use EXO mailbox. It’s not a mistake.

For more information and details see Configure OAuth authentication between Exchange and Exchange Online organizations

✅Verify that expected features work as expected:

• Free/Busy works from Cloud to on-prem and vice versa
• Migration of mailboxes works
• Test-ArchiveConnectivity -UserSmtp someuser@contoso.com  shows error “An Autodiscover request couldn’t be made for a misconfigured Office 365 mailbox“

In this specific case OAUTH worked as expected, but affected user still couldn’t access his cloud archive mailbox from OWA. No errors in IIS or application \ protocol logs.

🛠️Next troubleshooting steps:

Collected Exchange tracing showed this specific errors:

“Security.ExternalAuthentication”,”Configuration”,”Searching for federation trust configuration in AD”

“Data.Storage”,”Xtc”,”External authentification is disabled, remote mailbox/archive access for user /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=674939ede0e214d555247548983434e4970 will be disabled”

Thus, it looks like access to EXO archive for on-prem user from OWA requires DAUTH, and you need to configure Federation Trust manually if it doesn’t exist. In our case, federation wasn’t created by HCW, as it’s configured it only in specific cases \ situations.

From 🔗Create a hybrid deployment with the Hybrid Configuration wizard:

“HCW doesn’t enable Federation Trust by default for all Exchange Hybrid installations. It only enables Federation Trust if there are Exchange 2010 servers available on-premises. If no Exchange 2010 servers are found in the Exchange Server Organization, the workflow to enable Federation Trust and subsequently requiring domain proof will not execute. Note that organization relationships are still created.

For Exchange 2013 and above Exchange Hybrid deployments (i.e. organizations with no Exchange 2010 server) while creating Organization Relationships, HCW resets TargetApplicationUri and TargetAutodiscoverEpr as there is no Federation Trust. Although, if customers create Federation Trust manually, HCW honors this Federation Trust and preserves the values stored in TargetApplicationUri and TargetAutodiscoverEpr”

🛠️Configure federation trust

In our case, OWA was used extensively in organization and access to online Archive was really important for users. We need to configure federation trust per article 🔗Configure a federation trust:

Below is some step-by-step short instruction I’ve used in my case. All steps are performed on Exchange server in on-prem organization.

1. Verify, if you have certificate for federation, and if you don’t, you will need to issue new certificate.

Get-ExchangeCertificate  

Certificated services should list federation, subject name usually also contain something related to federation.

2. If you don’t have appropriate certificate (doesn’t exist or expired), you will need to issue new certificate. It’s OK to use self-signed certificate.

$SKI = [System.Guid]::NewGuid().ToString(“N”);

New-ExchangeCertificate -DomainName ‘Federation’ -FriendlyName “Exchange Delegation Federation” -Services Federation – SubjectKeyIdentifier $SKI -PrivateKeyExportable $true

3. Next, you will use this certificate thumbprint to create federation trust:

New-FederationTrust -Name “Microsoft Federation Gateway” -Thumbprint 8E0A3AEB20FE752424FE3F63465DF4683F52018C

(replace to thumbprint that you’ve got at step 2)

4. Certificate should be automatically distributed on all Exchange Servers in organization, and it will take some time.

You can verify that certificate exists on servers with Get-ExchangeCertificate cmdlet for every specific server, or use Test-FederationTrustCertificate tocheck all servers.

5. Next, you need to create TXT DNS record in public DNS that supports your DNS zone. For example, here, you get corresponding parameters for domain contoso.com:

Get-FederatedDomainProof -domainname contoso.com

Use this information to create appropriate DNS record and wait until it will be distributed.

6. Next, update federation trust:

Set-FederationTrust -RefreshMetadata -Identity “Microsoft Federation Gateway”

7. Add your domain to account namespace:

Set-FederatedOrganizationIdentifier -DelegationFederationTrust “Microsoft Federation Gateway” -AccountNamespace contoso.com  -Enabled $true

8. Sometimes it’s useful to verify federation trust with Test-FederationTrust  cmdlet. This cmdlet requires specific system mailbox to be created.

To create this mailbox switch to C:\Program Files\Microsoft\Exchange Server\V15\scripts directory and run new-TestCasConnectivityUser powershell script :

Cd $exscripts

.\new-TestCasConnectivityUser.ps1

9. After that, you can run  Test-FederationTrust cmdlet to verify that federation trust works and all tests finish successfully.

💡Note. This cmdlet works in UTC timezone. If your certificate was issued in your local Timezone, it can be, that certificate is not valid so far from Test-FederationTrust cmdlet perspective and you need to wait.

10. In some cases, you will also need to set TargetAutodiscoverEpr and TargetApplicationUri parameters for Organization Relationship.

If test-ArchiveConnectivity still doesn’t work, verify the name of your Org Relationship via Get-OrganizationRelationship and use it as identity. Example:

Set-OrganizationRelationship “On-premises to O365 – a874157c-6722-4d49-abaf-6f83d15297dc” -TargetAutodiscoverEpr https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity  -TargetApplicationUri “outlook.com”

For more information on this issue you can review this nice blog article Case Study: Exchange Hybrid on premises users cannot open their online archives from OWA, Outlook desktop is not affected

11. Finally, verify that issue resolved with test-ArchiveConnectivity -UserSmtp someuser@contoso.com and OWA.

End.