Troubleshoot free/busy issues in Exchange hybrid environment
Article
Applies to:
Microsoft 365
Who is it for?
Tenant administrators. Elevated access is required for many of the steps.
How does it work?
We'll begin by asking you the issue you are facing. Then we'll take you through a series of troubleshooting steps that are specific to your situation.
Estimated time of completion:
30-60 minutes.
Welcome to the hybrid environment free/busy troubleshooter
Select the option that best describes the issue that you are facing:
Note
If you want to review how free/busy works in a hybrid deployment, select the I want to better understand how Hybrid Free/Busy is supposed to work option.
On-premises Exchange server version in your environment
To better understand how Hybrid Free/Busy is supposed to work, review the following flowcharts. Select the version of the on-premises Exchange server that matches your environment:
Sign in to an on-premises user's mailbox and then try to view the Free/Busy for another on-premises user. This test is to verify that you do not have any issues with availability information retrieval within your on-premises environment.
This troubleshooter is used to diagnose free/busy issues in a hybrid environment. This doesn't seem to be your immediate issue. After the on-premises free/busy issues are addressed, restart this troubleshooter.
For information about how to troubleshoot some common on-premises free/busy issues, see Troubleshooting Free/Busy Information for Outlook 2007.
Cloud user can't see On-premises user's Free/Busy
Use the following methods to verify that Autodiscover can be resolved from an external source and that the Firewall is open.
Method 1: Verify that Autodiscover is resolving to the on-premises Exchange CAS server
From an external computer, open Command Prompt and type the following commands and press ENTER after each command:
NSLookup
autodiscover.<Your_Domain.com>
In the response to the command, the "Address" value should be the external IP of the on-premises Exchange CAS server. For example: Name: autodiscover.contoso.com Address: 38.96.29.10
Method 2: Verify that you can send an Autodiscover POST request to potential Autodiscover URLs
Cloud user cannot see On-premises user's Free/Busy (if issue isn't resolved)
Verify that the autodiscover endpoint is pointing to the on-premises Exchange Hybrid Server(s).
Check the IIS logs on the Exchange Hybrid server to verify that the Autodiscover POST request is being received by this server:
On the Exchange Hybrid Server, select Start > Run, type %SystemDrive%\inetpub\logs\LogFiles, and then press ENTER.
Open the W3SVC1 folder, then open the most recent IIS log file.
Search for Autodiscover.
The following screenshot shows an example of the Autodiscover POST request on IIS log:
If you do not see any entry for Autodiscover in your on-premises Exchange hybrid deployment server, the firewall may be pointing to a wrong CAS server.
Cloud user cannot see On-premises user's Free/Busy (if issue still not resolved)
Verify that the Microsoft Exchange Web Services (EWS) is resolvable and there are no firewall issues.
Check IIS logs on the Exchange 2010/2013 CAS server(s) to confirm that Web Services request is being received by this server:
On the Exchange 2010/2013 CAS server, select Start > Run, type %SystemDrive%\inetpub\logs\LogFiles, and then press ENTER.
Open the W3SVC1 folder, and then open the latest IIS log file.
In the latest IIS log file, search for exchange.asmx/wssecurity. The following screenshot shows an example of the request in the IIS log:
If you do not see any entry for exchange.asmx/wssecurity in your on-premises Exchange 2010/2013 hybrid deployment server, the firewall may be pointing to a wrong CAS server, or you may have pre-authentication configured on the firewall. For information about how to bypass firewall pre-authentication, see Configure Forefront TMG for a hybrid environment.
If a value must be changed, use the set-OrganizationRelationship cmdlet to fix the property. For more information about syntax and options, see Set-OrganizationRelationship.
For On-Premises settings
On the Exchange 2010/2013 CAS, run the following command in the Exchange Management Shell:
Get-OrganizationRelationship -Identity "On Premises to Exchange Online Organization Relationship"
If a value must be changed, use the set-OrganizationRelationship cmdlet to fix the property. For more information about syntax and options, see Set-OrganizationRelationship.
Your Exchange 2003 user cannot see cloud user's free/busy (if issue not solved)
Verify that there is no hard-coded Public folder routing that would prevent the legacy Free/busy request from succeeding.
Note
This is not a common issue.
Verify that the ms-Exch-Folder-Affinity-List attribute on the Exchange Server 2003 properties has Exchange 2010 ObjectGUID with the lowest cost (The format of this property is as follows: {guid of server},cost).
On a Domain Controller, select Start, select Run, type adsiedit.msc, and then select OK.
Right-click ADSI Edit, and then select Connect to.
On Select a well known Naming Context, select Configuration, and then select OK.
Expand Configuration > Services > Microsoft Exchange > First Organization > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers.
Right-click Exchange 2010 server, and then select Properties.
Copy the objectGUID value and then paste it in a notepad text file.
Move to Configuration > Services > Microsoft Exchange > First Organization > First Administrative Group > Servers.
Right-click Exchange Server 2003, and then select Properties.
Verify that ms-Exch-Folder-Affinity-List value is set with Exchange 2010 objectGUID. If the Exchange 2010 objectGUID is not listed on ms-Exch-Folder-Affinity-List, you can add it by using the format: {guid of server},cost.
Your Exchange 2003 user cannot see cloud user's free/busy (if issue not resolved)
Verify that the recipient object on the on-premises server has the correct LegacyExchangeDN configured.
Every cloud mailbox will have a corresponding on-premises Mail enabled object. For this kind of Free/busy query, we use the LegacyExchangeDN to route our request to the Proper Public folder server. To make sure that this value is accurate, follow these steps:
On the Exchange 2010 server, run the following command in the Exchange Management Shell:
Get-RemoteMailbox Username |fl LegacyExchangeDN
where username is the name of the cloud user that you are trying to see free/busy information for.
In the results, verify that the External (FYDIBOHF25SPDLT) is in the path. For example, the results should show the path as follows:
Your Exchange 2003 user cannot see cloud user's free/busy (if issue isn't resolved)
Verify Permissions on Public folder.
To use the Exchange 2010 Public Folder Management Console to change the client permissions for the External (FYDIBOHF25SPDLT) free/busy replica, follow these steps:
Start the Exchange 2010 Exchange Management Console.
In the console tree, select Toolbox.
In the result pane, select Public Folder Management Console, and then in the action pane, select Open Tool. The Public Folder Management Console appears.
In the Public Folder Management Console, in the action pane, select Connect to Server.
In Connect to server, select Browse to view a list of the available Mailbox servers that contain a public folder database.
In Select Public Folder Servers, select the Exchange 2010 server. Select OK, and then select OK.
In the Public Folder tree, move to System Public Folder > SCHEDULE+ FREE/BUSY.
In the Result pane, right-click EX:/O=FIRST ORGANIZATION/OU=EXTERNAL (FYDIBOHF25SPDLT), and then select Properties.
On the Permissions tab, confirm that Edit all permission level is selected for the **Default user:
Your Exchange 2003 user cannot see cloud user's free/busy (if issue is still not solved)
Is the arbitration mailbox missing or corrupted?
The Arbitration mailbox can be edited by using ADSIEdit. The federated.email account should be located in the default users container of Active Directory for the Exchange 2010 domain.
Use one of the following options:
Use adsiedit.
Connect to the default naming context in Active Directory.
Browse to the Users container and view the properties of the federated email account.
Change the proxyaddress attributes of the account to either have ONE of the SMTP addresses already federated, or add the already existing proxy address namespace present into the federation trust.
From the Exchange Server 2003 open Active Directory Users and Computers.
Move to the Users container and right-click the FederatedEmail account - then select Properties.
If you go to the email addresses tab that you can add another proxy address to match the federation namespaces already configured, or add the pre-existing primary SMTP namespace to the federation trust.
Your Exchange 2007 user can't access cloud user's free/busy
Check the availability address space to make sure that it has the correct settings. This might be a misconfiguration of the AvailabilityAddressSpace. Check that ProxyURL value on AvailabilityAddressSpace configuration matches the InternalURL of the Exchange 2010/2013 CAS Web Service virtual directory. To do so, follow these steps:
On the on-premises server, run the following commands in Exchange Management Shell:
If the ProxyURL and InternalURL values do match, make sure that you can access the URL from the Exchange 2007 CAS server. To do this, move to ProxyURL of the AvailabilityAddressSpace from CAS 2007. Authenticate with the Exchange 2007 source mailbox credential. The expected result is as follows:
Note
The InternalURL of the Exchange 2010/2013 CAS Web Service virtual directory should differ from Exchange 2007 CAS Web Service virtual directory.
Exchange 2010/2013 user cannot see cloud user's free/busy
Sign in to an on-premises user's mailbox and then try to view the Free/Busy for another on-premises user. This test is to verify that you do not have any issues with availability information retrieval within your on-premises environment.
Exchange 2010/2013 user cannot see cloud user's free/busy (Error Code 5039)
If you must have web proxy settings in your environment, verify that the on-premises Exchange 2010 and Exchange 2013 servers are set to use it.
On the on-premises Exchange 2010 and Exchange 2013 server(s), run the following command in the Exchange Management Shell:
Get-ExchangeServer | fl InternetWebProxy
In most environments the results will be blank. However, if you have an outgoing proxy in your on-premises environment you may have to configure the correct proxy settings.
To resolve this issue, run the following command, where the address and port number http://192.168.5.56:8080 is replaced with your server address and port number:
Exchange 2010/2013 user cannot see cloud user's free/busy (if issue not resolved)
Make sure that the time set on your server is not inaccurate by more than 5 minutes. If the server time is more than 5-minutes difference from real time, the communications with the federation gateway become invalid. This causes free/busy to fail.
Exchange 2010/2013 user cannot see cloud user's free/busy (Error Code 5016)
Determine whether the correct target address is specified on the MEU on-premises. Every Cloud Mailbox will have a corresponding on-premises object. This object must have the correct remote routing address (also known as the target address) specified. The remote routing address should contain a domain name similar to TenantName.Mail.OnMicrosoft.com.
To verify that the remote routing address is set, follow these steps:
On the Exchange 2010 server or Exchange 2013 server, run the following command in the Exchange Management Shell:
If a value must be changed, use the set-OrganizationRelationship cmdlet to fix the property. For more information about syntax and options, see Set-OrganizationRelationship.
For on-premises settings
From the Exchange 2010/2013 CAS, run the following command in Exchange Management Shell:
Get-OrganizationRelationship -Identity "On Premises to Exchange Online Organization Relationship"
If a value must be changed, use the set-OrganizationRelationship cmdlet to fix the property. For more information about syntax and options, see Set-OrganizationRelationship.
Exchange 2010/2013 user cannot see cloud user's free/busy (if issue isn't solved)
Verify that a token can be created that has test-federation trust.
From the on-premises environment, verify that you can retrieve a delegation token that will be used for Free/busy authorization:
Open the Exchange Management Shell from the on-premises Exchange 2010 or 2013 server.
Run the command Test-FederationTrust -UserIdentity User@company.com -verbose where User is the on-premises user who has issues viewing the cloud user's free/busy information.
The output should show success for every test. If there is a failure, use the Hybrid Configuration Wizard again to try to reset the federation trust.
On-premises Free/busy is not working for 2010/2013
This guide is used to troubleshoot Hybrid free/busy issues. Based on you answers, you have on-premises issues. For information about how to troubleshoot common on-premises free/busy issues, see Troubleshooting Free/Busy Information for Outlook 2007.
Contact support
Sorry, we cannot resolve an unidentified issue by using this guide. For more help to resolve this issue, go to Microsoft Support.
As a Windows Server hybrid administrator, you integrate Windows Server environments with Azure services and manage Windows Server in on-premises networks.