Demystifying Hybrid Free/Busy: what are the moving parts?
Published Feb 06 2018 04:58 PM 201K Views

Hybrid Free/Busy is one of those things that many people do not fully understand. If everything works well, the complexity is hidden from view and people working in various parts of organization can seamlessly work together. But if things go wrong… you will appreciate deeper understanding of what makes it work. This is why we wanted to create the blog post series on the subject. In this article, we will discuss how Free/Busy works in an Exchange Hybrid configuration. In next blog post, you will learn what we (Microsoft Support) see as the most common problems along with how we go about diagnosing those (often) complex issues. Hope you like reading, because there is a lot to cover! So, what is Free/Busy? Free/Busy is a feature that allows you to see when others are free (their calendar shows availability), busy (their calendar shows them as busy), or even Out of Office, or Something Else (tentative or working away) so that you can find an appropriate time for your meetings. Calling it all “Free/Busy/OOF/Something-Else” didn’t sound so cool to marketing hence “Free/Busy”. In a Hybrid deployment, we usually have some mailboxes in Exchange On-Premises and some mailboxes in Exchange Online (users are in different premises) and this has to work there too. One of the most important parts in Hybrid Configurations is the Federation Trust and many features, including Free/Busy can rely upon this. A quick overview of a hybrid deployment with a focus on Federation Trust components HFB1 In Contoso – On-Premises side we have on-premises Exchange Servers and mailboxes. We also have a federation trust with the Microsoft Federated Gateway (MFG) - now called Azure Authentication System. A Federation trust is not set by default for Exchange On-Premises organizations and we can either create it manually or run the Hybrid Configuration Wizard (HCW) which will do this for us. If you don’t have already a federation trust established on-premises (usually for purposes to share F/B with another on-premises organization) and you plan for a Hybrid deployment, then we strongly recommend you run HCW to automatically create the Federation Trust. In Contoso – Cloud Side there are Office 365 Exchange Online servers, your Office 365 tenant and mailboxes migrated from on-premises. A Federation trust with the MFG is automatically created for cloud-only-based Exchange organizations whom do not have a Hybrid relationship to an on-premises organization. If you run Get-FederationTrust cmdlet in Exchange Online PowerShell (see here how to connect to Exchange Online PowerShell) you would see two trusts: “WindowsLiveId” (Consumer Instance of Microsoft Federation Gateway) and “MicrosoftOnline” (Business Instance of Microsoft Federation Gateway) .

Note: As a troubleshooting tip, you might want to make sure the Application Identifier is “260563” and the Application Uri is “outlook.com” for both; in case you have a different App ID (292841) and a different App URI (outlook.live.com) for a Cloud trust, this means your tenant has an old reference pointing to MFG and most probably Free/Busy from on-premises to cloud would fail with a quite generic 401 Unauthorized error. If you were to find yourself in a such situation, please open a support case with Microsoft to get it resolved.

About Free/Busy lookup directionality

To guide you to the correct troubleshooting steps we first need to determine what direction Free/Busy queries are failing in. Understanding how Free/Busy works in general and the direction that lookups are failing can greatly simplify the troubleshooting steps. Simply said, there are 2 possible Free/Busy directions (referring to our example above): When Joe looks up Jane’s Free/Busy, the Free/Busy direction is On-premises to Cloud. HFB2 When Jane looks up Joe’s Free/Busy, the Free/Busy direction is Cloud to On-Premises HFB3 Now that you are familiar with the Free/Busy directions, we should take a moment to discuss how it all works. Let me set the stage for the below diagram: joe@contoso.com has his mailbox in Exchange on-premises and jane@contoso.com has been moved to Exchange Online. In Exchange on-premises, joe@contoso.com is a Mailbox User. Because Directory Synchronization is a requirement for Hybrid Deployments, joe@contoso.com (mailbox) is synced to the cloud and represented as a Mail Enabled User (MEU) object in Cloud with Target Address (TA) of joe@contoso.com. jane@contoso.com was once a Mailbox User in Exchange on-premises. Her mailbox was then migrated to Exchange Online. Jane now has a Mailbox User in Exchange Online and is represented as a Remote Mailbox (RM) object in Exchange On-Premises. Jane has a Primary SMTP address (SMTP: jane@contoso.com) and a secondary smtp address (smtp: jane@contoso.mail.onmicrosoft.com). Notice how we refer to a primary email address (SMTP) and to a secondary email address (smtp). According to TechNet, the difference between primary and secondary addresses is that the primary address serves as the return e-mail address. When mail is received from a recipient, the primary address determines which address the mail appears to have come from. Recipients can receive mail sent to any of the addresses associated with them (primary or secondary). The Target Address (TA) of the on-premises Remote Mailbox object is represented as jane@tenant.mail.onmicrosoft.com (secondary smtp) and this is crucial for Autodiscover and email routing from on-premises to cloud. A successful Autodiscover query is important in the Free/Busy process as it provides us with the Availability Service URL of the user which is the External EWS URL of an Exchange Organization. This TechNet article gives us more information on this <domain>.mail.onmicrosoft.com secondary email address:

