When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration:
When inspecting the Update-HybridConfiguration results, it reads:
Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.
Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.
Federation information could not be received from the external organization.
..
The problem lies in the sentence “Federation Information could not be received from external organization”. To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged.
Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain:
Get-FederationInformation example.com –Verbose
You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. When analyzing this output, you’ll see it contains two hints on the potential issues:
Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; …
1. Autodiscover
The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside.
Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice.
Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using:
Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true
2. Proxy rules
In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.
To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:
- /EWS/Exchange.asmx/wssecurity
- /Autodiscover/Autodiscover.svc
- /Autodiscover/Autodiscover.svc/wssecurity
After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.
After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.
For more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.
EighTwOne (821) 
Pingback: Federation Information could not be received .. | EighTwOne (821) « JC’s Blog-O-Gibberish
I was resolve this issue by some easy steps: “Server configuration” -> “Client Access” -> tap on “owa (Default Web Site)” -> in action pane tap on “Configure External Client Access”. In “Server selection” window enter external name in first line and add local Exchange 2010 server in “Select the Client Access servers……”
LikeLike
Pingback: 2012, a short Retrospective | EighTwOne (821)
excellent solution. It solved my problem.thanks
LikeLike
When I try to create a TMG rule for autodiscover, and set the authentication to ‘no authentication’, the entry can’t be saved… it states ‘The authentication settings of the Web listener used in the rule Redirect OWA are not compatible with the type of credentials delegation configured for this rule.’ any ideas on that?
LikeLike
Nevermind, I believe I’ve resolved this.
LikeLike
or not.. might need a different listener?
LikeLike
The rule authentication delegation setting need to be in the same authentication scheme as the authentication setting on the listener (and the CAS server(s)). Autodiscover needs to be authenticated. You could use the Outlook Anywhere publishing wizard to set the initial rule up for you using the autodiscover FQDN (will add autodiscover configuration), and remove the Outlook Anywhere specifics from the Paths, i.e. /rpc/* and /oab/*.
LikeLike
Thanks a lot, appreciate this post, came to my rescue at the right time.
LikeLike
Thanks for this post, I think that has given me a light.
But when performing continuous DNS entry error, however I think it is something else because when I run the cmdlet: “Get-FederationInformation mydomain-Verbose” now gives me an error of SSL / TLS before I appeared.
Scope(s): {}, Exclusive Configuration Scope(s): {} }
VERBOSE: [17:22:16.348 GMT] Get-FederationInformation : Resolved current organization: .
VERBOSE: [17:22:16.353 GMT] Get-FederationInformation : Using the following trusted host names: *.outlook.com.
VERBOSE: [17:22:19.200 GMT] Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.mydomain.com.co/autodiscover/autodiscover.svc;Exception=Discovery for domain
mydomain.com.co
failed.;Details=(Type=Failure;Url=https://autodiscover.mydomain.com.co/autodiscover/autodiscover.svc;Exception=The
underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.;);
Type=Failure;Url=https://mydomain.com.co/autodiscover/autodiscover.svc;Exception=Discovery for domain mydomain.com.co
failed.;Details=(Type=Failure;Url=https://mydomain.com.co/autodiscover/autodiscover.svc;Exception=The underlying connection
was closed: An unexpected error occurred on a send.;);
Type=Failure;Url=http://autodiscover.mydomain.com.co/autodiscover/autodiscover.xml;Exception=Discovery for domain mydomain.com.co
failed.;Details=(Type=Failure;Url=http://autodiscover.mydomain.com.co/autodiscover/autodiscover.xml;Exception=The remote
server returned an error: (403) Forbidden.;);
Type=Failure;Url=http://mydomain.com.co/autodiscover/autodiscover.xml;Exception=Discovery for domain mydomain.com.co
failed.;Details=(Type=Failure;Url=http://mydomain.com.co/autodiscover/autodiscover.xml;Exception=The remote server returned
an error: (403) Forbidden.;);
.
Federation information could not be received from the external organization.
+ CategoryInfo : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
+ FullyQualifiedErrorId : B780F771,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation
+ PSComputerName : hibrido.mydomain.com.co
VERBOSE: [17:22:19.223 GMT] Get-FederationInformation : Ending processing &
I wonder if the fact that the certificate is not aparesca “autodircover.mydomain” has to do with this failure.
Thank you.
LikeLike
This saved the day for me!! Great post. Thank you!!
LikeLike
Pingback: New Exchange Updates are Out | Just A UC Guy
Pingback: Netrix LLC – New Exchange Updates are Out