I decided to extend the Insight into the Hybrid Configuration Wizard article into another 2 parts. I've been getting numerous requests on troubleshooting the dreaded Get-FederationInformation Exception.
Let’s recap on what the high level steps for the HCW are:
I’m going to skip the Recipient Configuration Task here and cover that in my next article. I want to focus on step 4, the Organization Relationship Task for this article.
So let’s get right into it.
As the task name suggests, this step will:
Now, from the things I’ve seen and heard in the field is that most of the issues occur at step 3.
Step 3 uses a process called ProvisionOrganizationRelationship. The very first step that this function does is it tries to get the federation information for the domain for the organization relationship settings – let’s use uclabz.com.
Get-FederationInformation –domainname uclabz.onmicrosoft.com –BypassAdditionalDomainValidation $True
New-OrganizationRelationship -Name -TargetApplicationUri *.outlook.com -TargetAutodiscoverEpr <the Exchange Online Autodiscover URL> -Enabled:$True -DomainNames uclabz.mail.onmicrosoft.com
Get-FederationInformation –domainname uclabz.com –BypassAdditionalDomainValidation $True
Let’s pause here for a moment.
So why is the code doing this. Well, it’s simple. By using Get-FederationInformation, it’s very easy to get the correct values for TargetApplicationURI, TargetAutodiscoverEPR and DomainNames which is required for the New-OrganizationRelationship task.
The issues occur, because many customers have different ways of doing things, like Autodiscover, Certificates and Reverse Proxy etc.
Let’s take an example – Autodiscover:
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) '.
See, the way Get-FederationInformation cmdlet works is that the discovery process only uses the following logic to determine the correct settings (in this order):
So as you can see from the above, you need to have the correct DNS record’s in public DNS for this step to work.
Here are some more tips on what to check for when you run into this problem:
Get-autodiscovervirtualdirectory –server <hybridcas>|Set-AutodiscoverVirtualDirectory –WSSecurityAuthentication $true
Get-FederationInformation –domainname domain.onmicrosoft.com -BypassAdditionalDomainValidation $True
Get-FederationInformation –domainname domain.onmicrosoft.com
Allow All users and No Authentication, users can authenticate directly. TMG will need to passthrough the traffic directly to the Hybrid CAS instead of authenticating as specified above.Confirm that traffic is not being blocked to Autodiscover.svc by checking the TMG logs.See this article on TMG - http://support.microsoft.com/kb/2821214
Get-FederationInformation -domainname uclabz.com -BypassAdditionalDomainValidation $True
Phew, I think that’s that for this article. Good luck with your hybrid configurations, I hope the above helps.
Until next time,
Michael Hall (MCS)
Thanks Aleksandar! I hope the article helps people!
thanks for your great article, but the HCW still fails here. I noticed TargetAutodiscoverEpr has a wrong value when I Get-FederationInformation, I don't have an A record for autodiscover.domain.com which is the value actually set but a SRV record with points to mail.domain.com. All the remote connectivity analyzer tests are passed and on premises external clients (OA/activesync) fully working with autodiscover.
You will have to create a Autodiscover A record. As described in the article, the Get-Federationinformation cmdlet will not check for SRV. So you need to have the correct A record in DNS.
Hope that helps,
Error in listing of Autodiscover process. the third line should read: https://autodiscover.uclabz.com/autodiscover/autodiscover.xml
Great article Michael. Thanks.