The Availability service improves information workers' calendaring and meeting scheduling experience by providing secure, consistent, and up-to-date free/busy information. By default, this service is installed with Microsoft Exchange Server 2007. In cross-forest topologies where all connecting client computers are running Outlook 2007 or higher, the Availability service is the only method of retrieving free/busy data.
You can use the Availability service in cross-forest topologies across trusted or untrusted forests. The type of free/busy information returned is determined by whether the cross-forest free/busy data is configured as a per-user or an organization-wide service. Per-user free/busy information requires a trusted cross-forest topology and makes it possible for the Availability service to make cross-forest requests on behalf of a particular user. This also allows a user in a remote forest to grant a cross-forest user access to detailed free/busy information.
However, with organization-wide free/busy data, the Availability service can make cross-forest requests only on behalf of a particular organization and the queried user's default free/busy information is returned. It's not possible to control the level of free/busy information that's returned to users in the other forest.
To configure the Availability Service in a cross-forest topology you need to consider some important components. Depending on the scenario, the requirements to implement cross-forest availability will change.
In an Exchange 2007 cross-forest scenario, the only method for sharing free/busy information between forests is the Availability service. Because legacy Outlook clients or legacy mailbox owners can't use the Availability service, they're unable to retrieve free/busy information for users outside their forest, unless that information stored in public folders is somehow replicated between the forests. If you're running Office Outlook 2003 or earlier, you must use the Microsoft Exchange Server Inter-Organization Replication tool to synchronize free/busy data across multiple forests.
The Autodiscover service plays an important part in this scenario by locating and providing the external and internal URLs of the Avaialbility service (for cross-forest availability) to Outlook 2007 clients and Exchange 2007 Client Access Server. That means the CAS in the source forest must be able to connect to the Autodiscover service in the target forest to retrieve the Availability service Url.
For the cross-forest availability scenario, there are basically two options to configure Autodiscover:
Note: In a cross-forest topology, Exchange 2007 CAS can't use DNS Service Location (SRV) records to locate the Autodiscover service in the target forest.
The cross-forest Availability service has a time limit when the service performs an Autodiscover service request for cross-forest users in the Active Directory directory service. By default, this time-out value is 10 seconds. If the Autodiscover request does not finish in 10 seconds, the Availability service request for the cross-forest user may time out.
When an Exchange 2007 CAS in the source forest queries the availability service in the target forest, it randomly picks an Exchange 2007 CAS in the target forest, which means all of them have to be reachable from the source forest and the EWS InternalUrl must be resolvable from the source Exchange 2007 CAS servers. For details, see the following articles:
In Exchange 2010, you can use sharing policies to share users' calendar with free/busy information and contact information with users in external federated organizations. For details, see Understanding Federation and Configure Sharing Policy Properties.
In the scenario bellow we will configure cross-forest availability service between two Exchange 2007 forests which has a two-way trust relationship. We use the terms source forest for the forest which has the user mailbox that's making the query (contoso.local in this scenario) and target forest for the forest which has the user whose free/busy information is being queried (nwtraders.local in this scenario).
Following is the decision work flow that walks you through the entire process of configuring cross-forest Availability service for two Exchange 2007 organizations or a mixed environment with Exchange 2010 and Exchange 2007.
Although a trust relationship is not required to configure cross-forest availability service, the commands you run to configure it will vary for both scenarios.
If a trust relationship exists between the two forests, run the following commands.
In the source forest:
Add-AvailabilityAddressSpace -ForestName nwtraders.com- AccessMethod PerUserFB -UseServiceAccount $true
In the target forest:
Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "contoso\Exchange Servers"
If there's no trust relationship between the source and target forests, you'll need a user account in the target forest (nwtraders.local). In this example, we use an account named freebusy. Run the following commands.
Add-AvailabilityAddressSpace -ForestName nwtraders.com -AccessMethod OrgWideFB -Credential (Get-Credential)
When prompted for credentials, type nwtraders\freebusy and enter the password.
Set-AvailabilityConfig -OrgWideAccount freebusy
Autodiscover is an essential component for successful implementation of cross-forest availability service. In a trust relationship scenario, you have two options to configure it: export the SCP from the target forest or use DNS to query the host record autodiscover.targetforest.com.
Export-AutodiscoverConfig -TargetForestDomainController "dc.contoso.com" -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true
Type contoso\Administratorwhen prompted.
See Configuration tips and common troubleshooting steps for multiple forest deployment of Autodiscover service for some additional info.
In a trust or untrusted scenario, the Exchange 2007 CAS can query DNS to resolve autodiscover.targetforest.com. In this case, you need to create a host record for autodiscover.nwtraders.com.
Note: Autodiscover returns the Availability InternalUrl to the Exchange 2007 CAS
Regardless of whether you have a trust between the two forests, the Exchange 2007 CAS in the source forest must validate the certificate installed on each Exchange 2007 Client Access Server in the target forest.
After exporting the self-signed certificate or the root CA certificate from the target forest, you'll need to import it to the computer's certificate store (MMC -> Certificates -> Computer Account -> Trusted Root Certification Authorities) on each Exchange 2007 CAS server in the source forest.
Test AutoDiscover and Availability service (depending on the option you chose for Autodiscover):
Exported SCP: From the Exchange 2007 CAS in the source forest (contoso.local), browse the SCP and the EWS InternalUrl of the target forest (nwtraders.local). To retieve the SCP and EWS InternalUrl, run this command in the target forest.
Get-ClientAccessServer | fl name, auto* Get-WebServiceVirtualDirectory | fl name, InternalUrl
DNS: From the Exchange 2007 CAS in the source forest (contoso.local), browse the "autodiscover.nwtraders.com" and Availability service InternalUrl of the target forest (nwtraders.com):
Get-WebServicesVirtualDirectory | fl name, InternalUrl
Make sure the following components are working correctly:
Some of the above information was taken from the following references:
Thanks to Nagesh Mahadev, Julio Vieira and Georg Hinterhofer for their contributions and reviews.