A common problem that I have seen at client sites is the free/busy failure while looking up an on-premise mailbox from a migrated user. In this article, we will look at the common steps to troubleshoot the issue.
The first step to take is to go through the Microsoft article and make sure that everything is fine. In our case, everything checked out fine.
Second step is to run the Free/busy tests in the Microsoft Connectivity website.
In our case, everything was looking good, but the free/busy info came back with “No information” with the reason “The external recipient’s server could not be determined”.
The customer had a TMG 2010 array which was publishing all Exchange services including Autodiscover and there was number of network devices in between TMG & internal Exchange servers. We spent a lot of time checking this out, but couldn't find anything and went for a workaround at the end.
When doing a lookup for free/busy information, the Exchange servers within Office 365 will do a lookup to https://autodiscover.domain.com/autodiscover/autodiscover.svc/WSSecurity, assuming that autodiscover.domain.com is the published AutoDiscover url.
Rather than letting Autodiscover figure out the endpoint, we stamped the TargetSharingEPR attribute in Organizational Relationship (Exchange Online) to point to the externally published EWS url, say https://mail.domain.com/ews/exchange.asmx.
Once the TargetSharingEPR was set, free/busy information started to flow in fine.
Cloud Architect & Blogger with interests in Office 365, Enterprise Mobility & Security and Azure. I am active on Experts Exchange & TechNet forums and I am a technical author for SearchExchange. Follow me on Twitter, LinkedIn, Facebook or Google+ for the latest updates. For consultancy opportunities, drop me a line.