Editor’s note: The following post was written by Office 365 MVP Loryan Strant and Exchange Server MVP Michael Van Horenbeeck

In this blog post Exchange Server MVP Michael Van Horenbeeck and Office 365 MVP Loryan Strant will attempt to bridge the divide between the on-premises world and the cloud – and why sometimes it doesn’t always work as we expect.

A great feature of Exchange Server 2010 and 2013 is the ability to share calendar Free/Busy information with users outside of your organisation. This is also the case with Office 365 – and in fact is even easier for users to do.

However in the situation of a hybrid between Exchange Server and Exchange Online there can be a very small caveat that can cause confusion.

Before going into this let’s take a few steps back.

What is Exchange federation?

There are a number of federation types utilised in Microsoft technologies and specifically Office 365.  Federation ultimately is the creation of a “trust relationship” between two organisations so that information can be shared between them.

Similar to Active Directory Federation Services sharing and security tokens and identity information, Lync federation allowing separate organisations to see each other’s presence, setting up a federation between Exchange environments allows for calendar Free/Busy information to be exchanged (pardon the pun) between them.

Ultimately this is useful for people in different organisations to see each other’s calendar availability and schedule a meeting without having to correspond a great deal beforehand. We’ve all been in that situation where scheduling a meeting with more than one person in a different organisation – it’s not easy. Exchange calendar federation fixes that!

What it’s used for and how it works

While a hybrid effectively joins Exchange Server to Exchange Online to appear as a single environment for a single business – it is important to remember that these are separate environments and that the federation is simply providing a mechanism for information to flow simply and easily between them.

Exchange federation is also used to allow separate businesses to share Free/Busy information between each other. This was covered in a previous blog by Loryan Strant in the early days of Office 365: http://blogs.msdn.com/b/mvpawardprogram/archive/2011/08/08/mvps-for-office-365-establishing-calendar-sharing-between-office-365-customers.aspx

How does Exchange federation work in a hybrid environment

As described earlier, Exchange federation is used to exchange information between two environments. Prior to Exchange Server 2010 if a company wanted to share calendar information with another company, it had to go through a series of steps to set it up. One of these steps was to exchange account information for a service account which would be used to retrieve the requested information. Because this is not always desirable, Microsoft developed a service called the “Microsoft Federation Gateway”, hereafter referred to as the MFG.

The MFG acts as an authentication broker between both environments and explains where the term “Exchange federation” comes from. Requests from one organization to the other are “authenticated” through the MFG, and therefore these requests are federated. It does not matter if an organization wants to federate with a remote organization or with its hybrid counterpart in Office 365, the principle and how it works is the same. In fact, Exchange treats its hybrid counterpart as if it would be a remote organization which – to be technically correct – it is.

In order to be able to use this free MFG service from Microsoft, one has to setup a ‘trust’ with the MFG. Usually, this is something which has to be done manually. But in case of a hybrid deployment, the Hybrid Configuration Wizard automatically takes care of this.

Next to having a trust with the MFG, an organization has to setup a “relationship” with the other organization (or hybrid counterpart) by means of creating an Organization Relationship. This organization relationship is an object in Exchange which provides Exchange with more information on what URI to contact the other Exchange organization and on what information can be exchange between both environments.

In a hybrid deployment both the Exchange on-premises environment and Exchange Online have an organization relationship which look similar to what you see in the following image:

The on-premises organization has an organization relationship with information which points to Office 365 and the Exchange online organization has information about the on-premises deployment.

Now, let’s have a high-level look at how Exchange uses all these components to query Free/Busy information in a hybrid deployment. Take a look at the following image:

1. User ‘Loryan’ requests Free/Busy information for Michael’s mailbox (michael@contoso.com). This request is made at the on-premises Exchange server.
2. The Exchange server will lookup michael@contoso.com and find a mail-enabled user object. This object has a targetAddress attribute which points to Michael’s mailbox in Office 365 (michael@contoso.mail.onmicrosoft.com).
3. The Exchange server will now lookup its organizational relationships and verify if it has one for contoso.mail.onmicrosoft.com
4. Now, the Exchange server will contact the Microsoft Federation Gateway and request a authentication token for contoso.mail.onmicrosoft.com
5. The MFG sends back a token because contoso.com has a trust relationship with the MFG.
6. The on-premises Exchange server now uses the information it obtained from the Organization Relationship to do an Autodiscover request for contoso.mail.onmicrosoft.com in order to retrieve the remote Exchange Web Services endpoint it should connect to. It then uses the address it received to send the Free/Busy request to.
7. Exchange online will first check whether the MFG token which the Exchange on-premises has sent across with is valid before accepting the Free/Busy Request.
8. Exchange online will also verify its organization relationship so that it knows what information it is allowed to return
9. Exchange online queries Michael’s mailbox for the Free/Busy information
10. Exchange online sends back the Free/Busy information to the on-premises organization
11. The on-premises Exchange server sends back the request Free/Busy information to Loryan

As you can see, there are quite some ‘moving parts’ in requesting a remote user’s Free/Busy information. The same process is applied when an Exchange Online user queries the Free/Busy information for an on-premises user.

External organisational Free/Busy constraints in Exchange hybrid scenario

Now that we know how Exchange queries Free/Busy information, let’s have a look at the following scenario.

Contoso and Paradyne wish to share Free/Busy information with one another. In order to do so, they decide to setup everything that is necessary to make this work using Exchange Federation. Paradyne, however, is also enrolled in a hybrid deployment. In this particular scenario, Contoso users will not be able to request Free/Busy information for user in Paradyne’s organization if they are Exchange online users.

Take a look at the following scenario in which Loryan – working for Contoso – tries requesting Free/Busy information for Michael whose mailbox is hosted in the Exchange Online tenant of Paradyne:

1. User ‘Loryan’ requests Free/Busy information for Michael’s mailbox (michael@paradyne.com). This request is made at the on-premises Exchange server.
2. Given that the Exchange server isn’t authoritative or otherwise configured for paradyne.com it will lookup whether it has an organization relationship for that domain.
3. Now, the Exchange server will contact the Microsoft Federation Gateway and request a authentication token for paradyne.com
4. The MFG sends back a token because there’s a trust relationship with the MFG.
5. The on-premises Exchange server now uses the information it obtained from the Organization Relationship to do an Autodiscover request for paradyne.com in order to retrieve the remote Exchange Web Services endpoint it should connect to. It then uses the address it received to send the Free/Busy request to.
6. The Paradyne Exchange server will first check whether the MFG token which the Exchange on-premises has sent across is valid before accepting the Free/Busy Request.
7. The Paradyne Exchange server will also verify its organization relationship so that it knows what information it is allowed to return.
8. The Exchange server now looks up the recipient Michael@paradyne.com and discovers that object has a targetAddress stamped to it, which points to the cloud.
9. The Paradyne Exchange server now sends back that information to the Exchange server at Contoso.

There’s no 10^th bullet. The Contoso Exchange server now receives back information which it doesn’t know how to handle. In fact, even if Exchange would know how to handle the information (which isn’t Free/Busy information but rather a redirect), there would still be an issue because the Contoso Exchange organization doesn’t have an organization relationship with the Exchange Online tenant of Paradyne. So, as a result, this scenario is sort-of broken.

Workaround

With Office 365 becoming more and more popular, it’s more likely you will encounter such a scenario sooner rather than later. As long as the remote organization is an Exchange Online-only deployment, everything will work fine. In the case where the remote organization has a hybrid deployment, there’s one thing you can do: create (additional) separate Organization Relationships to and from the remote organization’s Exchange Online tenant. This allows you to bypass the limitation we discussed earlier. However, in order to query those user’s Free/Busy information, you would also need to use their target addresses, e.g. michael@paradyne.mail.onmicrosoft.com instead of their regular email address (michael@paradyne.com).

This workaround is far from perfect, but will at least allow you to query Free/Busy information for the remote organization’s Exchange Online users. The fact that you will need to know what users are hosted in Exchange online and what their targetAddresses are, is just something you’ll have to learn with until Exchange gets updated with the code required to handle these ‘redirects’.

About the authors

Loryan Strant is the Founder of Paradyne and a high profile ambassador for Microsoft Office 365. Drawing on his technical know-how and business brains, Loryan makes a habit of solving business problems through the application of new technology.  The application of Office 365 for business is his latest success story.

Considered a thought-leader in his field, Loryan is regularly called upon by Microsoft and other leading organisations to deliver talks on best practice, cloud security and how to capitalise on cloud technology for excelled business performance. His expertise and plain-English explanations have been consolidated into a comprehensive guide for businesses that Loryan co-authored and subsequently published; “Microsoft Office 365: Exchange Online Implementation and Migration”.

A highly-respected contributor to industry magazines and blogs, Loryan’s technical wisdom is quoted regularly in Microsoft marketing materials and technical journals. In 2011, Loryan was awarded the Microsoft Office 365 MVP Status (Most Valuable Professional), recognising him as a force to be reckoned with, amongst technical communities around the world.  Follow Loryan on Twitter or check out his blog.

==========

Michael Van Horenbeeck is a Microsoft Certified Solutions Master and Exchange Server MVP from Belgium, specialized in Exchange, Office 365, Active Directory and a bit of Lync. Michael has been active in the industry for 12 years and developed a love for Exchange back in early 2000. He is a frequent blogger, member of the Belgian Unified Communications User Group ‘Pro-Exchange’ and also a regular contributor to The UC Architects podcast. In addition to that, he frequently speaks at various international conferences and writes articles for several tech websites. You can follow Michael on twitter (@mvanhorenbeeck) or through one of his blogs on michaelvh.wordpress.com and www.pro-exchange.be

About MVP Monday

The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager, formerly known as MVP Lead, for Messaging and Collaboration (Exchange, Lync, Office 365 and SharePoint) and Microsoft Dynamics in the US. She began her career at Microsoft as an Exchange Support Engineer and has been working with the technical community in some capacity for almost a decade. In her spare time she enjoys going to the gym, shopping for handbags, watching period and fantasy dramas, and spending time with her children and miniature Dachshund. Melissa lives in North Carolina and works out of the Microsoft Charlotte office.