The Hybrid Mesh
Published Oct 17 2016 10:30 AM 57.7K Views

During the recent Microsoft Ignite conference I heard questions related to hybrid and partner free/busy relationships quite often, so I wanted to write about it. This scenario applies to companies with one or more external free busy relationships configured. For instance, you could have two or more companies on-premises sharing free/busy between each other. image Then one fine day, one of the companies deploys a hybrid configuration and moves mailboxes to Office 365; in our example, it is Tailspin. Suddenly, Contoso and Fabrikam users find availability information is not showing for the Tailspin mailboxes moved to Exchange Online. image This blog post discusses why free/busy is broken and what you can do about it.

A bit of history of the Availability service

For many years now we have allowed different organizations to share calendar availability between each other. It really started with the Availability Address Space feature in Exchange 2007, later moving on to the Microsoft Federation Gateway (Now called the Azure Authentication System) with Organization Relationships in Exchange 2010, 2013, and 2016. This set of features allows an organization to share limited free/busy details with another organization without an AD Trust in place. The main point of this article is to understand what to do when one of these organizations deploys a hybrid configuration with Office 365. Will free/busy sharing still work? However, before we get into why this could be a problem when you deploy a hybrid configuration, we need to make sure you have a general understanding of how the cross-organization free/busy works.

So, what does a typical configuration look like?

In most scenarios, it is just a matter of configuring a Federation Trust and an Organization Relationship using the Exchange Admin Center (EAC). The following is a diagram of the basic configuration between two organizations. image Now let’s look at how a cross organization availability requests works. For this example, we will assume a user Bill (from Contoso) is looking up a user Ted’s (from Tailspin) free/busy information. image 1. Bill creates a meeting request and adds Ted as an attendee. 2. The Exchange server in Contoso determines (usually based on target address of a mail-enabled user) that Ted is not local and has a domain name of TailspinToys.com set as the target address. 3. The Availability Service on the Exchange server in Contoso then checks to see if there is a path for it to find the free/busy information for TailspinToys.com.
  • First we check if we have OAUTH configured by looking for an Intra Organization Connector with the domain name of TailspinToys.com (assuming the Exchange server is 2013 or later).

Note: OAUTH is not a supported way to see free/busy between two on-premises organizations.

  • If that does not exist, we look to see if an Organization Relationship is configured by looking for the domain name of TailspinToys.com in the Organization Relationship.
  • If that also does not exist, we then look for the domain name TailspinToys.com as an Availability address space.
4. Assuming we used the typical options, we would have an Organization Relationship and a Federation trust (second option above). The ApplicationURI in the Organization Relationship is set to FYDIBOHF25SPDLT.TailspinToys.com, which is a unique identifier for the Tailspin trust in the Azure Authentication System (formerly known as the Microsoft Federation Gateway). A request is then made to the Azure Authentication System for a delegation token that will be accepted by Tailspin. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso sends an Autodiscover and eventually an EWS request for the availability information. 6. The Tailspin Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested free/busy data.

So now let’s say that Tailspin Toys deploys a hybrid configuration…

Let’s continue with the Contoso and Tailspin example. What would happen if Tailspin deployed a hybrid configuration and moved Ted to Office 365? image 1. Bill creates a meeting request and adds Ted as an attendee. 2. The Exchange server in Contoso determines the user Ted is not local and has a domain name of TailspinToys.com. 3. The Availability Service on the Exchange server in Contoso checks to see if there is a path for it to find the free/busy information for TailspinToys.com.
  • First we check if we have OAUTH configured by looking for an Intra Organization Connector with the domain name of TailspinToys.com.
  • If that does not exist, we look to see if an Organization Relationship is configured by looking for the domain name of TailspinToys.com in the Organization Relationship.
  • If that also does not exist, we then look for the domain name TailspinToys.com as an Availability address space.
4. Like in the previous example, our configuration utilizes the Organization Relationship and Federation Trust. A request is then made for a delegation token that will be accepted by Tailspin. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso sends an Autodiscover and eventually an EWS request for the availability information. 6. The Tailspin Exchange server validates the token provided by the Azure Authentication System and once confirmed, tells the Contoso server that the user is moved. The result is that the Exchange server in Contoso returns to Bill’s client no information (hash marks) instead of free/busy information for Ted because there is no path for the Target Address that is returned Ted@TailspinToys.mail.onmicrosoft.com. In addition, if an organization relationship was in place for TailspinToys.mail.onmicrosoft.com, the request would still fail because the token received from the Azure Authentication system (marked for ted@TailspinToys.com) would not be valid for the tenant.

The Problem

The main reason for this failure is because Organization Relationships are specific to a premises and the trust established is not transitive. Therefore, just because Contoso trusts the on-premises organization of Tailspin Toys does not mean that Contoso trusts the cloud-based Tailspin organization. To solve the issue, you need to do a few things… 1. Create an Organization Relationship between Contoso on-premises and Tailspin on-premises. Use a unique SMTP namespace for the domain name in the Organization Relationship like OnPrem.Tailspintoys.com

Note: In most environments, the shared namespace “TailspinToys.com” can be used as the Target address for on-premises users and you would not need the additional namespace of onprem.TailspinToys.com. However, to account for all complex partnerships that could be in place, a unique namespace used as the target address will ensure free busy works properly.

