The Hybrid Mesh

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. 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. 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. 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. 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? 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.

• Sync the Tailspin on-premises mailboxes with a primary address of User@TailspinToys.com and a Target Address of User@Onprem.TailspinToys.com
• Sync the Tailspin Cloud Mailboxes with a Primary address of User@TailspinToys.com and a Target Address of User@TailspinToys.Mail.OnMicrosoft.Com

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.

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:

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