The wizard (HCW) adds an accepted domain to the on-premises organization for hybrid mail flow and Autodiscover requests for the cloud organization. This domain, referred to as the coexistence domain, is added as a secondary proxy domain (contoso.mail.onmicrosoft.com) to any email address policies which have PrimarySmtpAddress templates for domains selected in the Hybrid Configuration wizard(contoso.com). By default, this domain is <domain>.mail.onmicrosoft.com.

Table below illustrates the hybrid user objects discussed above as well as how to look them up.

Typical Hybrid user objects configuration

On-premises commands On-premises objects Corresponding cloud objects Cloud commands
  ON-PREM MAILBOX USER MAIL ENABLED USER IN CLOUD  
Get-mailbox Joe@contoso.com | FT PrimarySMTPaddress On-premises mailbox user with SMTP: Joe@contoso.com Cloud mail enabled user with SMTP: Joe@contoso.com Get-MailUser Joe@contoso.com | FT PrimarySMTPAddress
(Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp address of @contoso.mail. onmicrosoft.com configured by HCW (Email Address Policies) Cloud mail enabled user has this secondary smtp Joe@contoso.mail. onmicrosoft.com (Get-mailuser Joe@contoso.com). EmailAddresses
(Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp Joe@contoso.mail. onmicrosoft.com Cloud mail enabled user has an ExternalEmailAddress Joe@contoso.com Get-MailUser Joe@contoso.com |FT ExternalEmailAddress
  REMOTE MAILBOX ON-PREM MAILBOX USER IN CLOUD  
Get-RemoteMailbox Jane@contoso.com |FT primarySMTPaddress Remote mailbox SMTP: Jane@contoso.com Mailbox User SMTP: Jane@contoso.com Get-Mailbox Jane@contoso.com |FT PrimarySMTPAddress
Get-RemoteMailbox Jane@contoso.com | FT RemoteRoutingAddress Remote mailbox TargetAddress: Jane@contoso.mail. onmicrosoft.com Mailbox User smtp: Jane@contoso.mail. onmicrosoft.com (Get-Mailbox Jane@contoso.com). EmailAddresses

Now that we understand user objects and their relevant properties, we should come back to Free/Busy directions. Between the on-premises organization and cloud organization there are bidirectional Organization Relationships and/or bidirectional Intra Organization Connectors (for Exchange 2013 or later) that are created during Hybrid Configuration. The source of these Relationships / Connectors plays an important role in the F/B directionality. The Free/Busy directions are:

Direction On-premises to Cloud

You are logged in to Outlook on the Web or Outlook on Windows as an on-premises user (joe@contoso.com), you’re your mailbox hosted on your on-premises Exchange server. As an on-premises user you wish to have a meeting with the cloud user (jane@contoso.com) but will first have to check their availability for the meeting. Let’s walk through the process: 1. Joe creates a meeting request and adds Jane as an attendee. 2. The on-premises Exchange server in Contoso determines (usually based on Target Address of the mail-enabled user) that Jane is not a local mailbox and has a different domain name of contoso.mail.onmicrosoft.com set as the Target Address. 3. The Availability Service on the on-premises Exchange server (Client Access Server if Ex2010 or Mailbox Server if 2013/2016) in Contoso then checks to see if there is a path to query Jane’s Free/Busy information for Contoso’s cloud side.

  • First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.mail.onmicrosoft.com (assuming the Exchange server is version 2013 or later).
  • If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.mail.onmicrosoft.com in the list of any existing Organization Relationships.
  • If neither an IOC nor an Organization Relationship for the domain contoso.mail.onmicrosoft.com exists, then we look for the domain name contoso.mail.onmicrosoft.com as an Availability Address Space (3).

4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso on-premises Organization Relationship is set to outlook.com, which is an identifier for the Contoso Cloud organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token that will be accepted by Contoso Cloud Organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso on-premises sends an Autodiscover request to Exchange Online, and upon a successful Autodiscover response will send an EWS request to Exchange Online for Jane’s availability information. 6. The Exchange Online server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Jane’s mailbox. Here is a flowchart which illustrates the Free/Busy lookup process: HFB5

Direction Cloud to on-premises

You are logged in to Outlook on the Web or Outlook on Windows as a cloud user (jane@contoso.com), whose mailbox is in Exchange Online. Jane wants to have a meeting with an on-premises user (joe@contoso.com), but must first check their availability for the meeting. 1. Jane creates a meeting request and adds Joe as an attendee 2. The Exchange Online servers in Contoso-cloud side organization determine (usually based on target address of a mail-enabled user) that Joe is not a local mailbox and has a domain name of contoso.com set as the target address. 3. The Availability Service on Exchange Online servers checks to see if there is a path for it to find the Free/Busy information for Contoso on-premises side organization.

  • First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.com (assuming the Exchange server is 2013 or later on-premises).
  • If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.com in the list of any existing Organization Relationships.
  • If neither an IOC nor an Organization Relationship for the domain contoso.com exists, then we then look for the domain name contoso.com as an Availability Address Space (3).

4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso Cloud Organization Relationship is set to FYDIBOHF25SPDLT.contoso.com, which is an identifier for the Contoso on-premises organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token which will be accepted by Contoso on-premises organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange Online server in Contoso cloud sends an Autodiscover request to the on-premises Exchange Servers and upon receipt of a successful Autodiscover response it will then send an EWS request for Joe’s availability. 6. The Contoso on-premises Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Joe’s mailbox.

Hybrid Free/Busy lookup order

To summarize, the following order would be used when processing for Free/Busy lookups from cloud to on-premises:

  1. Look for IntraOrganizationConnector (OAUTH)
  2. If there is no IntraOrganizationConnector or if it is disabled, then look for Organization Relationship (DAUTH)
  3. If neither of these are found or they’re disabled, then look for Availability Address Space. Availability Address Space is normally only used for Lotus Notes organizations. If Free/Busy lookup is getting all the way down to using the final Availability Address Space option for cloud to on-premises lookups in a hybrid deployment, then this would suggest there are configuration issues which must be repaired.

The order for Free/Busy lookups from on-premises to cloud is almost the same with some exceptions:

  1. If we have Exchange 2007 servers in coexistence with Exchange 2010/2013, we use Availability Address Space from Exchange 2007 to Exchange 2010/2013 and then Exchange 2010/2013 will use Org Relationship (Ex2010) or IntraOrganization Connector (Ex2013) to Cloud.
  2. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is enabled, Exchange 2010 will use Availability Address Space to Exchange 2013/2016 and then 2013/2016 will use the IntraOrganization Connector to Cloud.
  3. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is not enabled, Exchange 2010 will not send the request to the Exchange 2013/2016. Instead Exchange 2010 will use Organization Relationship to Cloud for Free/Busy.

Exchange 2013 Cu5+ and Exchange 2016 organizations without coexisting with legacy Exchange servers will use by default IntraOrganization Connectors from On-Premises to Cloud (normal process) This table summarizes which components (Get-IntraorganizationConnector / Get-OrganizationRelationship / Get-AvailabilityAddressSpace) are present (YES) or not (NO) in the Exchange Organization depending on the Exchange Server versions on-premises in a Hybrid deployment.

Free/Busy component matrix

Exchange Hybrid Environment Intra Organization Connector (IOC) Organization Relationship Availability Address Space
Pure Exchange 2016 Hybrid YES (created automatically by HCW) YES YES
Pure Exchange 2013 (CU5+) Hybrid YES (created automatically by HCW) YES YES
Pure Exchange 2010 Hybrid NO YES YES
Mixed Exchange 2007 + Exchange 2010 Hybrid NO - Ex2010 NO - Ex2007 YES - Ex2010 NO - Ex2007 YES - Ex2010 YES - Ex2007
Mixed Exchange 2007 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2007 YES - Ex2013 NO - Ex2007 YES - Ex2013 YES - Ex2007
Mixed Exchange 2010 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2010 YES - Ex2013 YES - Ex2010 YES - Ex2013 YES - Ex2010
Mixed Exchange 2010 + Exchange 2016 Hybrid YES - Ex2016 (if created manually) NO - Ex2010 YES - Ex2016 YES - Ex2010 YES - Ex2016 YES - Ex2010
Mixed Exchange 2013 + Exchange 2016 Hybrid YES - Ex2016 (created automatically by HCW) YES - Ex2013 YES - Ex2016 YES - Ex2013 YES - Ex2016 YES - Ex2013

Note: OAuth is by default configured by HCW in Exchange 2013 CU5 and above (including Exchange 2016) organizations. If Exchange 2013 / Exchange 2016 servers coexist with Exchange 2010 or older then OAUTH is not configured by default by the HCW but can be manually configured.

Note: Exchange 2013 CU5 is considered old and unlike wine, the finest CU is always the most recent one. You probably have heard about our n and n-1 supported version statement in Hybrid Deployments and can read more about it here and here.

Which Free/Busy lookup method are you using?

I won't go into all the details about the two types of authentication (OAUTH vs DAUTH) in this post, but I recommend reading this blog post at bedtime: Deep Dive: How Hybrid Authentication Really Works. As explained there, OAuth is an open-standards based model which is more preferred to a customized model. You can quickly determine if you are using OAuth or not by running: Get-IntraOrganizationConnector cmdlet in Exchange Management Shell (for F/B direction On-Premises to Cloud) and in Exchange Online PowerShell (for F/B direction Cloud to On-Premises). If you see Enabled = True, then you are using OAuth or the system should at least be trying to.

Note: We also need to make sure that the Target Domain is present on the Intra Organization Connector or Organization Relationship when deciding if using OAUTH or DAUTH.

I have created two flowcharts to show you the logic of using OAUTH vs DAUTH in a F/B lookup process for each F/B direction. The user’s setup remains still the same as shown in previous examples and I am reposting the diagram here so that you don’t need to scroll up. 1. Joe’s Exchange server deciding whether to use Oauth or Dauth : HFB7 2. Jane’s Exchange Online server deciding whether to use Oauth or Dauth HFB8 Now that you know which method is being used (or at least which should be attempted) and we know the direction Free/Busy is failing, we can see if you have everything configured correctly. In most cases these configurations are handled by the HCW and should be accurate and you can re-run the HCW to get things back to a good configuration.

  • If Exchange On-Premises > Exchange Online Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from on-premises.
  • If Exchange Online > Exchange On-Premises Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from Exchange Online.

Below, you will see a sample of the expected configuration for Intra Organization Connectors and Org Relationships from both sides (on-premises and cloud). This Baseline configuration was documented by my co-worker Ray Fong (Support Escalation Engineer) and I am very happy to have it when I troubleshoot Free/Busy issues.

Exchange Online side

Use this article to connect to Exchange Online PowerShell. INTRA ORGANIZATION CONNECTOR IN CLOUD

Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled
TargetAddressDomains : {contoso.com}
DiscoveryEndpoint    : https://autodiscover.contoso.com/autodiscover/autodiscover.svc *
Enabled              : True

Note: In practice, the On-Premises Discovery Endpoint (Autodiscover) is more likely to be found in the format https://mail.contoso.com/autodiscover/autodiscover.svc because of the EWS External URL, so pay attention to this Autodiscover URL and replace it if needed with the autodiscover.yourdomain.tld on the IOC present in the Cloud Side (Reference Set-IntraOrganizationConnector)

Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses
OnPremiseTargetAddresses : {contoso.com}

  • TargetAddressDomains - This should be your federated domains. Example: contoso.com
    • You can find the domains name by cross-checking Exchange Online's (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses
  • TargetDiscoveryEndpoint - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/.If you paste the URL in IE, you should receive a regular windows authentication security prompt
  • Enabled - This must be True.

Exchange On-Premises side (use Exchange Management Shell)

INTRA ORGANIZATION CONNECTOR IN ON-PREM

Get-IntraOrganizationConnector | fl Name,TargetAddressDomains,DiscoveryEndpoint,Enabled
Name                 : ExchangeHybridOnPremisesToOnline
TargetAddressDomains : {contoso.mail.onmicrosoft.com}
DiscoveryEndpoint    : https://outlook.office365.com/autodiscover/autodiscover.svc
Enabled              : True

  • TargetAddressDomains - This should be your tenant.mail.onmicroosft.com name. Example: 'contoso.mail.onmicrosoft.com'
  • TargetDiscoveryEndpoint - This should be the address of EXO Autodiscover endpoint. Example: https://outlook.office365.com/autodiscover/autodiscover.svc
  • Enabled - This must be True.

Exchange Online side

Use this article to connect to Exchange Online PowerShell. ORGANIZATION RELATIONSHIP IN CLOUD

Get-OrganizationRelationship "Exchange Online to on premises Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled
DomainNames           : {contoso.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : FYDIBOHF25SPDLT.contoso.com
TargetSharingEpr      :
TargetOwaURL          :
TargetAutodiscoverEpr : https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True

  • DomainNames - This should be your federated domains. Example: contoso.com
    • You can find the domains name by cross-checking On-Premises' (Get-FederatedOrganizationIdentifier).Domains
  • TargetAutodiscoverEPR - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity. If you paste the URL in IE, you should receive a regular windows authentication security prompt
  • TargetSharingEPR - Ideally this is blank. If it is set, it should be the On-Premises Exchange servers EWS ExternalUrl endpoint. Example: https://server.contoso.com/EWS/Exchange.asmx
    • You can find the URL by cross-checking On-Prem's Get-WebServicesVirtualDirectory ExternaUrl. If you paste the URL in IE with /WSSecurity at the end (https://server.contoso.com/EWS/Exchange.asmx/WSSecurity), you should receive a regular windows authentication security prompt
  • TargetApplicationURI - This must match the ApplicationUrI from On-Prem. Example: FYDIBOHF25SPDLT.contoso.com
    • You can find the value by cross-checking On-Prem's (Get-FederationTrust).ApplicationUri
  • FreeBusyAccessEnabled - This must be True.
  • FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails.
    • AvailabilityOnly: Free/Busy access with time only
    • LimitedDetails: Free/Busy access with time, subject, and location
  • FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization.
  • Enabled - This must be True.

Exchange On-Premises side (use Exchange Management Shell)

ORGANIZATION RELATIONSHIP IN ON-PREM

Get-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled
DomainNames           : {contoso.mail.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel   : LimitedDetails
FreeBusyAccessScope   :
TargetApplicationUri  : Outlook.com
TargetSharingEpr      :
TargetOwaURL          : https://outlook.com/owa/contoso.onmicrosoft.com
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
Enabled               : True

  • DomainNames - This should be your tenant.mail.onmicrosoft.com name. Example: contoso.mail.onmicrosoft.com
  • TargetAutodiscoverEpr - This should be a valid Exchange Online Autodiscover endpoint. Example: https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity or https://pod51038.outlook.com/autodiscover/autodiscover.svc/WSSecurity [<-- A pod address]
    • You can find the value from TargetAutodiscoverEpr of Get-FederationInformaiton -DomainName tenantname.mail.onmicrosoft.com -BypassAdditionalDomainValidation | fl
  • TargetSharingEPR - Ideally this is blank. If it is set, it should be Office 365 EWS endpoint. Example: https://outlook.office365.com/EWS/Exchange.asmx
  • TargetApplicationURI - This must be outlook.com if this is for organization relationship of the cloud tenant. For non-cloud organization relationship, this must match (Get-FederationTrust).ApplicationUri of the On-Prem trust of the other organization.
  • FreeBusyAccessEnabled - This must be True.
  • FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails.
    • AvailabilityOnly: Free/Busy access with time only
    • LimitedDetails: Free/Busy access with time, subject, and location
  • FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization.
  • Enabled - This must be True.

Both Autodiscover and EWS virtual directories must be enabled for WSSecurity authentication and/or OAuth. For example, if using OAuth, you should have OAuth listed as Authentication Methods, whereas if using only DAuth (Exchange 2010 for example), you would see only WSSecurity. Example of virtual directories authentication methods for an Exchange 2013 Hybrid Organization:

Get-AutodiscoverVirtualDirectory -Server SERVER01 | fl Name,AdminDisplayVersion,*authentication*
Name                          : Autodiscover (Default Web Site)
AdminDisplayVersion           : Version 15.0 (Build 1044.25)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

Get-WebServicesVirtualDirectory -Server server01| fl Name,AdminDisplayVersion,*Authentication*
Name                          : EWS (Default Web Site)
AdminDisplayVersion           : Version 15.0 (Build 1044.25)
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}

As explained earlier, there are some situations where Free/Busy from on-premises to cloud is going via Availability Address Space. This would be the expected configuration for Availability Address Space in Exchange on-premises (Exchange Management Shell):

Get-AvailabilityAddressSpace contoso.mail.onmicrosoft.com | fl ForestName, UserName, UseServiceAccount, AccessMethod, ProxyUrl, Name
ForestName        : contoso.mail.onmicrosoft.com
UserName          :
UseServiceAccount : True
AccessMethod      : InternalProxy
ProxyUrl          : https://server01.contoso.com/EWS/Exchange.asmx
Name              : contoso.mail.onmicrosoft.com

  • ForestName - The should be the tenant.mail.onmicrosoft.com domain name. This should also match the domain name of RemoteRoutingAddress of remote mailboxes. Example: contoso.mail.onmicrosoft.com
  • UserName - This should be blank.
  • UserServiceAccount - This must be True.
  • AccessMethod - This should be InternalProxy.
  • ProxyUrl - This should be the Exchange 2013/2016 Exchange Web Services Virtual Directory URL. The address could be the internal FQDN or load balancing EWS URL. Example: https://server01.contoso.com/EWS/Exchange.asmx

We recommend you check the following requirements for inbound/outbound connectivity to and from Exchange servers in a Hybrid Deployment:

If you have read this far – thank you! This concludes the Part 1 of this blog series. Onto troubleshooting next! Huge thanks to all that contributed to this blog post: Ray Fong, Nino Bilic, Tim Heeney, Greg Taylor and Brian Day. Mirela Buruiana

40 Comments
Not applicable
This is a great post!

I'd really appreciate more deeper dives like this; simply collecting all the information on the process into one place is much better than following the technet rabbit hole.

I'd especially appreciate one detailing the all of the steps taken by the HCW.

Not applicable
@haydong, I / we can do such blog on the configuration steps in HCW and maybe a comparison between Minimal HCW and Full HCW. I assume you are interested in the set-* / add-* /new-* /update-* cmdlets (anything else than get-*)
Not applicable
Very comprehensive article. I look forward to the rest of the series!
Not applicable
Thanks! The rest of the content is currently being reviewed. That part will be much more interesting, at least from technical support perspective. Stay tuned!
Not applicable
This is a nice reading. During this Ignite session https://myignite.microsoft.com/sessions/53164?source=speakerdetail full calendar sharing has been anounced. Can anything be said about when this will be availbale?
Not applicable
This was documented here https://technet.microsoft.com/en-us/library/58b46b2c-a6b2-424a-8fc2-0f1fe1ad8e18(v=exchg.150)#DelegatedMbxPerms

"As of February 2018 the feature to support Full Access, Send on Behalf and folder rights cross forest is being rolled out and expected to be complete by April 2018."

Microsoft

Hi, my name is Mirela Buruiana and I am the main author of this blog. Reply to this comment if you want me to get notified about your question /comment.

Copper Contributor

Thank you! Great post.

Copper Contributor

It's a really great post!!!

I have a strange question, Free/Busy between On-premises and Cloud no problem, only On-premises cannot sharing calendar to cloud user or set calendar permission to cloud user, but cloud user can sharing calendar to On-premises user, any suggestion? 

Thanks In Advance

Copper Contributor

PS. when assign permission to remote mailbox user will get alert as "one or more users cannot be added to the folder access list. Non-local users cannot be given rights on this server"

Microsoft
Copper Contributor

@Mirela_Buruthank you! hope these will be full supported soon.

Copper Contributor
Microsoft

@Jeep16 , thanks! the hyperlink to part2 is now fixed.

Copper Contributor

I have everything working in my EXO and Exchange 2016 hybrid.

 

Not sure if this is the right spot for this question - but it is about Free/Busy.

 

When using the Teams Calendar Scheduling Assistant, free/busy is very sporadic even for the meeting organizer.  Very inconsistent. Seems as though if there is already an existing meeting in the organizers calendar, then free/busy displays for the days previous and a week or so after.  Then hashes.

 

Any ideas?

Microsoft

@thorbug , I am not sure about Teams client and how the query / display is done, what I can suggest for the hashes (f/b issue) is that you try F/B from OWA and see if you see the hashes there too (you can use F12 Network Tab and look at the Response for GetUserAvailability) or you can try F/B test on exrca.com https://testconnectivity.microsoft.com/tests/FreeBusy/input when this issue happens in Teams. If the issue is reproducible on the Exchange /OWA client side, then check the error message and check part 2 of my blog, especially the PDF with common errors and resolutions. Those are mainly applicable for Hybrid Free/busy (between exchange on-premises user and exchange online user) but suggestions might help.  If issue is reproducible only in Teams and not Exchange /OWA, then I suggest you open a support case with Teams.

Copper Contributor

Hello @Mirela_Buru I have another scenario which is on-premise exchange with high availability (DAG) and available on 4 sites. Each site has virtual Exchange and primary DB on each site is located on same physical location of user mailbox. All users' are on single domain, and each geographical site has a DC replicated and synched with other DCs on another sites without any issue. Also, exchange DAG is healthy. Free/Busy is functioning only within same sites! and Free/Busy does not work across all sites! Example, when a user on site#1 is try to look for Free/Busy information for a user mailbox on site#2 then he/she will get error message "calendar; could not be updated" and on "scheduling assistance error is no information!!". Sites are connected together using MPLS connections. 

Any suggestion?

 

Thank you

Microsoft

@Yaseenhh , I work in Exchange Online Support team where I handle cloud free/busy and hybrid free/busy. The scenario you are describing seems pure Exchange On-Premises (cross-site Free/Busy). However, the Free/Busy call should be the same (GetUserAvailability). You need to retrieve that call and the error response. For the error message, you can use F/B test on Remote Connectivity Analyzer https://testconnectivity.microsoft.com/tests/FreeBusy/input  (source user = user from site1 , target user = user from site 2) or Fiddler tool while you reproduce the issue in Outlook or OWA client in Scheduling Assistant as explained in the second part of the blog: https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-finding-erro....

Copper Contributor

Thanks @Mirela_Buru I am going to open case with Microsoft because this calendar F/B was functioning but suddenly stopped and there is no network restriction between the servers (AD & Exchanges). 

Copper Contributor

Hello @Mirela_Buru 

 

I posted in your other blog about seeing the error with free/busy within f12. I think this article has shown me my issue, but I'm hoping you could confirm my suspicion. Im having issues seeing on-prem free/busy from exchange online mailboxes, the other way around is working fine.

 

In exchange online for get-organzationalrelationship I have the following :

 

TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

 

TargetApplicationUri : outlook.com

 

 

Based on your information above the autodiscover should be the on-prem autodiscover and the applicationURI should not be outlook.com but our on prem (i.e FYDIBOHF25SPDLT.contoso.com)

 

I dont have an entry for get-intraorganizarionconfiguration ( we have exchange 2010 and 2013 on prem )

 

 

Thanks!

@epeterson79 

 

 

Microsoft

@epeterson79 , sorry I missed it. There are a few things here:

1) Make sure that you are looking at the right Cloud Organization Relationship, that is meant for on-premises organization, should be Office 365 to on-premises.

In EXO PS:

Get-OrganizationRelationship "O365 to on-premises*" |FL Identity, DomainNames, Enabled, Free*, Target*

 

2) DomainNames should be your Vanity Domains, like contoso.com. No other MS domain like domain.mail.onmicrosoft.com or domain.onmicrosoft.com where Autodiscover for it always points to Office 365 servers.

 

3) Autodiscover for Contoso.com in Hybrid deployment must point to on-premises Exchange Server. So make sure you don't have a CNAME record for autodiscover.contoso.com that points to autodiscover.outlook.com. 

 

4) Assuming you have a Get-FederationTrust on-premises, you can put that ApplicationURI in the Cloud Organization Relationship and also if you have Autodiscover pointing to cloud for your contoso.com domain, then you can set TargetSharingEpr to point to the onpremises EWS url to bypass it.

Example of command in EXO PS:
Set-OrganizationRelationship "O365 to on-premises*" -TargetSharingEpr https://mail.contoso.com/EWS/Exchange.asmx -TargetApplicationUri FYDIBOHF25SPDLT.contoso.com

 

5) Then test again Free/Busy from cloud user to onpremUser@contoso.com

You can use https://testconnectivity.microsoft.com/tests/FreeBusy/input 

 

6) I also assume that in Cloud Organization (source side) you have a Mail User  for the target user onpremUser@contoso.com with the same External Email Address . It is not mandatory to have a MEU for target user in the source side but we need to make sure that contoso.com is the SMTP domain which Scheduling Assistant would resolve to. Based on this SMTP resolution, we pick the domain from user@domain and lookup for an organization relationship with the domain listed in DomainNames.

Copper Contributor

@Mirela_Buru 

 

Thanks for the quick reply!!

 

1.  Here is the output:

 

PS C:\windows\system32> Get-OrganizationRelationship "O365 to on-premises*" |FL Identity, DomainNames, Enabled, Free*, Target*


Identity : O365 to On-premises - c12856e0-d236-4e7b-8ba7-a9dac319c92c
DomainNames : {contosomail.com, contosoorg.org} ( I removed, but one is our email , the other is our domain)
Enabled : True
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
TargetApplicationUri : outlook.com
TargetSharingEpr : https://72c9440f-e756-42f7-b48a-80325101d9ac.resource.mailboxmigration.his.msappproxy.net/EWS/E
xchange.asmx
TargetOwaURL : https://mail.contoso.com/owa    ( I removed our server )
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

 

 

2. I believe this is correct, this is pointed to our organizations email and domain.

 

3. Our onprem autodiscover.contoso.com points to our public ip for owa

 

4. Thanks for the commands, would I also need to to change the targetautodiscover record? This appears that it should be pointing to  our on-prem autodiscover

 

6. We just made the move to Hybrid 2 weeks ago and have successfully moved 3 mailbox's (2 test accounts and mine) to the Exch online. All of our email addresses are the same as far as @contoso.com 

Microsoft

I see that you already have TargetSharingEpr and that is pointing to Hybrid Agent. Normally you don't need to change TargetAutodiscoverEpr (even if wrong) cause you are not using it due to TargetSharingEpr being populated  but you can re-run HCW because TargetApplicationUri is wrong and this will restore default settings.  Again, I am assuming that Autodiscover for your contosomail.com, contosoorg.org are pointing to on-premises Exchange in public DNS and not Office 365. If Autodiscover (still) points to Office 365, then HCW would set it like this (wrong) and you would need to switch back to on-premises. Then HCW would set it right.  In conclusion, TargetApplicationUri must be the on-premises one and this has to be set somehow (manually or thru HCW)

 

Also, I am assuming that these DomainNames contosomail.com, contosoorg.org are the primary SMTP domains used in Scheduling Assistant, for example, CloudUser@contoso.com will put these attendees in the Scheduling Assistant OnPremUser1@contosomail.com and OnPremUser2@contosoorg.org.

If these 2 conditions are met, then f/b request would go on that org relationship. And if you still have an error related to the security of the message, recycle EWS app pool or IISreset onprem on each exchange server.

Copper Contributor

@Mirela_Buru 

Here is an update about on my case "Free/Busy" for on-premise Exchange 2016 was not functioning as expected between two difference sites. 

The solution was related to TLS configurations. As we adopted the TLS 1.2 and the third-party tool was used to enable it. However, it was not enabled correctly, the value of Registry key "Enabled" was not (1) which cause the problem!

Correct the value on Client/Server TLS 1.2 to (Enabled (1)) on all Exchange servers within the network solved the problem. 

 

Here are some links related to TLS.

Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-1-gettin...

 

Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-2-enabli...

 

Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-3-turnin...

 

Hope this will be helpful.

Best Regards, 

Yaseen 

Microsoft

Yasee, thank you for letting us know. Based on your resolution, I can only guess that your underlying free/busy error was similar to this one: “The request was aborted: Could not create SSL/TLS secure channel.”

