Correctly Setting Up and Configuring Free/Busy Lookups in Cross-Forest Environments Using the Availability Service in Microsoft Exchange

What’s this all about? The Microsoft Exchange Availability service provides secure, consistent, and up-to-date free/busy information to clients that are running Outlook. By default, this service is installed with Exchange Server 2013. In cross-forest topologies where all connecting clients are running Outlook, the Availability service is the only method of retrieving free/busy information. However, configuring the Availability service for cross-forest is a bit like a branching tree—with each path depending on your environment and functional requirements.

Configuring Free/Busy Lookups in Cross-Forest Environments Using the Availability Service in Microsoft Exchange

This post will address how to correctly set up and configure free/busy lookups for users of Outlook 2013, 2010 and 2007.  A subsequent post will address Outlook 2003 users.

Trust is the First Consideration
When setting up and configuring free/busy lookups, your first decision is whether or not to establish a trust between the two forests. While both trusted and untrusted users are able to view general free/busy status, in the absence of a trust, they will not be able to view calendar details. So, if your users expect that they’ll be able to grant their cross-forest colleagues the ability to see that Friday dentist appointment, you’ll need to have a trust in place.

Cross-Populate Placeholder Objects in the Directories
The next decision (and often the most challenging one) is how to cross-populate placeholder objects in opposing directories. Essentially, there has to be an object that users can view within Outlook, and then select from the GAL (global address list), in order to browse a user’s availability. Given the potential for a massive headache, you want to avoid hours, or likely days, of troubleshooting because your objects were created incorrectly. If migration is your ultimate goal, create the objects as mail-enabled users from the start—do not create contact objects, because you’ll add the unnecessary step of having to delete them later.

Officially, Microsoft recommends using Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) to create the objects. Personally, I have not used FP1 very often, and am unable to provide much feedback as to the pros and cons. Instead, I recommend Binary Tree’s SMART Directory Sync. It’s easy to setup, syncs group membership, and can be configured to run on a schedule to keep both environments up to date. For quick validation tests, where I don’t want to install any software, I typically use Microsoft’s Prepare-MoveRequest script, included with every installation of Exchange 2010 or greater. The mail-enabled users created by the script are 100% compatible with cross-forest Availability service sharing.

Verify Connectivity on Both Sides
The next step is to verify that your Exchange servers, on either side, can resolve the Availability service end points. One easy way to see if you are set up correctly is to simply use the Auto-Discover service that’s part of Outlook 2007 or greater. If you can attach to a mailbox in the opposing forest without any intervention, everything’s good. But, if you receive any type of error in the configuration of the profile (certificates are a common one), it is very unlikely to work. Even though I’ve had a few occasions where Outlook was able to configure itself, availability information was not visible. In those cases, I’ve ‘CTRL-Right Clicked’ on the Outlook system tray icon and executed the ‘Test Email Auto-Configuration’ test in order to determine the cause of the problem. Only check the “Use AutoDiscover” box and pay special attention to all of the URLs returned in the "Results” window (and especially the Availability Service URL).

Commands to Run to Start the Availability Service
Once you have verified connectivity on both sides, and created some test mail-enabled users, you can run the commands to get things going.

If you look at the first command below (executed on Forest A), you’ll see that you are granting the remote forest a new right on all of your local mailbox servers. The second command (executed on Forest B) says, when looking up the availability service info for a mail-enabled user whose ‘TargetAddress’ attribute is, use this alternate method to gather that information.

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedright "ms-Exch-EPI-Token-Serialization" -User ForestB\Exchange servers"

Add-AvailabilityAddressSpace -Forestname -AccessMethod PerUserFB -UseServiceAccount:$true

If you don’t have a trust in place (or if it’s a one-way trust), you’ll need to use the format specified below. Create an account in Forest A and verify that he is ONLY a member of the Domain Users group. Then, run these 3 commands in Forest B:

Set-AvailabilityConfig -OrgWideAccount "ForestA\UserA"

$a = Get-Credential (Enter the credentials ForestA\UserA)

Add-AvailabilityAddressspace -Forestname -Accessmethod OrgWideFB -Credential:$a

Bottom Line: If your trust is in place, and Autodiscover works, congratulations—you should now be seeing your test accounts free/busy info within Outlook! Please watch for my next post where I’ll describe a scenario where your users are still on Exchange 2003 or utilizing Outlook 2003.