After configuring our hybrid environment and moving a couple of test mailboxes to the Cloud, I found out that none of our migrated mailboxes can see the Free/Busy information for people that have mailboxes on-prem. This is a tricky problem since the Free/Busy information works for both: users that have mailboxes on-prem and when a user that has mailbox on-prem tries to access a Calendar in Outlook for a user that has a mailbox in the Cloud. I’ve tried to solve this problem using Google since this is a very common problem. I’ve even checked Microsoft article https://support.microsoft.com/en-us/help/2555008/how-to-troubleshoot-free-busy-issues-in-a-hybrid-deployment-of-on-premises-exchange-server-and-exchange-online-in-office-365 and made sure that everything works. The funny thing was that even though Outlook had problems retrieving the Free/Busy information, every time I tried the Exchange Connectivity test from the Office365 tab that you can find here https://testconnectivity.microsoft.com/ I received a successful attempt and I could see the appointments for the on-prem user. I’ve also tried the Outlook autodiscover test from the Exchange server tab and this test also completed successfully.
We have a pretty complex Exchange environment. We have 4 Exchange servers on 3 locations. Three of the servers form a DAG where we have 10 Exchange Databases. Three of the servers are also part of an CAS array. All our Exchange servers are Exchange 2010 with SP3 and the latest CU installed. I’ve configured the Hybrid environment using Microsoft’s hybrid configuration wizard and it also completed without reporting any errors. I’ve enabled the hybrid configuration only for two domains from the 10 that are accepted on our Exchange servers. Both domains are of course federated with Office365.
I’ve actually opened a case with Microsoft Support about this problem and they provided an online troubleshooter for this problem. You can find it here: https://support.microsoft.com/en-us/help/10092/troubleshooting-free-busy-issues-in-exchange-hybrid-environment
I’ve started the troubleshooter and choose the problem I had: My Cloud user can’t see free/busy for an on-premises user.
We tested the free/busy information on-prem and decided it works.
We also verified that the autodiscover is resolving to our on-prem Exchange CAS server. Just to be safe we verified using both methods.
We connected to Exchange Online (you can find the guide here: https://technet.microsoft.com/library/jj984289(v=exchg.160).aspx) and tested the Organization Relationship. There was no need to change everything since everything was set up correctly.
The next steps should be done on all Exchange Servers that are members of the CAS array.
We checked the IIS logs on both CAS servers and searched for the autodiscover part and didn’t find any errors.
We also checked the IIS logs for exchange.asmx/wssecurity.
We’ve checked the EWS external URL and it was already setup correctly and accessible from the internet.
WSSecurity was enabled on our Autodiscover directory and on our EWS directory.
We’ve checked the Handler Mappings on our EWS directory in IIS on all of our CAS servers and svc-Integrated was not missing.
The solution for our problem was on Step 10. We checked all CAS members for the svc-Integrated handler mapping for the Autodiscover endpoint and on one of them a lot of the handler mappings were missing. There is a link in the troubleshooter for resolving this error by doing a re-register of the dlls for .NET 3.0, but we chose a different method. We knew that there is nothing wrong with our other endpoints so we decided to re-create the Autodiscover endpoint on the server that had a problem.
- First we made a backup of the settings for this endpoint using this powershell cmdlet:
Get-AutodiscoverVirtualDirectory -Identity “<name_of_your_exchange_server>\Autodiscover (Default Web Site)” | FL
The parameters you need to write down are: BasicAuthentication, WindowsAuthentication, WSSecurityAuthentication, Path, InternalUrl, ExternalUrl and WebSiteName - After that we removed the virtual directory using this powershell cmdlet:
Remove-AutodiscoverVirtualDirectory -Identity “<name_of_your_exchange_server>\Autodiscover (Default Web Site)” -DomainController <name_of_your_domain_controller> - To create the virtual directory you can use this powershell cmdlet:
New-AutodiscoverVirtualDirectory -BasicAuthentication $true -WindowsAuthentication $true -WSSecurityAuthentication $true -Path “the_path_to_your_Exchange_Autodiscover_folder_on_your_disk” -InternalUrl “the_url_for_your_autodiscover_service_that_is_reachable_internally” -ExternalUrl “the_url_for_your_autodiscover_service_that_is_reachable_externally” -WebSiteName “Default Web Site” -DomainController <name_of_your_domain_controller> - Do an iisreset on the server you just created the Autodiscover virtual directory.
After we recreated the virtual directory we tried to access the Free/Busy Information from a cloud mailbox for a user that is on-prem and immediately got a success and were able to see the info.
I didn’t reach the end of the troubleshooter since this was my problem but if nothing of the above solves your problem you can try to reach the end of the troubleshooter.
Some of the blogs I’ve found on the internet suggest you do a IIS reset on all your CAS servers but unfortunately that didn’t do the trick for me.