Blog Post

Exchange Team Blog
7 MIN READ

How to Configure the Availability Service for Cross-Forest Topologies

The_Exchange_Team's avatar
The_Exchange_Team
Icon for Microsoft rankMicrosoft
Mar 04, 2011

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

Updated Jul 01, 2019
Version 2.0
Client Access
Exchange 2007
mailbox
  • Deleted's avatar
    Deleted
    Mar 06, 2011
    Very usefull informations. Thank you.
  • Deleted's avatar
    Deleted
    Mar 08, 2011
    what about using a shared SMTP namespace?
  • Deleted's avatar
    Deleted
    Mar 08, 2011
    "from the cas in the source.."
    and
    "That means the CAS in the source forest must be able to connect to.."

    What if you have no Cas in your source Forest, i.e the Account Forest?
    Users had Exch 2003 in Source, migrated their mailboxes to Exchange 2010 Resource Forest.


  • Deleted's avatar
    Deleted
    Mar 08, 2011
    Hi Binny,

    Cross-forest Free/Busy does not work with a shared SMTP addrees for the following reason, see the scenario bellow, unless if you're using PF replication rather than availabiltiy service.

    1. Outlook 2007 clients in the source forest (Forest A) connect to the EWS InternalUrl to get free/busy information for users from Forest A.
    2. For users in the target forest (Forest B), which is a cross-forest request, the CAS from the source forest needs to find A record for autodiscover.forestb.com or make an LDAP call if you exported the SCP from the target forest into the source forest.
    3. In the source forest (Forest A), you have all the contacts from the target forest (Forest B).
    4. Once you add a contact in outlook 2007, the exchange identifies the contact and knows this is going to be a cross-forest free/busy request.
    5. The CAS in the source forest (Forest A) reads the information from Add-AvailabiltiyAddressSpace you ran previously to decide if the CAS is going to query the availability service or a Public Folder
    6. In your scenario, you ran the cmdlet to use the Availability service which will depend of the autodiscover.
    7. The CAS in the source forest (Forest A) will try to find autodiscover.forestb.com, and then after that will return the EWS InternalUrl of the remote CAS to query free/busy for users in the target forest.
    8. Here is the issue, since you have the same SMTP address in both forest. Autodiscover does not work in this type of scenario because it will query the wrong forest that does not have the object, since autodiscover cannot point to different organizations.
    10. This is how the code was design to work.

    Options to solve the problem:

    If you want to keep the same SMTP address on both forest, then you will have to use old fashion way with Public Folder querying the free/busy.
    1.Add-AvailabilityAddressSpace -ForestName <example.contoso.com> -AccessMethod PublicFolder
    2.Then replicate the Public Folder between both forests.

    http://technet.microsoft.com/en-us/library/bb125182.aspx
  • Deleted's avatar
    Deleted
    Mar 08, 2011
    Hi Mark,

    If you have Exchange 2003 on one forest and Exchange 2010 on the other forest, then you cannot use the availability service but then rely on Public Folder replication cross-forest for free/busy information.
  • Deleted's avatar
    Deleted
    Mar 08, 2011
    Another great post. Thank you for sharing these informations.
  • Deleted's avatar
    Deleted
    Mar 09, 2011
    1. Is it possible to setup availability between non-trusted forests?
    2. When DNS Autodiscover is in use, will Exchange perform HTTP redirect check like Outlook does? It is a typical setup for multi-tenant Exchange environments.
  • Deleted's avatar
    Deleted
    Mar 09, 2011
    Hi Dmitri,

    Yes, it's possible to setup cross-forest availability service with a non-trusted forest as you can see in the work flow above asking "Is there a trust relationship between both forests?". If the answer is NO then the cmdlet is different on each forest and you will have to create a user account to access free/busy. So the post explain this scenario.

    Don't recall a single customer using HTTP redirect in a cross-forest scenarionspecially because if takes more than 10 sec to respond you'll get a timeout.
  • Deleted's avatar
    Deleted
    Mar 09, 2011
    Hi Binny,

    A shared SMTP address will not work because an important component in this scenario is autodiscover service and you cannot have it the autodiscover DNS A record pointing to two different forests. In this case the solution then is rely on Public Folder replication cross-forest for free/busy information.