Unable to share calendar free/busy info from O365 to external federated domain

Question

I've got two domains that I'm trying to share calendar free/busy info between through federation. SiteA is an on premise deployment of Exchange 2010 SP2. SiteB is an Office 365 Enterprise deployment.

Both organizations are federated through the MSFT gateway.

Sharing works from SiteA to SiteB, meaning a user at SiteB can request access to a user at SiteA and view their calendar.

Sharing does not work from SiteB to SiteA.

Running Test-OrganizationRelationship shows the following:

[PS] C:\Windows\system32>Test-OrganizationRelationship -UserIdentity [email protected] -Identity siteB -verbose
VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship : Active Directory session settings for
'Test-OrganizationRelationship' are: View Entire Forest: 'False', Default Scope: 'mydomain', Configuration
Domain Controller: 'mydc', Preferred Global Catalog: 'mygc', Preferred
Domain Controllers: '{ mydc1, mydc2 }'
VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship : Runspace context: Executing user:
[email protected], Executing user organization: , Current organization: , RBAC-enabled: Enabled.
VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship : Beginning processing &
VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship : Instantiating handler with index 0 for cmdlet extension
agent "Admin Audit Log Agent".
VERBOSE: [20:24:06.037 GMT] Test-OrganizationRelationship : Current ScopeSet is: { Recipient Read Scope: {{, }},
Recipient Write Scopes: {{, }}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive
Recipient Scope(s): {}, Exclusive Configuration Scope(s): {} }
VERBOSE: [20:24:06.037 GMT] Test-OrganizationRelationship : Searching objects "me" of type "ADUser" under the root
 "$null".
VERBOSE: [20:24:06.037 GMT] Test-OrganizationRelationship : Previous operation run on global catalog server
'mygc'.
VERBOSE: [20:24:06.037 GMT] Test-OrganizationRelationship : Searching objects "siteB" of type "OrganizationRelationship"
under the root "$null".
VERBOSE: [20:24:06.037 GMT] Test-OrganizationRelationship : Previous operation run on domain controller
'mydc'.
VERBOSE: Test that organization relationships are properly configured.
VERBOSE: [20:24:06.053 GMT] Test-OrganizationRelationship : Resolved current organization: .
VERBOSE: [20:24:06.053 GMT] Test-OrganizationRelationship : Calling the Microsoft Exchange Autodiscover service for the
 remote federation information.
VERBOSE: [20:24:09.084 GMT] Test-OrganizationRelationship : The Autodiscover call succeeded for the following URL:
https://pod51041.outlook.com/autodiscover/autodiscover.svc.
VERBOSE: [20:24:09.084 GMT] Test-OrganizationRelationship : The Autodiscover call succeeded for the following URL:
https://pod51041.outlook.com/autodiscover/autodiscover.svc.
VERBOSE: [20:24:09.084 GMT] Test-OrganizationRelationship : The Autodiscover call succeeded for the following URL:
https://pod51041.outlook.com/autodiscover/autodiscover.svc.
VERBOSE: [20:24:09.084 GMT] Test-OrganizationRelationship : The Autodiscover call succeeded for the following URL:
https://pod51041.outlook.com/autodiscover/autodiscover.svc.
VERBOSE: [20:24:09.084 GMT] Test-OrganizationRelationship : Generating delegation token for user me@siteA for
application http://outlook.com/.
VERBOSE: [20:24:09.366 GMT] Test-OrganizationRelationship : The delegation token was successfully generated.
VERBOSE: [20:24:09.366 GMT] Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service is being called
 to determine the remote organization relationship settings.
VERBOSE: [20:24:09.366 GMT] Test-OrganizationRelationship : The Client will call the Microsoft Exchange Autodiscover
service using the following URL: https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity.
VERBOSE: [20:24:10.553 GMT] Test-OrganizationRelationship : 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 = <cannot read response stream>
Exception:
System.Net.WebException: The request failed with HTTP status 404: Not Found.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse

I can't find any reason for it to be failing. It's failing at the autodiscover call for wssecurity. All the online posts say to enable wssecurity for the virtual directory, but that isn't an option for a full online deployment of Office 365. Frankly, federated sharing from O365 should "Just Work"

This next piece is the Org relationship data going from SiteB (O365) to SiteA (EX 2010)

PS C:\Users\me> Get-OrganizationRelationship | fl
Creating a new session for implicit remoting of "Get-OrganizationRelationship" command...


RunspaceId            : b56a8f0b-7e7e-4e8c-bf5c-c33209e59b13
DomainNames           : {SiteA}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
MailboxMoveEnabled    : False
DeliveryReportEnabled : False
MailTipsAccessEnabled : False
MailTipsAccessLevel   : None
MailTipsAccessScope   :
PhotosEnabled         : False
TargetApplicationUri  : FYDIBOHF25SPDLT.SiteA.us
TargetSharingEpr      :
TargetOwaURL          :
TargetAutodiscoverEpr : https://autodiscover.SiteA.us/autodiscover/autodiscover.svc/WSSecurity
OrganizationContact   :
Enabled               : True
ArchiveAccessEnabled  : False
UseOAuth              : False
AdminDisplayName      :
ExchangeVersion       : 0.10 (14.0.100.0)
Name                  : SiteA
DistinguishedName     : CN=SiteA,CN=Federation,CN=Configuration,CN=appriver3651001356.onmicrosoft.com,CN=ConfigurationUni
                        ts,DC=NAMPR04A001,DC=prod,DC=outlook,DC=com
Identity              : SiteA
Guid                  : d01ce3d5-6b47-41c6-b597-9f5ed5aca4a8
ObjectCategory        : NAMPR04A001.prod.outlook.com/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship
ObjectClass           : {top, msExchFedSharingRelationship}
WhenChanged           : 7/19/2013 3:36:22 AM
WhenCreated           : 7/19/2013 3:36:13 AM
WhenChangedUTC        : 7/19/2013 10:36:22 AM
WhenCreatedUTC        : 7/19/2013 10:36:13 AM
OrganizationId        : NAMPR04A001.prod.outlook.com/Microsoft Exchange Hosted
                        Organizations/appriver3651001356.onmicrosoft.com - NAMPR04A001.prod.outlook.com/ConfigurationUn
                        its/appriver3651001356.onmicrosoft.com/Configuration
OriginatingServer     : BL2PR04A001DC06.NAMPR04A001.prod.outlook.com
IsValid               : True
ObjectState           : Unchanged

And this is from SiteA (EX 2010) to SiteB (O365)

[PS] C:\Windows\system32>Get-OrganizationRelationship | fl

RunspaceId            : a9029d90-cdf0-494a-85ea-a960bc04f023
DomainNames           : {SiteB domains, 4 total}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
MailboxMoveEnabled    : False
DeliveryReportEnabled : False
MailTipsAccessEnabled : False
MailTipsAccessLevel   : None
MailTipsAccessScope   :
TargetApplicationUri  : http://outlook.com/
TargetSharingEpr      :
TargetOwaURL          :
TargetAutodiscoverEpr : https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity
OrganizationContact   :
Enabled               : True
ArchiveAccessEnabled  : False
AdminDisplayName      :
ExchangeVersion       : 0.10 (14.0.100.0)
Name                  : SiteB
DistinguishedName     : CN=SiteB,CN=Federation,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=my,DC=site
Identity              : SiteB
Guid                  : 458f9921-f2f8-4286-92e2-a3f0b8c444f1
ObjectCategory        : Mysite/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship
ObjectClass           : {top, msExchFedSharingRelationship}
WhenChanged           : 7/19/2013 10:37:58 PM
WhenCreated           : 7/19/2013 3:16:18 PM
WhenChangedUTC        : 7/20/2013 5:37:58 AM
WhenCreatedUTC        : 7/19/2013 10:16:18 PM
OrganizationId        :
OriginatingServer     : MyDC
IsValid               : True

It should be noted that when I enter the TargetAutodiscoverEPR (https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity) I am prompted for credentials, meaning that the 404 error I get is bunk.

The other odd thing I've noticed is when I setup the Organization Relationship from SiteA to SiteB. Running Get-FederationInformation yields the following for SiteB

PS C:\Users\me> Get-FederationInformation -DomainName SiteB
Creating a new session for implicit remoting of "Get-FederationInformation" command...


RunspaceId            : d6086380-948f-43db-9d0c-4ba7325b5a20
TargetApplicationUri  : outlook.com
DomainNames           : {SiteB domains, 4 total}
TargetAutodiscoverEpr : https://pod51041.outlook.com/autodiscover/autodiscover.svc/WSSecurity
TokenIssuerUris       : {urn:federation:MicrosoftOnline}
IsValid               : True
ObjectState           : Unchanged

The TargetApplicationUri states "outlook.com", and that's how it got entered when I setup the Org Relationship in the SiteA EMC. However, sharing didn't work and testing got me the following

PS C:\Users\me> Test-OrganizationRelationship -UserIdentity me@SiteB -Identity SiteA


RunspaceId  : d6086380-948f-43db-9d0c-4ba7325b5a20
Identity    :
Id          : ApplicationUrisDiffer
Status      : Error
Description : The TargetApplicationUri of the remote organization doesn't match the local ApplicationUri of the
              Federation Trust object. The remote URI value is http://outlook.com/. The local URI value is
              outlook.com/.
IsValid     : True
ObjectState : New

RunspaceId  : d6086380-948f-43db-9d0c-4ba7325b5a20
Identity    :
Id          : VerificationOfRemoteOrganizationRelationshipFailed
Status      : Error
Description : There were errors while verifying the remote organization relationship SiteB.
IsValid     : True
ObjectState : New

I had to manually go into the Org Relationship object (SiteA trust of SiteB) and change the URI from "outlook.com" to "http://outlook.com" for sharing to work in that direction. This is another quirk of setting this all up that is making me thing that this is a MSFT issue on the O365 side...

Solution

I had exactly the same issue and I thought I managed to resolve it however it was for about 5 min

Basically today I tried to rediscover the settings by using "Automatically discover configuration Information"

It changed TargetAutodiscoverEpr to https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity from https://podxxxxx.outlook.com/autodiscover/autodiscover.svc/WSSecurity. It worked for about 5 minutes and started coming up with 401 error. Rediscovered and back to podxxxxxy format again.

Hope that will provide some clues.

Comments

[Admin]

have you seen support.microsoft.com/kb/2838688 ?

[Admin]

@RobM Yeah, that was shown to me as well, but it doesn't fit here. The TargetSharingEpr on both sides are already null

[Admin]

Have you used the Remote Connectivity Analyser to test autodiscovery? testexchangeconnectivity.com

[Admin]

Hmmm... We use a hybrid deployment, but I didn't set it up so probably not experienced enough to know the answer, but have you verified the relevant ports are open on your firewall to allow the incoming traffic to flow from O365? I guess the best start is 80/443.

[Admin]

Plus, that RCA is a little quirky in its formatting, it looks like it has failed but actually just trying a bunch of different methods until it finds one that works and then moves on.

[Admin]

@Holocryptic - have a look at these 2 links and see if either help. support.microsoft.com/kb/2555008 and community.office365.com/en-us/forums/158/p/23314/…

[Admin]

@john That's my actual config. I didn't anonymize that portion.

[Admin]

@TheCleaner That's all stuff I've tried. We're escalating from MSFT now.

[Admin]

Let us know how it goes and post the answer. It could help others with O365 federation in the future.

[XelaIT]

changed to autodiscover-s.outlook.com/autodiscover/autodiscover.svc/… and randomly after many tries it started working again for 5 minutes or so and stopped again.

[XelaIT]

I seems to intermittently for about 5 min. It looks like an issue on Office 365 side. Will try to log a call with them.