Copper Contributor

Hello Mirela , 

 

I have a scenario and couple questions 

Here is the following configuration of the two organizations:

Organization 1:

Exchange 2013 CU23

Organization 2:

Exchange 2016 CU19

Both organizations have an internal connection between them and a Full Trust Relationship.

What is the best way to set up the organizations so they can share their free\busy ? 

 

The two separate organizations they will both be moving to O365 in the same tenant later this year. If we set them up now to use Microsoft Federated Gateway to share free\busy information what happens when these users start to move to O365, will the on-premise users lose the ability to see free\busy for those users from the other organization that have moved to O365?

Microsoft

Hi Manju,


I deal much more with reactive support (break/fix ) than planning / consulting so you might need to check with an MS Customer Engineer/ Consultant /Partner for deployment advices.

In short, this is what I think of :

- Set bidirectional Organization Relationships between the two on-premises organizations (DAuth)

- Possibly Multi-hybrid setup with same tenant: https://docs.microsoft.com/en-us/exchange/hybrid-deployment/hybrid-with-multiple-forests#multi-fores... 

- Configure Hybrid Mesh using Organization Relationships (DAuth): https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910 

 

In the future, Engineering team might introduce Hybrid Mesh with IntraOrganization Connectors (OAuth) and would simplify things in terms of free/busy between hybrid organizations.

