Cross-Forest Availability with Exchange 2007 and Exchange 2010

Prior to Exchange 2007, Exchange stored F/B information in Public Folders, and Outlook clients knew where to go in the Public Folder store to find the data. With the desire to move away from Public Folders, this information became available via Exchange Web Services (EWS), also sometimes called the Availability Service (AS). This is a SOAP based web service hosted on the CAS server and accessible via HTTPS. Outlook 2007 and newer knows how to access this endpoint as does Outlook for Mac and various other EWS clients. Exchange 2007 also introduced the ability to provide a means for cross-organization F/B info without any complex public folder replication. The way this works is you define an “availability address space” in Exchange which tells Exchange for a given subdomain, send those F/B requests over to a different AS endpoint. This is a very common scenario particularly with mergers and acquisitions. Let’s consider one such scenario and see how to set this up (as well as how it works).

In an effort to become Santa’s sole source cargo supplier, your employer, Wing Tip Toys (wingtiptoys.com), acquires the Fabrikam Coal Company (fabrikam.com). You manage the Exchange 2010 organization for Wing Tip Toys, and Fabrikam Coal runs Exchange 2007. Later in the merger process, you’ll consolidate Fabrikam into your organization, but, as soon as the merger closes, you’ll need to make it possible for Wing Tip Toys users to view F/B information for Fabrikam users. To do this, you need to configure an Availability Address Space in your Exchange organization for fabrikam.com. You can do this using these PowerShell commands:

# These credentials are a standard mailbox enabled user in the Fabrikam organization
$credentials = Get-Credential

Add-AvailabilityAddressSpace -ForestName "fabrikam.com" -AccessMethod OrgWideFB -Credentials $credentials

This tells Exchange to route F/B requests for *@fabrikam.com to a CAS in the fabrikam.com organization. In order to find Fabrikam’s CAS servers, your CAS servers will use Autodiscover. One important thing to note is that your CAS will ONLY use this route we’ve defined if the Fabrikam user we’re trying to retrieve F/B info for has a Contact or Mail Enabled User (MEU) in the Wing Tip Toys Active Directory environment. That contact or MEU must have a targetAddress which ends with @fabrikam.com.

Note: targetAddress is the name of the attribute in Active Directory. The *-MailContact and *-MailUser cmdlets as well as the Exchange Management Console refer to this attribute as the ExternalEmailAddress.

Here’s a quick (simplified) diagram of what happens:

WTT user looks up F/B info for john@fabrikam.com.
WTT CAS searches Active Directory for a contact or MEU with a targetAddress of john@fabrikam.com.
Active Directory returns a match.
WTT CAS performs an Autodiscover search for Fabrikam.com (this includes all of the usual Autodiscover mechanisms).
Fabrikam returns Autodiscover results.
WTT contacts Fabrikam’s availability service (authenticating with the credentials provided earlier) and asks for information pertaining to john@fabrikam.com.
Fabrikam’s AS returns information to WTT’s CAS.
The WTT CAS returns the information to the user.

Warning: This behavior is different for Outlook 2003 clients. Outlook 2003 clients have no knowledge of the Availability Service and as such they only obtain F/B info from Public Folders. Exchange 2010 SP1 introduced a change in behavior whereby F/B requests to Public Folders for users which are in a different forest are intercepted. The mailbox server intercepts these Public Folder requests and performs steps 4 – 7, contacting the remote CAS directly. If you’ve made firewall rules on the basis that only CAS servers perform cross-forest availability lookups, you’ll need to adjust those rules accordingly.

When testing cross-forest F/B lookups, you may need some extra logging to sort things out. The best place to collect this data without engaging PSS is actually in the Outlook client. You can enable this logging by opening Outlook’s Options (either via the Tools menu in Outlook 2007 or backstage in Outlook 2010), and then going to Advanced. Check the “Enable troubleshooting logging” box and restart Outlook. When you make future Free/Busy requests, you’ll find those logged under %temp%\olkas.