In an earlier article I explained How to Configure Exchange 2010 SP1 Federation. Buried within that article are the steps to solve federation issues that stem from Exchange 2003 migrations. Here, I’m listing just those steps.
When federation doesn’t work in one or both directions, you may see any of the following errors in Outlook or Outlook Web App:
No Information (Error code: 5009)
The attendee’s server couldn’t be found. For more information, please contact your helpdesk. (Error code: 5039)
No information. No free/busy information could be retrieved. The external recipient’s server could not be determined. Contact your administrator.
Here’s how to fix it:
- Ensure that the ExternalURL property is set for the Exchange Web Services virtual directory for the federated domains. Use the following cmdlet to check:
Get-WebServicesVirtualDirectory | fl name,server,InternalURL,ExternalURL
If the ExternalURL property is not set, remote domains will be unable to connect to your CAS servers to get federated free/busy information. Set it using the following cmdlet:
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalURL https://mail.companyabc.com/EWS/Exchange.asmx
Replace mail.companyabc.com with the same external FQDN used by that company to access OWA.
Test federation again. That may be all that you needed to do.
- Configure the TargetSharingEPR property of the organization relationship on the remote domain that cannot view federated free/busy information. Usually this is only needed on Exchange 2003/2010 mixed environments or when federating with Office365. Run the following cmdlet to configure it:
Set-OrganizationRelationship “CompanyABC” -TargetSharingEpr https://mail.companyabc.com/EWS/Exchange.asmx/WSSecurity
Test federation again from Outlook or OWA. You can also use the Test-FederationTrust and Test-OrganizationRelationship cmdlets.
BTW, neither of these changes require that you run IISReset – they go into effect immediately.