How to Share Free/Busy Information Without Using Federated Delegation

If you have a two-way forest trust in place between two organizations, such as during a merger, you can share calendar free/busy information between two Exchange organizations without having to configure federated delegation.

Federated delegation is usually the way to go since it offers more than just free/busy sharing.  With federation using the Microsoft Federated Gateway Server service you can share limited details between business partners.  In addition to free/busy information you can share meeting subjects, attendee, and location information.

Federated delegation works by brokering a trust between two different SMTP domains. The following diagram shows how this brokered trust works between contoso.com and fabrikam.com:

Federated delegation between contoso.com and fabrikam.com

To see more information about federated delegation see my articles, How to Configure Exchange 2010 SP1 Federation and Exchange Federated Free/Busy doesn't work in one direction.

Because federated delegation relies on different SMTP domains, it won't work during a merger/migration where both companies share the same SMTP domain (contoso.com).  The answer is to use the Add-AvailabilityAddressSpace cmdlet in both orgs.  

Be aware that the TechNet documentation for the Add-AvailabilityAddressSpace cmdlet is inaccurate/incomplete. It says this cmdlet is only supported on Exchange 2010 SP2 and Exchange 2010 SP3 when it's actually supported on all versions of Exchange 2007 through Exchange 2013.  It also misses some crucial steps, which I've added below.

Here's how to configure simple free/busy sharing information when both orgs share the same SMTP domain. For the examples below, the source domain is the one retrieving the free/busy info from the target domain. It is assumed that both domains already have a two-way forest trust configured and DNS forwarding is configured.

• Run the following cmdlet in the target domain:

Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "sourcedomain\Exchange Servers"

• Run the following two cmdlets in the source domain:

Add-AvailabilityAddressSpace -ForestName targetdomain.com -AccessMethod PerUserFB -UseServiceAccount $true

Export-AutodiscoverConfig -TargetForestDomainController dc.remotedomain.com -TargetForestCredential $Target -MultipleExchangeDeployments $true

After these steps are performed the users in the source domain can see free/busy information for users in the target domain.  Repeat these steps, switching the the source and target domains, to allow bidirectional free/busy look-ups.

Be aware that the source domain relies on Autodiscover and Exchange Web Services (EWS) in the target domain.  If Autodiscover is not configured properly (i.e., missing the autodiscover.targetdomain.com record in DNS) it will not work.  It also relies on the externalUrl property of the WebServicesVirtualDirectory in the target domain.  That must be set to a valid URL and the SSL certificate used by this EWS URL must be trusted by the source domain.

It's also important to know that autodiscover will automatically redirect to the SMTP domain of the targetAddress property if it's configured.  That means if you have a mailbox user or mail enabled user in contoso.com with a targetAddress configured for fabrikam.com, autodiscover will redirect to autodiscover.fabrikam.com for connection information.