When implementing cross-organization calendar sharing between Office 365 and Exchange 2010, many admins encounter a perplexing scenario: one-way federation works perfectly while the reverse direction fails with cryptic 404 errors. The core symptoms include:

• Successful sharing from Exchange 2010 (SiteA) to O365 (SiteB)
• Failed sharing from O365 (SiteB) to Exchange 2010 (SiteA)
• 404 Not Found errors on WSSecurity endpoints during Test-OrganizationRelationship
• Mismatched TargetApplicationURI formats causing verification failures

The critical error appears in the Test-OrganizationRelationship output:

VERBOSE: The Microsoft Exchange Autodiscover service failed to be
called at 'https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity' 
because the following error occurred: WebException.Response = 
System.Net.WebException: The request failed with HTTP status 404: Not Found.

Despite the 404 error, the endpoint actually exists (credential prompts appear when accessed directly). This suggests an authentication handshake failure rather than a missing resource.

A particularly insidious problem surfaces in the TargetApplicationURI format:

Test-OrganizationRelationship output shows:
The remote URI value is http://outlook.com/. The local URI value is outlook.com/.

The protocol prefix matters significantly in federation scenarios. We need to ensure consistent formatting:

# Correct the URI format in Exchange 2010
Set-OrganizationRelationship -Identity "SiteB" -TargetApplicationUri "http://outlook.com/"

For Office 365 to Exchange 2010 sharing, several specific requirements must be met:

# O365 Organization Relationship configuration essentials
Set-OrganizationRelationship -Identity "SiteA" 
    -FreeBusyAccessEnabled $true 
    -FreeBusyAccessLevel LimitedDetails 
    -TargetAutodiscoverEpr "https://autodiscover.siteA.com/autodiscover/autodiscover.svc/WSSecurity" 
    -TargetApplicationUri "FYDIBOHF25SPDLT.siteA.com"

To systematically verify the federation setup:

# 1. Verify federation trust
Get-FederationTrust | fl *uri*

# 2. Check organization relationships
Get-OrganizationRelationship | fl Name,DomainNames,TargetApplicationUri,TargetAutodiscoverEpr,FreeBusyAccess*

# 3. Test both directions
Test-OrganizationRelationship -UserIdentity user@siteA.com -Identity SiteB -Verbose
Test-OrganizationRelationship -UserIdentity user@siteB.com -Identity SiteA -Verbose

In hybrid environments, proxy servers might interfere with the WSSecurity endpoint communication. Verify proxy exceptions are configured for:

• *.outlook.com
• autodiscover.yourdomain.com
• All federation endpoints

If federation remains problematic, consider these workarounds:

# 1. Use direct publishing of free/busy via IIS
Set-OrganizationRelationship -Identity "SiteA" -FreeBusyAccessEnabled $false
Set-WebServicesVirtualDirectory -Identity "EWS*" -ExternalUrl https://mail.siteA.com/ews/exchange.asmx

# 2. Implement mailbox forwarding rules
New-InboxRule -Name "ForwardCalendar" -From user@siteB.com -CopyToFolder user@siteA.com

---

When attempting to federate calendar sharing between Office 365 and Exchange 2010 SP2, I encountered asymmetric behavior where free/busy information flowed in one direction but not the other. The setup involves:

• SiteA: On-prem Exchange 2010 SP2
• SiteB: Office 365 Enterprise
• Both federated through Microsoft's federation gateway

The primary symptom manifests when testing the organization relationship:

Test-OrganizationRelationship -UserIdentity me@site.a -Identity siteB -verbose
[...]
System.Net.WebException: The request failed with HTTP status 404: Not Found.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(...)

Interestingly, manually visiting the autodiscover endpoint (https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity) prompts for credentials, suggesting the 404 error might be misleading.

Comparing the organization relationships reveals subtle but critical differences:

From O365 (SiteB) to Exchange 2010 (SiteA)

TargetApplicationUri  : FYDIBOHF25SPDLT.SiteA.us
TargetAutodiscoverEpr : https://autodiscover.SiteA.us/autodiscover/autodiscover.svc/WSSecurity

From Exchange 2010 (SiteA) to O365 (SiteB)

TargetApplicationUri  : http://outlook.com/
TargetAutodiscoverEpr : https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity

Initial federation information retrieval showed an inconsistency:

Get-FederationInformation -DomainName SiteB
[...]
TargetApplicationUri  : outlook.com

But testing revealed the mismatch:

Test-OrganizationRelationship -UserIdentity me@SiteB -Identity SiteA
[...]
Description : The TargetApplicationUri [...] remote URI value is http://outlook.com/.
The local URI value is outlook.com/.

1. Correct the Application URI

Set-OrganizationRelationship -Identity "SiteB" -TargetApplicationUri "http://outlook.com/"

2. Verify WSSecurity Endpoint Availability

Check if the autodiscover endpoint is accessible through PowerShell:

$web = New-Object System.Net.WebClient
$web.DownloadString("https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity")

3. Validate Federation Configuration

Test-FederationTrust -UserIdentity administrator@siteA.com
Get-FederationTrust | fl *uri*

4. Enable Detailed Logging

For Exchange 2010:

Set-EventLogLevel -Identity "MSExchange Autodiscover\Autodiscover" -Level Expert
Set-EventLogLevel -Identity "MSExchange Federation\Federation" -Level Expert

• O365 endpoints sometimes require protocol prefixes (http://) while on-prem doesn't
• DNS resolution must work bidirectionally between environments
• Certificate chains must be properly trusted on both sides
• Time synchronization is critical for federation token validation

1. Verify consistent Application URI formats (include protocol)
2. Confirm autodiscover DNS records resolve correctly
3. Check firewall rules for autodiscover endpoints
4. Validate certificate trust chains
5. Ensure proper time synchronization (NTP configured)