Copper Contributor

@Mirela_Buru 

Hi, Mirela,

 

Run "Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses" , get below error, how to get all "OnPremises configuration objects"?

**********************************

PS C:\Windows\system32> Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses
Multiple OnPremises configuration objects were found. Please use the OrganizationGuid parameter to select a specific OnPremises configuration object.
+ CategoryInfo : ObjectNotFound: (:) [], MultipleOnPremi...sFoundException
+ FullyQualifiedErrorId : [Server=HK2PR01MB3379,RequestId=3421c258-a398-433f-92de-b1f45202a1b4,TimeStamp=4/20/2021 9:19:04 AM] [FailureCategory=Cmdlet-MultipleOnPremisesOrganizationsFoundException] 4AA83A1B
+ PSComputerName : outlook.office365.com

*************************************************

Thanks with best regards,

Peter

Microsoft

@peter1872 
Hi Peter,

 

You probably have multiple Exchange on-premises forests? if yes, get the GUID value from on-premises Get-OrganizationConfig or cloud's Get-OnPremisesOrganization and use it for the Get-IntraOrganizationConfiguration -OrganizationGuid <GUID> command, see cmdlet documentation here: Get-IntraOrganizationConfiguration (ExchangePowerShell) | Microsoft Docs

Copper Contributor

