Notes from the Field – Free and Busy without federation Gateway

If you want to share free and busy details between two Exchange organizations, you usually use the Microsoft Federation Gateway. Sometimes this is not possible, e.g., for compliance reasons, or other business reasons. But there exists a way to do this, even without an Active Directory trust between two organizations.

Let us say we have two Exchange organizations: and

The prerequisites are:

  • you can resolve and access the target AutoDiscover-endpoint from the source domain infrastructure (hint: you can use pin-point DNS zones)
  • you can resolve and access the Exchange Web Services (EWS) endpoint from the source domain infrastructure (note that the Availability Service (AS) accesses the InternalUrl)
  • you add an account in each Active Directory forest which does not have any specific permissions assigned (membership of “Domain Users” security group is sufficient, no mailbox needed). 

I will use user account freebusy in this example.

Execute the following in Exchange organization using Exchange Management Shell:

$TargetSmtpDomain = ''$TargetDomainAccount = 'adatum.comfreebusy'Add-AvailabilityAddressSpace - Forest $TArgetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('')[1]


Execute the following in Exchange organization using Exchange Management Shell:

$TargetSmtpDomain = ''$TargetDomainAccount = 'contoso.comfreebusy'Add-AvailabilityAddressSpace - Forest $TargetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('')[1]


Exchange Server in the source organization must be able to resolve the recipient address for requesting free/busy information from the target organization. Exchange Server can determine a target address accurately when you create the recipient object as a contact in the source Exchange organization. 

For this example, you create contact objects in for all user in and vice versa. You can use GalSync or any other identity management (IDM) software that can handle object synchronization.



When using Exchange Server 2013, or 2016, you may run into a problem.

The HttpProxy log of the requesting Exchange Server log will state that AutoDdiscover failed for generic mailbox (or

HttpProxy log excerpt:

2019-07-26T07:19:24.649Z,2827102f-75b1-4ecb-ae6c-36b075bb8e93,15,1,1779,2,,Autodiscover,,/autodiscover/autodiscover.xml,,Basic,true,CONTOSOfreebusy,,MailboxGuid~01b62c6d-4324-448f-9884-5fec6d18a7e2,ASAutoDiscover/CrossForest/EmailDomain//15.01.1779.002,,CONTOSO-EX1,404,,MailboxGuidWithDomainNotFound,POST,,,,,AnchorMailboxHeader-MailboxGuidWithDomain-NoUser,,,,381,,,,0,,,0,1;0;,1,,0,1,,0,4,0,,,,,,,,,0,3,0,,3,,3,3,,,,BeginRequest=2019-07-26T07:19:24.646Z;CorrelationID=;ProxyState-Run=None;;;ProxyState-Complete=CalculateBackEnd;SharedCacheGuard=0;EndRequest=2019-07-26T07:19:24.649Z;I32:ADS.C[CONTOSO-DC1]=2;F:ADS.AL[CONTOSO-DC1]=0.8201787,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Cannot find mailbox 01b62c6d-4324-448f-9884-5fec6d18a7e2 with domain    at Microsoft.Exchange.HttpProxy.AnchorMailbox.CheckForNullAndThrowIfApplicable[T](T ret)    at Microsoft.Exchange.HttpProxy



If DNS is used to resolve the AutoDiscover endpoint of the target Exchange organization, the source Exchange organization queries AutoDiscover information for a mailbox with that uid. SCP-based AutoDiscover lookup does not use this dedicated uid-based email address.



To solve this issue, you add the required SMTP address found in the HttpProxy log to one user mailbox in the target organization.

In the organization:

Set-Mailbox -Identity '' -EmailAddresses @{add=''}


In the organization:

Set-Mailbox -Identity '' -EmailAddresses @{add=''}



%d Bloggern gefällt das: