Office 365 Users cant See On-Premise Free/Busy Information

Exchange 2010 Hybrid Office 365 Free Busy Issues.

On-Premise users can see Free/Busy Information of On-Premise users.
On-Premise users can see Free/Busy Information of O365 Users.
O365 Users can See Free/Bust Information of O365 Users.

O365 Users cannot See Free/Bust Information of On-Premise Users.

The O365 user can Open the Users calendar and see everything, though when they use the Scheduling Assistant when creating a Meeting they get:

No Information.
No free/busy information could be retrieved
the external recipient's server could not be determined.
Contact your administrator

MS Remote Connectivity Analyzer comes back with all okay for AutoDiscover.
https://www.testconnectivity.microsoft.com/

The User's Default Calendar Permissions allow for "AvailabilityOnly", I have also tried "LimitedDetails" with no success.


RunspaceId   : c704d8d7-fc2a-4c5e-84ee-f9387189b798
FolderName   : Calendar
User         : Default
AccessRights : {AvailabilityOnly}
Identity     : Default
IsValid      : True

RunspaceId   : c704d8d7-fc2a-4c5e-84ee-f9387189b798
FolderName   : Calendar
User         : Anonymous
AccessRights : {None}
Identity     : Anonymous
IsValid      : True

Open in new window


Here is the Default Sharing Policy:

RunspaceId        : c70458d7-f52a-4c55-84e5-f9387189b758
Domains           : {Anonymous:CalendarSharingFreeBusyReviewer, *:CalendarSharingFreeBusySimple}
Enabled           : True
Default           : True
AdminDisplayName  :
ExchangeVersion   : 0.10 (14.0.100.0)
Name              : Default Sharing Policy
DistinguishedName : CN=Default Sharing Policy,CN=Federation,CN=<site>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=costono,DC=com
Identity          : Default Sharing Policy
Guid              : 35eca126-d55b-4d84-95e9-6f7f99a6c46e
ObjectCategory    : costono.com/Configuration/Schema/ms-Exch-Sharing-Policy
ObjectClass       : {top, msExchSharingPolicy}
WhenChanged       : 3/28/2018 11:24:37 AM
WhenCreated       : 6/20/2011 4:22:52 PM
WhenChangedUTC    : 3/28/2018 6:24:37 PM
WhenCreatedUTC    : 6/20/2011 11:22:52 PM
OrganizationId    :
OriginatingServer : addc.costono.COM
IsValid           : True

Open in new window

LVL 3
Scott TownsendIT DirectorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vasil Michev (MVP)Commented:
In general you should be looking at the Org relationship, not the Sharing policies. Make sure that all domains are included there. Other than that, enable logging and look at the actual error reported there.

Is this a pure 2010 install? There was a known issue with recent 2016 updates: https://support.microsoft.com/en-us/help/4058297/hybrid-f-b-looks-up-fails-between-exchange-server-2016-cu8-and-o365

