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 contoso.com, replace my E15.corp with contoso.com.
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 email@example.com in E15.corp and then manually create a mail contact called firstname.lastname@example.org in SOA.corp. Then I’ll test with an SOA mailbox to see if I can perform cross forest free busy.
In the email@example.com 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: