For example, your users may not be able to retrieve calendar information from either environment about whether or not someone they are trying to reach is busy or has some free time.
That problem may have its roots on the individual computer of a user or Exchange Federation may not be configured correctly.
To determine the source of the annoyance, you should ask your users if the problem is occurring in both desktop Outlook and the Outlook Web App for Office 365. If the snag appears in one Outlook version and not the other, then you might have a Federation-computer compatibility problem.
A possible cure for that snag is to reconfigure the Office 365 desktop applications on the computer. You can do that by going to the Microsoft Office 365 portal, accessing Resources, click downloads and then set up.
Once reconfigured, the free/busy service should return to the machine — as long as its running Outlook 2007 or 2010, since Office 365 works only with those versions of Outlook.
Sometimes your users may be able to access free/busy information from one environment but not another. Two possible sources for that problem are a misconfiguration of the Application Target URI or the sharing policies in the cloud and in the Exchange online tenant may not match.
To address that problem, you’ll want to go to the Exchange Management Shell and obtain information about your Office 365 domain. You can do that by issuing the command Get-FederationInformation followed by the default domain for Office 365.
After issuing the command, you should pay attention to two key values that appear on the screen: TargetApplicationUri and TargetAutodiscoveryEpr. Those settings are needed by the target domain to determine that the federation trust is configured correctly.
To see the current trust information configuration, use the command Get-OrganizationRelationship | FL. In that information, check the DomainNames section. It should include the name of your company service routing domain and its federated domain. If it doesn’t, you may have a problem with your Exchange Federation configuration.
If that’s the case, you’ll need to review the Microsoft Exchange Server Deployment Assistant to ensure that your configuration aligns with the steps outlined in the assistant and that your environment meets all the system requirements detailed there.
If the DomainNames section is copacetic, you’ll want to check the TargetApplicationUri and TargetAutodiscoveryEpr sections to make sure they jibe with the values that appear when you ran the Get-FederationInformation cmdlet.
A no-match means you’ll have to run this cmdlet: Set-OrganizationRelationship -Identity Name -TargetApplicationUri TargetApplicationUri -TargetAutodiscoverEpr.
After that, the problem may still persist. In that case, you want to ensure that the sharing policies in the cloud and in the Exchange Online tenant match. To do that, you should issue the following command from the Exchange Management Shell: Get-SharingPolicy | FL. When the results from that command appear on your screen, make note of the value in the Domains field.
Then you have to go to Exchange Online and issue the following command from the Windows PowerShell window: Get-SharingPolicy, and note the Domain value.
If the domain values match, you’re golden. If they don’t, you’ll need to use the Set-SharingPolicy cmdlet to configure the domains so they do match.
While troubleshooting these problems can be time-consuming, once they’re ironed out, your organization can realize the benefits of its hybrid Exchange setup, such as better control of your data.