Wednesday, December 14, 2011

Federation information could not be received from the external organization.

I had an issue when completing the Hybrid Configuration Wizard in Exchange 2010 SP2. It continuously crashed out with the following error.

Error:
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.
at Microsoft.Exchange.Management.Hybrid.RemotePowershellSession.RunCommand(String cmdlet, Dictionary`2 parameters, Boolean ignoreNotFoundErrors)
'.

Additional troubleshooting information is available in the Update-HybridConfiguration log file located at C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration\HybridConfiguration_12_8_2011_18_2_52_634589641723224440.log.

Exchange Management Shell command attempted:
Update-HybridConfiguration -OnPremisesCredentials 'System.Management.Automation.PSCredential' -TenantCredentials 'System.Management.Automation.PSCredential'

Elapsed Time: 00:02:56




I also received the following error when running this command:

Get-FederationInformation -DomainName 4logic.com.au

Federation information could not be received from the external organization.
+ CategoryInfo : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
+ FullyQualifiedErrorId : ABE6A500,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation




Externally my autodiscover was working correctly which I confirmed by using the Exchange Remote Connectivity Analyzer (ExRCA).



However what we found was internally the Get-FederationInformation does not use the Service Connection Point (SCP) objects in Active Directory for performing Autodiscover. As a result it must be able to resolve autodiscover.4logic.com.au to an internal IP address.

We have two ways we can do this... add your public DNS zone to your internal network and populate it with internal IP addresses or create an entry in your hosts file on your Hybrid Server. This is what I did.

The hosts file is located under C:\Windows\System32\drivers\etc



Also your certificate attached to Exchange must have a valid SAN name for your autodiscover record.

7 comments:

  1. any issues with using a wildcard certificate instead of a SAN certificate? i'm getting the exact errors shown here, but all dns resolution appears to be functional.

    ReplyDelete
  2. Install Exchange 2010 SP2 Update Rollup 1. This should contain the fix.

    ReplyDelete
  3. I am getting this error too, RU1 did not fix it for me, did it work for you?

    ReplyDelete
  4. We're seeing it too, and are working with a senior support escalation engineer at Microsoft to attempt to determine the cause and solution. We have split DNS, and the internal DNS record for autodiscover is a CName pointing to an "A" record representing the Hybrid server (though not the NetBIOS name). We tried a host file entry and still no go. The SAN cert's subjects contain "autodiscover" and the name in the "A" record. Still no go. Same error.

    ReplyDelete
  5. Update to April 11, 2012 post: The MS engineer thinks he's found the problem with our SP2, Rollup 1 installation and can reproduce it. The problem lies somewhere with IIS and autodiscover. If you browse directly to autodiscover.svc, it fails. But if you go to the autodiscover.xml and authenticate first, and then you go to autodiscover.svc, it redirects to WSSecurity and succeeds. The problem is, when O365 "reaches in," it does not first go to the .xml.

    ReplyDelete
    Replies
    1. Were you able to find a resolution to this issue?

      Delete
  6. I have same issue. That does it mean, a post above? We should wait untill rollup 2, or?..

    ReplyDelete