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.

Considerations

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.

Requirements:

  1. You must sync the Global Address List (GAL) between forests.
  2. Autodiscover service must be working between forests.
  3. All Exchange 2007 Client Access Servers must validate the certificate on the target forest.

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.

Cross-Forest Availability and the Autodiscover Service

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:

  1. If there's a trust relationship between the two forests, you can export the Service Connection Point (SCP) from the target to the source forest. For details, see How to Configure the Autodiscover Service for Multiple Forests.
  2. Use DNS to resolve the (default AutoDiscover) FQDN autodiscover.targetforest.com.

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.

The Scenario

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).


Figure 1: The topology

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.


Figure 2: Decision work flow for configuirng cross-forest Availability service

Cross-Forest Availability Service Flow

  1. To configure the availability service for a cross-forest topology, you must install and configure GAL Synchronization (GALSync). For information about how to install and configure the GALSync feature in Microsoft Identity Integration Server (MIIS),
  2. 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.

    1. In the source forest:

      Add-AvailabilityAddressSpace -ForestName nwtraders.com- AccessMethod PerUserFB -UseServiceAccount $true

    2. 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.

    1. In the source forest:

      Add-AvailabilityAddressSpace -ForestName nwtraders.com -AccessMethod OrgWideFB -Credential (Get-Credential)

      When prompted for credentials, type nwtraders\freebusy and enter the password.

    2. In the target forest:

      Set-AvailabilityConfig -OrgWideAccount freebusy

  3. 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.

    1. In a trust relationship scenario, run this command in the target forest (nwtraders.local) to export the SCP from the target forest to the source forest:

      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.

    2. 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

  4. Certificate Validation

    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.

    • self-signed certificate: If a is installed on the Exchange 2007 CAS in the target forest, you must export it.
    • untrusted root: If the server has a certificate signed by an untrusted root CA, you'll need to export the root CA certificate.
    • trusted root: If a certificate issued by a trusted CA is installed on the Exchange 2007 CAS, which is the best and recommended solution, you don't have to export and import the certificate unless there's any issue with certificate validation.

    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.

  5. Test Autodiscover and Availability Service

    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

  6. Test cross-forest free/busy

    Make sure the following components are working correctly:

    • Autodiscover is working on each forest
    • Availability service is working on each forest
    • Autodiscover is working cross forest using DNS or a SCP
    • EWS Internalurl in the Target forest is accessible from the Exchange 2007 CAS in the source forest
    • There's no certificate validation error when accessing Autodiscover or the EWS InternalUrl
    • Finally test cross-forest free/busy from Outlook 2007

Additional Reading

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.

Vandy Rodrigues