Configuring Cross Organization Free Busy Information in Exchange 2013


There are many times when you will have an outside organization that you wish to share free busy information with.  Starting with Exchange 2010, Microsoft introduced the ability to utilize their Microsoft Federation Gateway to facilitate the sharing of free/busy information across multiple organizations.  While that solution works really well, there are times when that might not be the best solution.  For instance, you may have a customer in the middle of a large scale migration, or a partner company that you have connectivity to.  In these situations, you can utilize the direct method of establishing and configuring sharing free busy information.  This method, does require the two exchange organizations to have some level of connectivity to each other.  There are two direct methods that you can use. 

You can leverage the forest trust model, which indicates that you have a forest between between the two Exchange Organizations.  This would mean that you have a high level of network connectivity and integration between the two organizations.  The benefit to this method is that you can assign per user based permissions.  Meaning Paul from Forest A can have expanded rights to Jon from Forest B’s mailbox for free and busy. 

The second option is to use the non trusted forest based model.  This means that there is no forest trust between the networks.  Instead a general service account is leveraged to secure the permissions.  This means that the free and busy info is assigned organization wide, meaning you lack the granularity to assign different permissions per user.

I’ll walk through and explain both methods.  For our lab, we have the E15.corp forest, running Exchange 2013, and SOA.corp running Exchange 2013.

Trusted Forest Mode:

So the first thing we need to do is assign the mailbox servers in each forest to have the ms-exch-epi-token-serialization right on the remote forest’s mailbox servers.  If this is an Exchange 2010 or Exchange 2007 environment, change out mailbox servers for cas servers.

In the SOA.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “E15.corp\Exchange servers”


In the E15.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “soa.corp\Exchange servers”


So now, the Mailbox Servers from each forest, have the permission’s necessary. 

Next, in each forest, you need to add the availability space so that Exchange knows to look up that space for Availability.  Here is also where we will tell Exchange that we will use the Per User format.  In the SOA.corp domain run:

Add-AvailabilityAddressSpace -Forestname e15.corp –AccessMethod PerUserFB -UseServiceAccount:$true


For the ForestName parameter, mine is E15.corp because it’s a test lab, but this should be the SMTP namespace of the far side domain.  So if the far side is, replace my E15.corp with

Then, in the E15.corp domain run the following:

Add-AvailabilityAddressSpace –Forestname soa.corp –AccessMethod PerUserFB -UseServiceAccount:$true



Next, we need to tell the soa.corp domain how to retrieve free and busy information from the e15.corp domain.  By default, it will use DNS and attempt autodiscover.e15.corp.  So ensure your source forests can resolve that address, and that they trust the certificates of the far side domain.

You can also export the Service Connection Point from one side and import it into the other.

In the E15.corp domain, to export it’s autodiscover information to the Soa.corp domain, run:

Export-AutodiscoverConfig -TargetForestDomainController “phdc-soadc01.soa.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

Replace the TargetForestDomainController value with the FQDN of your far side domain controller.  And then enter in credentials in the destination forest:



In the SOA.corp, run the same command but specify it for the E15.corp domain:””

Export-AutodiscoverConfig -TargetForestDomainController “phdc-e15dc01.e15.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true


You can check the SCP in your local domain by opening ADSIEDIT and connecting to the Configuration Partition, then browsing to Services->Microsoft Exchange Autodiscover

This is a screen shot from soa.corp showing the SCP info for E15.corp:


Untrusted Forest Mode:

If you don’t have a forest trust between the two forests, you can still do free busy, but you can only share it on an organization wide basis.

In the E15.corp forest, create a user named FreeBusyE15@e15.corp.  This can be a regular user account with no mailbox.

In E15.corp run the following:

Set-AvailabilityConfig –OrgWideAccount e15.corp\freebusye15

In the SOA.corp forest, create a user named FreeBusySOA@soa.corp.  This can be a regular user account with no mailbox.

In SOA.corp run the following:

Set-AvailabilityConfig –OrgWideAccount soa.corp\freebusySOA

Next, in the E15 forest, run the following command to configure the availability service to SOA.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential soa.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest Soa.corp –AccessMethod OrgWideFB –Credentials $a

Next, in the SOA forest, run the following command to configure the availability service to E15.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential E15.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest E15.corp –AccessMethod OrgWideFB –Credentials $a

Syncing the GAL:

So, you need to sync the GAL to make contact objects available across both domains.  Meaning, the Mailboxes of E15.corp get created as mail contacts in SOA.corp and vice versa.  This allows your users to select them from the GAL and perform free/busy lookups.

For the sake of our article, I’ll manually create a mailbox called pponzeka@e15.corp in E15.corp and then manually create a mail contact called pponzeka@e15.corp in SOA.corp.  Then I’ll test with an SOA mailbox to see if I can perform cross forest free busy.

In the pponzeka@e15.corp mailbox, ill create a meeting for tomorrow between 3 PM and 5 PM named E15 Corporate Meeting:



We open Outlook for the user very imaginatively named, Soa-User1, go to create a new appointment and select the Scheduling Assistant.  If we click Add Attendees and see that we have a Paul Ponzeka with the globe icon, indicating he is a Mail Contact:


And confirmed!  Working cross forest free/busy:




  1. Peter

    Great Article
    But are these really the only steps to take to enable free/busy between two Exchange 2010 organizations with a forest trust? With a forest trust, I suppose you don’t need federation services? Isn’t?
    It’s not clear for me, but with a forest trust in place, do you need a GAL sync to get free/busy to work cross-organization?

  2. Simon

    Hi, great post! Can you confirm whether the sync of Contacts are required using full federation? I see there is a Quest tool to auto sync users to contact records in the other domain, but if federation does not require this I would go that way.

  3. Luis

    HI Port25guy,

    done exactly as described and doesn’t worked; Free/busy will not display. I’ve also configured a Federation Tust

    Any tips?

    1. Simon

      Hi, there are caveats with this approach… but it does work. With this approach you have to create contact records either side in exchange for it to work. It wont work if you just type in an email address. And there is no free tool to create contacts automatically, but it is fairly simple to export mail enabled users and create contact records on the other side. But then you have to deal with people joining / leaving the orgs. With org sharing or federation you use MS gateway to connect, but the same caveat applies with the contacts. With 2013 it does work just typing the email address.

Comments are closed.