User can't view free/busy information for a remote user in a hybrid deployment of on-premises Exchange Server and Exchange Online in Office 365

You have a hybrid deployment of on-premises Microsoft Exchange Server and Microsoft Exchange Online in Microsoft Office 365 in which your hybrid deployment server is running Exchange Server 2010 Service Pack 2 (SP2). However, users can’t view free/busy information for a remote user. When a user tries to view free/busy information for a remote user, the free/busy information isn’t displayed. Instead, the user may experience one or more of the following symptoms:
  • The free/busy information for the remote user is displayed as number sign (#) characters in the Calendar.
  • In Outlook Web App, "error 5037" is displayed.
  • The Microsoft Outlook <FileName>-fb.log and <FileName>-as.log files contain an error message that resembles the following:
    <FreeBusyResponse><ResponseMessage ResponseClass="Error"><MessageText>The caller does not have access to free/busy data.</MessageText><ResponseCode>ErrorNoFreeBusyAccess</ResponseCode><DescriptiveLinkKey>0</DescriptiveLinkKey><MessageXml><ExceptionType
For example, an Office 365 user can’t view free/busy information for an on-premises user. However, other users can view free/busy information for that same on-premises user.
This issue occurs if the domain name for the Simple Mail Transfer Protocol (SMTP) address of the user who is trying to view the free/busy information isn’t included among the domain names in the organization relationship. For example, when you run the Test-OrganizationRelationship cmdlet, the following output is displayed:
RunspaceId : a6c3799f-2ecd-4d79-ae4b-6c470ddd1dee
Identity :
Id : LocalFederatedDomainsAreMissingFromTheRemoteOrganizationRelationsipDomains
Status : Warning
Description : There are locally federated domains that aren't present in the list of domains for the
remote organization relationship object.
IsValid : True
This occurs if the SMTP domain wasn't manually added to the organization relationship. This may also occur if the following conditions are true:
  • The Office 365 user account was created before you upgraded the on-premises environment to Exchange Server 2010 SP2.
  • You used the Hybrid Configuration wizard in Exchange Server 2010 SP2 in the on-premises environment to set up the federation trust.
For example, the domain name of the Office 365 user is In this scenario, the Office 365 user account doesn't have as one of its proxy addresses. The request to the on-premises environment uses instead of for the Office 365 user account. The request is rejected because the organization relationship in the on-premises environment doesn't have added to it.
To resolve this issue, edit the organization relationship in the on-premises environment to include the SMTP domain of the user who is experiencing the issue. To do this, use one of the following methods.

Method 1: Use Exchange Management Console

  1. On the on-premises Exchange server, open Exchange Management Console, and then click Organization Configuration under Microsoft Exchange On-Premises.
  2. Click the Organization Relationships tab, and then view the properties of the organization relationship.
  3. Click the External Organization tab, type the federated domain name in the Federated domains of the external Exchange organization box, and then click Add.
  4. Repeat step 3 for each domain that you want to add.
  5. Click OK.

Method 2: Use Exchange Management Shell

  1. On the on-premises server, open Exchange Management Shell.
  2. Set up the organization relationship as a variable. For example, run the following command

    $OrgRel = Get-OrganizationRelationship Contoso
  3. Add the additional domain names that you want to the variable. For example, run the following command:

    $OrgRel.DomainNames += ""
  4. Update the organization relationship by using the new domain names value. For example, run the following command:

    Set-OrganizationRelationship $OrgRel.Name -DomainName $OrgRel.DomainNames
To help identify the issue in Office 365, follow these steps:
  1. Connect to Exchange Online by using remote PowerShell. For more information about how to do this, go to the following Microsoft website:

  2. Compare the SMTP address of the user with the organization relationship. To do this, run the following command:

    if ( (Get-CloudOrganizationRelationship).DomainNames -contains (Get-Mailbox user).PrimarySmtpAddress.Domain) { write-host "The domain was found" -ForegroundColor Green } else { write-host (Get-Mailbox user).PrimarySmtpAddress.Domain "was not found" -ForegroundColor Yellow}
    Note You can also compare each domain that is listed in the accepted domains with the domain names that are in the organization relationship. To do this, run the following command:

    Get-AcceptedDomain | ForEach-Object { if ( (Get-CloudOrganizationRelationship).DomainNames -contains $_.DomainName) { write-host $_.DomainName "was found" -ForegroundColor Green } else { write-host $_.DomainName "was not found" -ForegroundColor Yellow<AngularNoBind>}}</AngularNoBind>
Still need help? Go to the Office 365 Community website.

The link below will navigate your web browser to a guided tutorial which will help you solve your problem

Start guided walkthrough.

Article ID: 2667844 - Last Review: 08/21/2015 10:13:00 - Revision: 17.0

  • Microsoft Exchange Online
  • Microsoft Exchange Server 2010 Standard
  • Microsoft Exchange Server 2010 Enterprise
  • Microsoft Exchange Server 2010 Service Pack 2
  • o365 o365a o365e o365022013 o365m hybrid gwt guided walk through kbtshoot KB2667844