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.

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.

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.

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.