You can get some additional tips via the guided troubleshooter (https://support.microsoft.com/en-us/help/10092/troubleshooting-free-busy-issues-in-exchange-hybrid-environment) or these blogs:
https://blogs.technet.microsoft.com/exchange/2018/02/06/demystifying-hybrid-freebusy-what-are-the-moving-parts/
https://blogs.technet.microsoft.com/exchange/2018/03/02/demystifying-hybrid-freebusy-finding-errors-and-troubleshooting/
Scott TownsendIT DirectorAuthor Commented:
Single Exchange 2010 SP3 RU 19?


Using the connectivity Analyzer for Free/Busy Test with O365 Source and On-Prem Destination returns Test was Good.

Performing Free/Busy Lookup
 	Free/Busy Lookup completed successfully.
 	
	Additional Details
 	
Results for <On-Prem-user>@<domain>.com which consists of appointments that include today's date
Free	4/16/2018 7:00:00 AM - 4/21/2018 7:00:00 AM UTC
Busy	4/17/2018 3:00:00 PM - 4/21/2018 12:00:00 AM UTC
Busy	4/18/2018 12:30:00 AM - 4/18/2018 2:00:00 AM UTC
Busy	4/18/2018 5:00:00 PM - 4/18/2018 5:30:00 PM UTC
Elapsed Time: 1097 ms.

Open in new window




Creating the Appointment in OWA has the same issue as Outlook 2016. Using the information here: https://blogs.technet.microsoft.com/exchange/2018/03/02/demystifying-hybrid-freebusy-finding-errors-and-troubleshooting/
I was able to get the GetUserAvailabilityInternal information.  It returned the following Error:
The response from the Autodiscover service at 'https://autodiscover/autodiscover.svc/WSS ecurity' failed due to an error in user setting 'ExternalEwsUrl'. Error message: InvalidUser.

Open in new window


Googling that said to be sure that the O365 user has the user@<tenant>.mail.onmicrosoft.com in email addresses of the O365 user. That Address is there.
Same article said to set: Set-OrganizationRelationship “O365 to On-premises*” -TargetSharingEpr <On-Premises EWS External URL>
This one says to make it NULL:


Issuing the following Command:
Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled
Against O365 returns nothing.
Against On-premise returns "The term 'Get-IntraOrganizationConnector' is not recognized as the name of a cmdlet"

Issuing the Command:
Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresse
Against O365 returns the domains I expect
Against On-premise returns  "The term 'Get-IntraOrganizationConfiguration' is not recognized as the name of a cmdlet"


Running the Following Command:
Get-OrganizationRelationship "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d" | fl DomainNames,FreeBusy*,Target*,Enabled
Returns:
DomainNames           : {<list of my domains>...}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : outlook.com
TargetSharingEpr      :
TargetOwaURL          : https://<MyExternalOn-Prem-OWA-URL>/owa
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True

Open in new window



Running the Following Command:
Get-OrganizationRelationship "On-premises to O365 - 722b8d45-5f4a-4f48-a049-55437fe57d8d" | fl DomainNames,FreeBusy*,Target*,Enabled
Returns:
DomainNames           : {<Tenant-Name>.mail.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : outlook.com
TargetSharingEpr      :
TargetOwaURL          : http://outlook.com/owa/<One-Of-My-Domains>
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True 

Open in new window


I'm not sure why this is:
TargetOwaURL          : http://outlook.com/owa/<One-Of-My-Domains>

How does it Choose this: <One-Of-My-Domains>  Its a Random Domain, Possible it was the first one I test migrated to O365. Though Its not the Primary Domain.

Running the Following Command:
Get-AutodiscoverVirtualDirectory -Server <Server> | fl Name,AdminDisplayVersion,*authentication*
Returns:
Name                          : Autodiscover (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True

Open in new window



Running the Following Command:
Get-WebServicesVirtualDirectory -Server <server> | fl Name,AdminDisplayVersion,*Authentication*
Returns:
Name                          : EWS (Default Web Site)
CertificateAuthentication     :
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True

Open in new window



Running the Following Command:
Get-AvailabilityAddressSpace <tenant>.mail.onmicrosoft.com | fl ForestName, UserName, UseServiceAccount, AccessMethod, ProxyUrl, Name
Returns:
ForestName        : <tenant>.mail.onmicrosoft.com
UserName          :
UseServiceAccount : True
AccessMethod      : InternalProxy
ProxyUrl          : https://yExternalOn-Prem-OWA-URL>/EWS/Exchange.asmx
Name              : <tenant>.mail.onmicrosoft.com

Open in new window

Vasil Michev (MVP)Commented:
Your org relationship (the one on the on-prem server - to O365) should have all the domains added, or at least the domain for said user. The info you posted above only shows the default routing O365 domain, which means that only users with user@tenant.mail.onmicrosoft.com addresses will be able to do lookups. This should pop up as an error when you run the Test-OrganizationRelationship cmdlet. So try to add to the domain list and retest.

Apart from that, I see some strange value for the other org relationship (O365 to on-prem), but since free/busy seems to be working OK for on-prem users, I guess we can ignore them.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Scott TownsendIT DirectorAuthor Commented:
Thank you for your reply.   What typically sets the domains in the OrganizationRelationship? HCW? I have selected all of my Domains when I run it.

I have about 25 Domain names that we are hosting. Many users have at least 5 different addresses.  Should they be listed in a Specific order?
<tenant>.mail.onmicrosoft.com fist? AD Connected Domain First?
Listing out all of the Domains for the 'Get-OrganizationRelationship "O365 to On-premises - *" ' does not include <tenant>.mail.onmicrosoft.com, should it?

What was odd about the results from: Get-OrganizationRelationship "O365 to On-premises ?

Below are the results from the Test-OrganizationRelationship from both On-Prem and O365.


Test-OrganizationRelationship from On-Premise Server
[PS] C:\Scripts>Test-OrganizationRelationship -UserIdentity <user>@<PrimaryDomain>.com -Identity "On-premises to O365 - 722b8d45-5f4a-4f48-a049-55437fe57d8d"


RunspaceId  : be97b0cf-bbac-440a-a1ca-253bda110e87
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 FYDIBOHF25SPDLT.<Random-Domain-we-host>.com. The local URI value is outlook.com.
IsValid     : True

RunspaceId  : be97b0cf-bbac-440a-a1ca-253bda110e87
Identity    :
Id          : PropertiesDiffer
Status      : Warning
Description : The values of property MailboxMoveEnabled are different and should match. The local organization relationship On-premises to O365 - 722b8d45-5f4a-4f48-a049-55437fe57d8d has value True, and the remote organization relationship O365 to On-premises - 72
              2b8d45-5f4a-4f48-a049-55437fe57d8d has value False.
IsValid     : True

RunspaceId  : be97b0cf-bbac-440a-a1ca-253bda110e87
Identity    :
Id          : VerificationOfRemoteOrganizationRelationshipFailed
Status      : Error
Description : There were errors while verifying the remote organization relationship O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d.
IsValid     : True

Open in new window





PS C:\Windows\system32> Test-OrganizationRelationship -UserIdentity <user>@<PrimaryDomain>.com -Identity "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d"

Begin testing for organization relationship CN=O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d,CN=Federation,CN=Configuration,CN=<tenant>.onmicrosoft.com,CN=ConfigurationUnits,DC=NAMPR15A003,DC=PROD,DC=OUTLOOK,DC=COM, enabled state True.

Exchange D-Auth Federation Authentication STS Client Identities are urn:federation:MicrosoftOnline/outlook.com;uri:WindowsLiveID/outlook.com;

STEP 1: Validating user configuration
WARNING: The federated domain '<AD-Connected Domain>' of the user is in the local organizational relationship which normally only contains the domains of
external organizations.

RESULT: Success.

STEP 2: Getting federation information from remote organization...

RESULT: Success.

STEP 3: Validating consistency in returned federation information

RESULT: Success.

STEP 4: Requesting delegation token from the STS...

RESULT: Success.
Retrieved token for target https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity for offer Name=MSExchange.Autodiscover,Duration=28800(secs)

STEP 5: Getting organization relationship setting from remote partner...

RESULT: Unable to retrieve organization relationships from remote organization.
RESULT: Error.

LAST STEP: Writing results...


RunspaceId  : 95c54737-df4e-4ec6-b1e5-c75d838c036b
Identity    :
Id          : AutodiscoverServiceCallFailed
Status      : Error
Description : The Autodiscover call failed.
IsValid     : True
ObjectState : New


COMPLETE.

Open in new window

Vasil Michev (MVP)Commented:
You dont need all the domains, but add at least any configured as Accepted domains in O365, or at the very least the ones corresponding to the Primary SMTP address/UPN of your users. No specific order needed.

On the "O365 to on-premises" relationship, you dont need the mail.tenant.onmicrosoft.com domain, as this one only exists in the cloud. What's weird about it for example is the TargetAutodiscoverEpr value, this one should point to your on-premises server.

The HCW should have set the relationships, so it wont hurt if you rerun it one more time. Make sure to use the latest version of the wizard, you can download it from the O365's EAC.
Scott TownsendIT DirectorAuthor Commented:
I was able to add the On-Premise Autodiscover URL to TargetAutodiscoverEpr manually.  
Set-OrganizationRelationship "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d" -TargetAutodiscoverEpr  "https://<on-prem-host>/autodiscover/autodiscover.svc/WSSecurity"

Open in new window


This is the Error I'm getting now from OWA warm trying to check Free/Busy status:
Autodiscover failed for email address <On-Premise-User> with error System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message

Open in new window


Looks like there are Federation Issues?
Scott TownsendIT DirectorAuthor Commented:
Here is the output from the Test-FederationTrust and Test-FederationTrustCertificate Commands

[PS] C:\Scripts>Test-FederationTrust

 RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : FederationMetadata
Type       : Success
Message    : The federation trust contains the same certificates published by the security token service in its federation metadata.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Id         : TokenValidation
Type       : Success
Message    : Requested delegation token is valid.

Open in new window



[PS] C:\Scripts>Test-FederationTrustCertificate
 

RunspaceId : f07537f0-9935-4f05-96c1-640b0e4df4ba
Site       : <AD-Domain>/Configuration/Sites/Corporate
Server     : <On-Prem-Host>
State      : Installed
Thumbprint : 61CC86446535A6368FD94975F6C1F7C0B0332A7E

Open in new window

Vasil Michev (MVP)Commented:
Havent seen this one previously, but quick check on google suggest it's related to the security settings on the virtual directory: https://www.inthecloud247.com/exchange-federated-calendar-sharing-issue/
Scott TownsendIT DirectorAuthor Commented:
Scott TownsendIT DirectorAuthor Commented:
I ran the Following Commands:

Get-FederationTrust | Set-FederationTrust –RefreshMetaData

Get-AutodiscoverVirtualDirectory –Server "<on-prem-server>" | Set-Autodiscovervirtualdirectory –WSSecurityAuthentication $false
Get-WebServicesVirtualDirectory –Server "<on-prem-server>" | Set-WebServicesVirtualDirectory –WSSecurityAuthentication $false
IISRESET

Get-AutodiscoverVirtualDirectory –Server "<on-prem-server>" | Set-Autodiscovervirtualdirectory –WSSecurityAuthentication $True
Get-WebServicesVirtualDirectory –Server "<on-prem-server>" | Set-WebServicesVirtualDirectory –WSSecurityAuthentication $True
IISRESET

Open in new window

Then reset the Application pools.

Still getting:

Autodiscover failed for email address <on-prem-user> with error System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
      at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
         at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
            at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.&lt;&gt;c__DisplayClass48_0.&lt;EndInvoke&gt;b__0()
               at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation).,
                inner exception: An error occurred when verifying security for the message. LID: 37772

Open in new window


Here is the output of tje Test-OrganizationRelatonship again. the AutoDiscover errors are no longer there.

Though This is a bit troubling: FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>
<One-of-the-accepted-Domains> is listed that many times and is the same domain. Its one of the First few test Domains I Migrated over.


Test-OrganizationRelationship -UserIdentity <on-Premise-User> -Identity "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d"

Begin testing for organization relationship CN=O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d,CN=Federation,CN=Configuration,CN=<tenant>.onmicrosoft.com,CN=ConfigurationUnits,DC=NAMPR15A003,DC=PROD,DC=OUTLOO
K,DC=COM, enabled state True.

Exchange D-Auth Federation Authentication STS Client Identities are urn:federation:MicrosoftOnline/outlook.com;uri:WindowsLiveID/outlook.com;

STEP 1: Validating user configuration
WARNING: The federated domain '<AD-Domain>' of the user is in the local organizational relationship which normally only contains the domains of external organizations.

RESULT: Success.

STEP 2: Getting federation information from remote organization...

RESULT: Success.

STEP 3: Validating consistency in returned federation information
RESULT: Error.

LAST STEP: Writing results...


RunspaceId  : 4fb0e4fa-20d5-42e4-bf77-f203288d3ac7
Identity    :
Id          : MismatchedFederation
Status      : Warning
Description : The federation information returned from remote organization is different from local organization relationship configuration. The local organization relationship uses Security Token Service
              'urn:federation:MicrosoftOnline;uri:WindowsLiveID' and the remote organization uses Security Token Services 'urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:
              federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:Microsoft
              Online;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federatio
              n:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;ur
              n:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:Microso
              ftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federat
              ion:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline;urn:federation:MicrosoftOnline'.  The local organization relationship has Application URI
              'outlook.com' and the remote organization uses Application URIs 'FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPD
              LT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.EvanTownsen
              d.me,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF2
              5SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.EvanTow
              nsend.me,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIB
              OHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.Eva
              nTownsend.me,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>,FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>'.
IsValid     : True
ObjectState : New


COMPLETE.

Open in new window

Scott TownsendIT DirectorAuthor Commented:
I found out where <One-of-the-accepted-Domains> is coming from, its the Domain listed in the Federation.
It is the Domain I selected when I first set things up. Though its the AD Connected Domain, its just one of the 35 Domain Names. Its Actually My Son's Domain, so not sure how (or if) I can change it at this point?

C:\Scripts>Get-FederatedOrganizationIdentifier | fl
RunspaceId          : 4e2ceaa7-4f27-488a-8e55-27362dc67316
AccountNamespace    : FYDIBOHF25SPDLT.<One-of-the-accepted-Domains>
Domains             : {<list of my Accepted domains>}
Enabled             : True
OrganizationContact :
DelegationTrustLink : Microsoft Federation Gateway
IsValid             : True
ExchangeVersion     : 0.10 (14.0.100.0)
Name                : Federation
DistinguishedName   : CN=Federation,CN=myenm,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<AD-Domain>,DC=com
Identity            : Federation
Guid                : b4e24116-995b-4886-abbe-001e41de6cd2
ObjectCategory      : <AD-Domain>/Configuration/Schema/ms-Exch-Fed-OrgId
ObjectClass         : {top, msExchFedOrgId}
WhenChanged         : 12/6/2017 11:11:08 AM
WhenCreated         : 6/20/2011 4:22:52 PM
WhenChangedUTC      : 12/6/2017 7:11:08 PM
WhenCreatedUTC      : 6/20/2011 11:22:52 PM
OrganizationId      :
OriginatingServer   : <AD-Server>

Open in new window

Scott TownsendIT DirectorAuthor Commented:
I went through this page too:
http://www.shudnow.net/2017/12/01/pass-through-authentication-without-password-hash-synchronization-breaks-online-to-on-premises-freebusy/

The password Hash was already being Sync'd, so that was not an issue.

As well as this one:
https://support.microsoft.com/en-gb/help/4056251/free-busy-lookup-fails-from-exchange-on-premises-to-exchange-online

Glad I tested with my own account though...     After issuing the Command:
Set-MsolUserPassword -UserPrincipalName John@contoso.com -ForceChangePassword $false

Open in new window

My user's Password was no longer accepted on any of the Online Services.   I had to Login to the Office Portal and reset my password before I could login to the Online Services again.
Scott TownsendIT DirectorAuthor Commented:
I Contacted Microsoft Support and here is what they walked me through…


Get the Federation Trust ApplicationUri from On-Premise
[PS] C:\Windows\system32>Get-FederationTrust

Name                 ApplicationIdentifier     ApplicationUri
----                 ---------------------     --------------
Microsoft Federat... 000000004005162E          <ID>.<Domain.Name>

Open in new window


Get the Federated Organization Identifier AccountNamespace from On-Premise
[PS] C:\Windows\system32>Get-FederatedOrganizationIdentifier | fl AccountNamespace
AccountNamespace    :   <ID>.<Domain.Name>

Open in new window


Get Organization Relationship TargetApplicationUri from Office 365
PS C:\Windows\system32>  Get-OrganizationRelationship "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d" | fl TargetApplicationUri
TargetApplicationUri : outlook.com

Open in new window


TargetApplicationUri should be the same a the On-Premise ApplicationUri - <ID>.<Domain.Name> and not, outlook.com

For the O365 to On-Prem Connector - Set the Organization Relationship TargetApplicationURI to the proper ApplicationUri - <ID>.<Domain.Name> In Office 365
Set-OrganizationRelationship "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d" -TargetApplicationURI "  <ID>.<Domain.Name>"

Open in new window


Verify the TargetApplicationUri was set correctly on Office 365
PS C:\Windows\system32>  Get-OrganizationRelationship "O365 to On-premises - 722b8d45-5f4a-4f48-a049-55437fe57d8d" | fl TargetApplicationUri
TargetApplicationUri :   <ID>.<Domain.Name>

Open in new window

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott TownsendIT DirectorAuthor Commented:
Contact MS Support
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Office

From novice to tech pro — start learning today.