@Mirela_Buru 

Hi, Mirela,

Thanks for your answer, I got it.

 

Thanks with best regards,

Peter

 

Copper Contributor

Hello Mirela,
I have a question regarding the time interval after the configuration changes become active. How long do I have to wait to see if the changes take effect? Or how can I be sure that the changes are already active and there may be other errors?

Best regards
Ingo Weidner

Microsoft

Hi Ingo,

If you refer to changes like disabling / enabling IntraOrganization Connectors or Organization Relationships or setting TargetSharingEpr, should be instant. Checking the free/busy result (you can use exrca.com Free/Busy test) before and after making the changes is usuallt enough to understand if it works or if the error message changed.

Microsoft

I found the problem.

Manually set 'TargetSharingEpr' URLs in EXO will be removed when Exchange 2019 HCW runs.

Copper Contributor

Hi Mirela

 

I'm looking at a curious problem at my site where all users have been AD Connect synced, mailboxes created in 365 afterwards and thereafter mailbox content migrated to 365. Last the old Exchange 2010 server was uninstalled without any problems. This is more than a year ago.

 

The problem is that from the Outlook App it is not possible to see free busy time in other users calendars. If I set the permissions to Reviewer on the calendar the users can see the content, but switching back to only see free busy info again the Outlook app just shows the "updating" text in the top of the calendar. This is both in online and cached mode. Outlook on the web shows it correctly. Teams also shows it fine.

 

This is also only a problem when doing it from a domain joined computer. If I set up the accounts on a non-domain joined computer. Both "old" users created before the sync and migration and new users are affected. Also tried creating a cloud-only user an accessing that calendar with the Outlook App, but the same problem appears here.

 

I have searched high and low for posts describing similar issues and I have found a bit, but mostly related to a hybrid setup and non that have helped me pinpoint the exact reason. Please be aware that this have never been an actual hybrid setup, but AD Connect was up and running while the Exchange 2010 server was running (though not configured for hybrid).

 

So I'm hoping that you might be able to help a bit with this :)

 

Best and many thanks for your time

Thomas

 

Copper Contributor

Hello, Thank you for this hearty article. however I have the same problem. my Onprem users cannot see Online rooms or online user availability. on owa the OnPrem users can see all the online rooms but on outlook desktop they only see the OnPrem rooms. could you help me solve this problem ?

 

OnPrem

Windows\system32>Get-OrganizationRelationship |FL Identity, DomainNames, Enabled, Free*, Target*
Creating a new session for implicit remoting of "Get-OrganizationRelationship" command...


Identity : On-premises to O365 - 3cab0bd4-b6bc-4ed-xxxxx....
DomainNames : {myDomain.mail.onmicrosoft.com}
Enabled : True
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
TargetApplicationUri : outlook.com
TargetSharingEpr :
TargetOwaURL : http://outlook.com/owa/MyDomain.com
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

 

Online

PS C:\Windows\system32> Get-OrganizationRelationship |FL Identity, DomainNames, Enabled, Free*, Target*


Identity : O365 to On-premises - 0f1e6abe-beea-40ea-bc26-xxxxx
DomainNames : {MyDomain.com}
Enabled : True
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
TargetApplicationUri :
TargetSharingEpr :
TargetOwaURL : https://mail.MyDomain.com/owa
TargetAutodiscoverEpr :

Copper Contributor

This article is great. I'd love to see it amended to include the new Modern Hybrid details. Specifically related to the app proxy for free/busy. 

Copper Contributor

@Geek_Ndongo 

I have the exact same problem as you, were you able to solve it somehow ?

 

Thanks.

Copper Contributor

hi @alessiodiangelo 

 

my targetappliactionUri was empty on exchangeOnline


i have added targetapplicationUri : FYDIB…………LT.mydomain.com

 

https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationrelationship?view=excha...

 

Copper Contributor

I second the motion by GaryLowell, This article is great, thank you. I'd love to see it updated to include the new Modern Hybrid details. Specifically related to the hybrid agent service and Azure app proxy.

Microsoft

@ProfileX , @GaryLowell ,I know I am very late in answering, but I can try to update the article to include this. The difference with the New Modern Hybrid Agent is that IntraOrganization connector / Org Relationship in EXO will have TargetSharingEpr set to https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx . And I have another article on troubleshooting Hybrid Agent: Modern HCW (Hybrid Agent): troubleshooting like a pro - Microsoft Community Hub
Also, this image from another blog, although it is for migration endpoints, it basically shows the Modern Agent configuration in EXO: Troubleshooting Hybrid Migration Endpoints in Classic and Modern Hybrid - Microsoft Community Hub

Mirela_Buru_0-1692023874426.jpeg

 

Version history
Last update:
‎May 15 2020 05:22 PM
Updated by: