While recently deploying a 2013 CU6 Hybrid Server for a 2007 Exchange customer moving to Office 365, I ran into an issue with Free/Busy federation that may have been lurking around Exchange 2013 Hybrid servers since CU5.

A short description of the issue:

Free/Busy information was not available for a 2007 mailbox on-premises when performing a lookup from a migrated mailbox in Office 365. I double checked that all Virtual Directories on Exchange 2013 were configured and that their External URL’s resolved correctly.  I also validated connectivity and finally ran through the Free/Busy Troubleshooting guide and it still provided no indication as to why Free/Busy fails.

Free/Busy lookups from an Exchange 2013 mailbox to a 2007 mailbox worked without a hitch. All Free/Busy lookups from mailboxes on-premise 2007 or 2013 were able to view Free/Busy information for mailboxes on Office 365.

A little background:

Before we dive deeper into the issue and its workaround, let’s spend some time understanding federation with Office 365.

The way Free/Busy or Calendar sharing works between Office 365 and an on-premises Exchange environment is by establishing a “trust” and a “relationship” (commonly seen as Federation Trust and Organization Relationship within Exchange) between Office 365 and on-premises Exchange 2013. This trust and relationship are automatically configured at both ends (Office 365 and on-premises) when running the Hybrid Configuration Wizard (HCW).

In a typical automatic configuration via the HCW, the on-premises Federation Information and Organization Relationship for on-premises with Office 365 and vice versa will look like the images below:

Federation Trust Information

  • On-Premises with Office 365

Federation Information on-premises

  • Office 365

Federation Information Online

Organization Relationship Information

  • On-Premises

Organization Relationship On-premises

  • Office 365

Organization Relationship Online

Free/Busy federation configuration on Office 365 points to on-premises Autodiscover services. This means there is a heavy dependency on the Autodiscover service functioning properly on-premises as it will be providing EWS connectivity information.

Back to troubleshooting:

Diving deeper into our issue, I captured some logs from an Outlook 2010 Client performing the free/busy lookups. These logs will provide retrieved information for the Exchange Availability service responding to Free/Busy requests. Below I have attached the logs from an Office 365 mailbox performing a Free/Busy lookup request of a 2007 on-premises mailbox.

Outlook Free/Busy Logs

Why?

As you can see, there is a “Proxy web request failed…The request failed with HTTP status 401: Unauthorized” error being provided by the remote availability service of the Exchange 2007 server when attempting to process the proxied availability request for Free/Busy information. The error does not occur when the 2013 server from the same site queries the 2007 server from mailboxes both residing on premises. The HTTP 401: Unauthorized error is coming from a request made by an Exchange Server in a separate “site”, in this case Office 365. Autodiscover on the Exchange 2013 Server (which should be the endpoint for Autodiscover requests) may be providing the EWS address of the Exchange 2007 server and Office 365 attempts a direct connection. This is by design as you saw above, the trust and relationship configuration was done automatically by the HCW and sets the Autodiscover URL as its target. Thus Office 365 attempts to talk to Exchange 2007 over its Free/Busy native authentication type WSSecurity (Web Services Security) and Exchange 2007 is unable to understand the request. Ultimately Exchange 2007 Availability Service fails the request with the 401 HTTP code.

Interestingly, a similar issue dealing with authentication was found during the resolution of another Exchange 2013 CU6 and Exchange 2007 co-existence environment regarding mailbox database unexpected failures. More information on that issue can be found here.

The workaround:

To mitigate this authentication type issue, we can change the way Office 365 performs these lookup operations and bypass querying Autodiscover for the EWS link. To do so, we have to manually set the EWS address it will use to handle requests by editing the TargetSharedEpr parameter*. The target is the Hybrid Server external URL for EWS and we will add a trailing “/WSSecurity” in its URL.

To manually enter the EWS address in this parameter, you will have to connect to your Office 365 tenant through PowerShell and edit its Organization Relationship properties as detailed below:

  1. Open the Exchange 2013 Management Shell
  2. Query your external URL for EWS using Get-WebServicesVirtualDirectory for the 2013 Server EWS website.
  3. Copy the External URL ( looks similar to “https://namespace.domain.tld/ews/exchange.asmx”)
  4. Connect to your Office 365 tenant using the Azure AD Module for Windows PowerShell.
  5. Modify your Organization Relationship TargetSharedEpr address using a command similar to the one below. For the TargetSharedEpr parameter, paste the URL extracted on Step 3 and add “/wssecurity” to the URL.
  6. Get-OrganizationRelationship | Set-OrganizationRelationship –TargetSharedEpr https://namespace.domain.tld/ews/exchange.asmx/wssecurity
  7. Verify your configuration took effect by running a “Get-OrganizationRelationship | fl” command. It should now look like this:

Organization Relationship Online fixed

*Note: Please do not attempt this workaround for 2010 Hybrid Servers. This value must be $null when establishing federation between Office 365 and Exchange Server 2010. You can see more information here.

This article is specifically for Hybrid Deployment with 2013 CU5-CU6 Hybrid Servers and an Exchange 2007 infrastructure.