Configure Free/Busy Cross Request (Exchange Online and Exchange on-premise) when both Organizations are Hybrid
In my post below I was showing how you can configure free/busy calendar information for hybrid organizations, but only to share it for Exchange Online mailbox users.
In case both organizations are hybrid and you want to enable them to share free/busy calendar information between both organizations and environments, it gets really messy and you need to configure for both organizations separate namespaces for the online and the on-premise environment.
To say it right away, I wouldn’t configure this, because then the users from one organization needs different primary SMTP domains for each environment, for Exchange on-premise and Exchange Online.
The following two articles describes how you can implement this scenario by using for the on-premise and Exchange Online organization a separate namespace.
The Hybrid Mesh
https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910?WT.mc_id=M365-MVP-6771Hybrid FreeBusy
https://www.msxfaq.de/cloud/exchangeonline/hybrid/hybrid_freebusy.htm
The Hybrid Mesh article below, describes the scenario with a separate namespace which not have to be configured also as primary smtp domain, but here only one organization is hybrid and the other is just on-premise. Also only the on-premise organization (Contoso) is making free/busy requests to the hybrid organization Tailspin, but not vice versa.
I will simulate this configuration first in detail below.
The Hybrid Mesh
https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910?WT.mc_id=M365-MVP-6771
Setup if one Organization is Hybrid and one just on-Premise (The Hybrid Mesh article)
As mentioned here I want to simulate the configuration mentioned in the following article. One organization is hybrid and having mailboxes hosted in Exchange Online and Exchange on-premise and one organization which just uses Exchange on-premise.
So Tailspin Toys from the article, in my case here is my lab environment (braintesting.net) and Contoso is my prod environment (braincourt.com).
The Hybrid Mesh
https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910?WT.mc_id=M365-MVP-6771
I will use my lab environment as hybrid organization and my prod environment as only on-premise. The prod environment is actually also hybrid, but for this simulation, I will just use the on-premise Exchange environment and mailboxes hosted in on-premise.
As already mentioned, we need to create for the hybrid organization and its on-premise environment a unique SMTP namespace.
Therefore I will add the namespace as accepted domain to the on-premise lab environment as shown below, I will use for this domain onprem.braintesting.net.
I will also need to add the new namespace (domain) to my federation trust between the on-premise environement and the Azure Authentication System.
Further we also need to create a new autodiscover DNS CNAME record for the new domain at our public DNS registrar, which is pointing to our on-premise Exchange server.
autodiscover.onprem.braintesting.net. 86400 IN CNAME mail.braintesting.de.
The CNAME autodiscover DNS record will be used by the other organization (prod env) when they configure the organization relationship with the lab on-premise environment and using this domain namespace.
Without this record the following error message will appear at the other organization (prod env) when they want to add the domain to the organization relationship.
Also keep in mind, that you need to include the new autodiscover DNS record (FQDN) in the Exchange Server certificate.
When the other organization try to connect to the Exchange Server, to request the federation information, the connection couldn’t be established, because the other organization wouldn’t trust the server certificate if the FQDN from the autodiscover URL isn’t included as subject alternative name (SAN) in the certificate.
Federation information could not be received from the external organization.
So now I will first create an organization relationship between my prod on-premises environment and my lab on-premises environment.
Therefore we will using the previously created unique SMTP namespace –>
onprem.braintesting.net
Below I am on my prod on-premise Exchange Server, here I will add the unique SMTP namespace onprem.braintesting.net. This namespace (domain) is also added on all on-premise mailboxes in the lab environment as email alias.
The primary SMTP domain braintesting.net I will remove from the organization relationship.
Second I will create an organization relationship between my prod on-premises environment and my lab Exchange Online environment.
Therefore we will using the native Microsoft coexistence domain
<tenant name>.mail.onmicrosoft.com.For my lab environment, this is braintestingde.mail.onmicrosoft.com.
So for the Exchange Online environment we do not need to create a new primary SMTP domain as we still have one with the Microsoft coexistence domain.
Finally the organization relationship configuration on my prod on-premise Exchange Server will looks like below.
As also mentioned in the article The Hybrid Mesh, the primary SMTP domain from my lab hybrid environment (braintesting.net), is not present in any of the organization relationships in my prod 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.
In the lab environment we just need to set up one organization relationship with the on-premise Exchange environment from the prod organization. The prod environment here simulates Contoso from the article which is just using Exchange on-premise.
Here we can use just the primary SMTP address braincourt.com for.
Finally we need to maintain the mailboxes/contacts from the hybrid organization in both organizations.
First we add for all on-premise mailboxes in the hybrid organization (lab organization) an email alias with the new unique namespace (domain).
Here for example Fred.Nurk@onprem.braintesting.net.
The email alias for the Exchange Online users (mailboxes) is because of the hybrid configuration already and by default assigned with *@braintestingde.mail.onmicrosoft.com, which is also the native Microsoft coexistence domain and used for routing email between the on-premise and the online organization.
Second we need to create in the other organization (prod evironment) for all the on-premise and online mailboxes in the hybrid lab environment, a new mail contact.
Here use first for all users the normal primary SMTP address for the external email address as shown below with Fred.Nurk@braintesting.net.
After creating the new mail contact in the Exchange admin center, change the targetAddress attribute in the Active Directory Users and Computers console into the new namespace (domain) smtp address as shown below.
The smtp address must be of course the same as you previously added as email alias in the lab hybrid environment.
For on-premise users we need to add the email alias with @onprem.braintesting.net.
For Exchange Online users we need to add the email alias with @braintestingde.mail.onmicrosoft.com. Finally exactly the alias as configured in the other organization.
After that users in the prod environment can add the on-premise and also Exchange Online users from the lab hybrid environment by using the contacts in their global address list as shown below.
The users will appear with their normal primary SMTP address but in addition as shown below, the new targetAddress is listed which is used for email routing and forwarding free/busy requests.
Fred Nurk where the mailbox is hosted in Exchange on-premise.
John Doe where the mailbox is hosted in Exchange Online.
free/busy requests for both user works.
As mentioned in the article The Hybrid Mesh, the effort with the maintenance of the target addresses is the reason why you should use for this scenario a solution to sync mailbox enabled objects between both organizations.
But now below, I want to show what we need to configure if both organizations are hybrid and want to make free/busy requests from both organizations and also cross requests, not just between both online or on-premise organizations, but also from on-premise to online and vice versa.
For this scenario, the users from one organization needs different primary SMTP domains configured for each environment, for Exchange on-premise and Exchange Online, which is in practice not desirable!
Setup if both Organization are Hybrid and also cross requests supported
As already mentioned, this configuration is just to show how it works but in practice makes no sense to configure it, because then the users in your organization will have different primary SMTP email addresses configured for each environment, for Exchange on-premise and Exchange Online
How it works
Now we will see the reason, why we need to configure for this scenario the separate namespaces (domains) not just as targetAddress as shown in the article Thy Hybrid Mesh, but also as primary SMTP email address.
Below Joe Average from the prod environment (Exchange on-premise) is requesting free/busy calendar information from Fred Nurk in the lab environment.
I have configured as mentioned the separate namespace (domain) also as primary SMTP email address for Joe Average which is Joe.Average@onprem.braincourt.com.
Request for free/busy calendar information from Fred.Nurk@braintesting.net in the lab environment (Exchange on-premise). The targetAddress from Fred Nurk is maintained in the prod environment and the contact object with Fred.Nurk@onprem.braintesting.net.
free/busy requests works.
The request I captured with Fiddler, here you can see in the request headers the user identity which is requesting free/busy and the GetAvailability response for the mailbox from Fred Nurk.
It works because the lab environment have configured for the organization relationship the domain onprem.braincourt.com.
That means on one side, that internal users in the lab environment can request free/busy calendar information from the prod environment and for user mailboxes configured with the onprem.braincourt.com domain as primary smtp domain or targetAddress.
On the other side it means, that external requests for free/busy calendar information for the internal mailboxes in the lab environment, are only allowed from users, they had the primary SMTP domain onprem.braincourt.com (User Identity) configured.
As shown in Fiddler above, the user identity for the request uses the primary SMTP domain with @onprem.braincourt.com.
So the domains configured in the Domains to share with list in the organization relationship, are not just used to validate outbound free/busy requests but also to validate if external inbound free/busy requests are valid and allowed.
We also need to add an organization relationship with the Exchange Online environment from the prod environment.
Here we use the native Microsoft coexistence domain which is BraincourtGmbH.mail.onmicrosoft.com.
Therefore users from the on-premise lab environment can access free/busy from the Exchange Online prod environment (provided organization relationship is also configured there) and also users from the Exchange Online prod environment can access the on-premise lab environment, provided the users have configured BraincourtGmbH.mail.onmicrosoft.com as primary SMTP domain.
Thats also the reason why we now in contrast to the article The Hybrid Mesh, needs to change also the primary SMTP addresses for each environment.
Now not only one environment (on-premise or Online) needs to make free/busy requests and for both environments we need to create an organization relationship where we cannot use the same shared domain.
How it not works
Now the same as previously but this time the primary SMTP address from Joe Average in the prod environment is not using the separate namespace (domain).
Joe Average this time using its usual default email address Joe.Average@braincourt.com.
The request I also captured with Fiddler, here you can see in the request headers the user identity which is requesting free/busy and the GetAvailability response for the mailbox from Fred Nurk.
The following error was logged. The main part here is InvalidUser. This could be either the requested user or the user which is requesting.
Autodiscover failed for email address Fred.Nurk@onprem.braintesting.net with error Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverInvalidUserException: The response from the Autodiscover service at ‘https://autodiscover.braintesting.net/autodiscover/autodiscover.svc/WSSecurity’ failed due to an error in user setting ‘ExternalEwsUrl’. Error message: InvalidUser.
The reason here is, that the domain braincourt.com from the requested user Joe.Average@braincourt.com is not configured in the organization relationship and therefore not valid and allowed to request free/busy information.
So that’s excactly the reason why we for this scenario also needs to configure the separate namespace (domain) not just as targetAddress but also as primary SMTP address.
Assigning the same primary domain like braincourt.com for both organization relationships, from on-premise to on-premise and on-premise to Exchange Online is not possible and you will get the following error message:
The domain ‘braincourt.com’ already exist in another organization relationship. Domains can only exist in one organization relationship.
And the reason for this error message is of course, that in this case the Exchange organization cannot know which of both organization relationships and its Autodiscover URIs should be used for the same shared braincourt.com domain.
Finally you need to configure in each organization four relationships, two in Exchange on-premise (on-premise to on-premise and on-premise to online) and two in Exchange Online (online to online and online to on-premise) by using in each organization two different namspaces (domains) for the on-premise and online environment.
As mentioned in the Hybrid FreeBusy article under the URL https://www.msxfaq.de/cloud/exchangeonline/hybrid/hybrid_freebusy.htm, it would be much easier if Microsoft would support to proxy free/busy requests from on-premise to Exchange Online, as it is already the case for outlook clients, to find the associated mailbox by just using autodiscover which is pointing only to the on-premise organization in hybrid configurations.
Then you wouldn’t need to use the workaround with the targetAddress and the separate namespaces. The scenario with cross requests where both organizations are hybrid and using the separate domains also as primary SMTP address isn’t really practicable.
I think the reason why Microsoft will not support to proxy the requests from on-prem to online (official article below an also not changed in newer versions of Exchange), is their focus to bring customers to cloud-only and not investing to much effort in on-premise scenarios.
Limitations of free/busy sharing
Exchange organizations that have both on-premises and cloud users: If you set up calendar sharing with another Exchange organization that is configured in a hybrid deployment with Microsoft 365 or Office 365, free/busy availability lookups for Microsoft 365-based or Office 365-based or remote users that have been moved to the cloud will fail. Because the organization relationship for your Exchange organization is with the remote on-premises Exchange organization, not the Microsoft 365-based or Office 365-based Exchange Online organization, the free/busy request can’t query the Microsoft 365-based or Office 365-based users. Exchange 2013 doesn’t support functionality to proxy these availability requests through the on-premises organization to the Microsoft 365 or Office 365 service.
Mail User vs. Mail Contact
In Exchange Online organizations, mail users are similar to mail contacts. Both have external email addresses and both contain information about people outside your Exchange Online organization that can be displayed in the shared address book and other address lists. However, unlike a mail contact, a mail user has sign in credentials in your Microsoft 365 organization and can access resources. For more information about mail contacts and mail users, see Recipients in Exchange Online.
Source: https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-mail-users
Links
Configuring federated sharing between Exchange organizations
https://learn.microsoft.com/en-us/exchange/configuring-federated-sharing-between-exchange-organizations-exchange-2013-helpOrganization relationships in Exchange Online
https://learn.microsoft.com/en-us/exchange/sharing/organization-relationships/organization-relationshipsFederation procedures
https://learn.microsoft.com/en-us/exchange/federation-procedures-exchange-2013-helpShared free/busy in Exchange hybrid deployments
https://learn.microsoft.com/en-us/exchange/shared-free-busyAdvanced Sharing Scenarios with Exchange Hybrid Deployments
https://www.enowsoftware.com/solutions-engine/m365-exchange-online-center/advanced-sharing-scenarios-with-exchange-hybrid-deploymentsHybrid FreeBusy
https://www.msxfaq.de/cloud/exchangeonline/hybrid/hybrid_freebusy.htmDemystifying Hybrid Free/Busy: what are the moving parts?
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704?WT.mc_id=M365-MVP-6771
The best home for modern WordPress sites built on the Google Cloud Platform