2. Create an Organization Relationship between Contoso on-premises and Tailspin in Exchange Online. For this Organization Relationship the domain name should be TailspinToys.Mail.onmicrosoft.com. 3. Make sure that you have a solution in place to sync mailbox enabled objects between Tailspin and Contoso. As a mailbox is moved from Tailspin on-premises to Tailspin online, Contoso needs to be made aware and the related objects’ Target Address needs to be updated in Contoso. This is needed to ensure we direct the free/busy requests to the correct premises the first time. This step can be achieved via Forefront Identity Manager (FIM) or with a script.

Note: The domain name “TailspinToys.com” is not present in any of the Organization Relationships in the Contoso environment. Keeping this name out of the Organization Relationship will ensure that you can continue to use the shared namespace and see free/busy information.

image

What happens when I move all my mailboxes to the cloud?

When you move all your mailboxes to the cloud you have the option to switch the Autodiscover namespace to point to Office 365 instead of on-premises. So in our example, if you move all of the Tailspin mailboxes to the Exchange Online and wanted to just keep Exchange on-premises for recipient management purposes, you could follow the appropriate method for decommissioning the hybrid configuration In Tailspin. Then you would delete Contoso’s existing Organization Relationships and recreate the Organization Relationship in Contoso so that it has the cloud based information: image

Conclusion

The Availability service does not treat free/busy between organizations as transitive and there are no plans to change that today. If you want to be in a hybrid configuration and maintain relationships with other external organizations, you will have to take into account the additional configuration requirements mentioned in this article. Thanks to all that contributed to this content: Lou Mandich, Ray Fong, Henrik Walther, and Ross Smith IV Timothy Heeney
9 Comments
Not applicable
This doesn't address email routing. The targetaddress is what's used to route email, so having a different targetaddress for external cloud vs on prem users means that mail sent to cloud based mailboxes will be delivered directly to the cloud, bypassing any hygiene solutions tied to the mx records if mail is supposed to be routed on premises first. The way to get around this is with address rewrites, but this such a complicated solution where an autodiscover redirect and getting a new token would be much simpler. Also, you have to sync contacts between orgs, whereas without a hybrid cloud setup, this wasn't necessary.
Not applicable
This is not entirely true. You can create send connector with domain tenant.mail.onmicrosoft.com and point it to whatever is mx record / ip address of tenant.com domain and you'll still have routing as you would expect. No need for something complex as address rewrite in this scenario. This article covers setup for Free/Busy and not covering mail routing.
Not applicable
Tim,

Thanks for sharing. This clarifies a lot and helps to understand a hybrid M&A much better.

Not applicable
Burris,

Awesome article...this helps how to share free/busy details with another organization in a Hybrid configuration

Not applicable
Great article, Tim. It's worth noting that if the TailspinToys.com domain is hybrid, Contoso.com users will still be able to see free/busy info for those users who are on-prem. Free/busy breaks only when a mailbox is moved to Office365 because Organizational Relationships are not transitive, as described above.
Not applicable
Thanks Tim.

I opened a call on this problem last week for two hybrid tenants. At Tier 2, they still have no idea what is going on. With this post and a few lines of PowerShell - all is now well with the world.

I am curious about the reverse scenario. But I'll test that in my labs.

Not applicable
Really helpful article, thanks for sharing.

But why doesn't the Tailspin OnPrem Exchange server return the target address to Contoso? In that case, I won't need to sync mailboxes with target address from Tailspin to Contoso.

Scenario:

Contoso user asks for F/B of cloud user "userA@tailspintoys.com" -> Contoso Exchange asks Tailspin Exchange -> Tailspin Exchange recognizes, that "userA@tailspintoys.com" has a target address with "userA@tailspintoys.mail.onmicrosoft.com" and provide this information to Contoso Exchange. Contoso Exchange will start / redirect F/B request against O365 (of course you need to configure the OrganizationRelationship from Contoso to tailspintoys.mail.onmicrosoft.com first).

This would be my desired scenario.

Not applicable
Excellent article, that helps overcome the availability limitation: Exchange organizations that have both on-premises and cloud users described in: https://technet.microsoft.com/en-us/library/09e6732a-4e99-44d0-801d-9463fdc57a9b(v=exchg.150)#limitations
Copper Contributor

hello,

 

I have a question if Microsoft meanwhile changed here something regarding proxy requests from on-premise to online and the delegation tokens as this article is from 2016? Below I tested this with two hybrid organizations where both mailboxes are in Exchange Online but the primary smtp addresses used for the requests both points in autodiscover to the on-premise organization and it works without using the remote routing address (targetAddress) in addition. 

 

.....................

 

Never mind, found the reason, this works because in the organization relationship from Exchange Online is configured besides the native *.mail.onmicrosoft.com domain also the primary smtp domain and the Autodiscover endpoint is set in the organization relationship explicit to Exchange Online https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity.

 

So all mailboxes hosted in Exchange Online will use for requesting free/busy information for this primary smtp address the autodiscover url which is set for the relationship and not the public dns records set for.

 

In case some mailboxes also hosted in on-premise with the primary smtp address and you wanted also request them from Exchange Online you have to use the mentioned different namespaces.

 

regards,
Marcus

Version history
Last update:
‎Jul 01 2019 04:28 PM
Updated by: