Export (0) Print
Expand All
4 out of 8 rated this helpful - Rate this topic

How to Configure the Availability Service for Cross-Forest Topologies

 

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Topic Last Modified: 2012-09-24

This topic explains how to use the Exchange Management Shell to configure the Availability service for cross-forest topologies. The Availability service improves information workers' free/busy data by providing secure, consistent, and up-to-date free/busy information to computers that are running Microsoft Office Outlook 2007. By default, this service is installed with Microsoft Exchange Server 2007. In cross-forest topologies in which all connecting client computers are running Outlook 2007, the Availability service is the only method of retrieving free/busy data.

noteNote:
You cannot use the Exchange Management Console to configure the Availability service for cross-forest topologies.

You can use the Availability service in cross-forest topologies across trusted or untrusted forests. The kind of free/busy information 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 is possible only in a trusted cross-forest topology. It enables the Availability service to make cross-forest requests on behalf of a particular user. This enables a user in a remote forest to grant detailed free/busy information to a cross-forest user.

By contrast, organization-wide free/busy data enables the Availability service to make cross-forest requests only on behalf of a particular organization. In this case, a user's default free/busy information is returned, and it is not possible to control the level of free/busy information that is returned to users in the other forest.

noteNote:
The terms Source forest and Target forest are used in this topic to identify each forest. These terms are defined as follows:
  • The Source forest is the Exchange forest from which the Availability Service makes the free/busy inquiry.
  • The Target forest is the Exchange forest from which the free/busy information is being retrieved.

Depending on the scenario, you should also consider the following requirements:

  • You must sync the global address list (GAL) between forests.
  • The Autodiscover service must be working between forests.
  • All Exchange 2007 Client Access servers must validate the certificate on the target forest.
noteNote:
Microsoft Exchange Server 2007 Service Pack 3 (SP3) Update Rollup 6 uses the external URL for Exchange Web Services to connect to the target forest. The external URL for Exchange Web Services cannot be returned by the Autodiscover service if Outlook Anywhere is not enabled in the target forest. In this case, the cross-forest lookup fails.
To work around this issue, enable Anywhere in the target forest, and then verify that the external URL for Exchange Web Services is configured correctly.
  1. Enable Outlook Anywhere in the target forest. For information about how to enable Outlook Anywhere, visit the follow TechNet website: Enable Outlook Anywhere Wizard > Enable Outlook Anywhere Page
  2. Configure the external URL for Exchange Web Services for the target forest. To do this, run the following command in Windows PowerShell for Exchange:
    Set-WebServicesVirtualDirectory -identity “server_name\EWS (Default Web Site)” -ExternalURL https://mail.contoso.com/ews/Exchange.asmx
    noteNote:
    In this command, contoso is a placeholder for the actual domain name.
  3. Enable Outlook Anywhere for the organization mailboxes that will be making incoming remote availability requests.
    noteNote:
    If an administrator disables Outlook Anywhere on an individual mailbox, that mailbox's information cannot be retrieved by a remote forest because Autodiscover will not return an Exchange Web Services ExternalURL value for that mailbox.

To configure Microsoft Windows for a cross-forest topology, you must install and configure GAL Synchronization (GALSync). For complete information about how to install and configure the GALSync feature in Microsoft Identity Integration Server (MIIS) 2003, see the following resources:

This feature creates mailbox-enabled contacts that represent recipients from other forests. This lets users view the contacts in the GAL, and add them as attendees to meetings.

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 users who have mailboxes homed on earlier versions of Exchange cannot use the Availability service, they cannot retrieve free/busy information for users outside their forest unless the information that is stored in public folders is replicated between the forests.

Therefore, if you are running Office Outlook 2003 or an earlier version, you must use the Microsoft Exchange Inter-Organization Replication tool to synchronize free/busy data across multiple forests. For more information about the Microsoft Exchange Inter-Organization Replication tool, see Microsoft Exchange Server Inter-Organization Replication.

You must also run the following cmdlet from the Exchange Management Shell to set public folder free/busy availability:

Add-AvailabilityAddressSpace -ForestName "target.forest.com" -AccessMethod PublicFolder
  • To run the Get-ClientAccessServer cmdlet, the account that you use must be delegated the following:
    Exchange View-Only Administrator role
  • To run the Add-ADPermission cmdlet, the account that you use must be delegated the following:
    Exchange Organization Administrator role
  • To run the Add-AvailabilityAddressSpace cmdlet, the account that you use must be delegated the following:
    Exchange Organization Administrator role
  • To run the Set-AvailabilityConfig cmdlet, the account that you use must be delegated the following:
    Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

The Autodiscover service provides information for the Availability service by locating and providing the external and internal URLs for the Outlook 2007 client and Exchange 2007 Client Access server for cross-forest availability. That means the Client Access servers must be able to connect to the Autodiscover service on the target forest to return the Availability service URL.

In a cross-forest availability scenario, there are basically two options to configure the Autodiscover service.

  • Export the Service Connection Point (SCP) from the target to the source forest if there is trust relationship between the forests.
  • Use DNS to resolve the autodiscover.targetforest.com Web site address.
noteNote:
DNS Service Location (SRV) records do not work to locate the Autodiscover service to an Exchange 2007 Client Access server in a cross-forest scenario.

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. For more information, see the following topics:

When you install Exchange 2007 with the Client Access server role, a self-signed certificate is created. The self-signed certificate has two Subject Alternative Name (SAN) entries: one for the NetBIOS name of the Client Access server and one for the fully qualified domain name (FQDN) of the Client Access server. Therefore, if you plan to use the default self-signed certificate installed on the Client Access server, you have only one option to make Autodiscover work between both forests: You must export the SCP from the target forest to the source forest. In this scenario, you must have a trust relationship between both forests. For more information, see the following topics:

If there is no trust relationship between forests, and if you still want to use a self-signed certificate, you must reissue a new self-signed certificate and include the Subject Alternative Name for autodiscover.targetforest.com. You can use the New-ExchangeCertificate cmdlet to reissue a new self-signed certificate. For more information, see New-ExchangeCertificate (RTM).

Although the self-signed certificate can be used to encrypt communications between a Client Access server and other Exchange 2007 server roles, we do not recommend the self-signed certificate for use with client applications and devices. Because of the limitations of a self-signed certificate, we recommend that you replace the self-signed certificate with either a trusted third-party certificate or a certificate signed by a Windows PKI. For more information, see the following Exchange Help topics:

  1. In an Windows trust relationship scenario, run the following cmdlets in the source and target forest:

    Source Forest:

    Add-AvailabilityAddressSpace -ForestName "xyz.com" -AccessMethod PerUserFB -UseServiceAccount $true
    

    Target Forest:

    Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User  "Sourceforest\Exchange Servers" 
    
  2. If a trust relationship does not exist, you must run the following cmdlets in the source and target forest. In this scenario, a service account with low permissions is required in the target domain. For example, use a regular account without administrative permissions.

    Source Forest:

    $a = Get-Credential (Type the credential  "TargetForest\User"  for organization-wide user)
    Add-AvailabilityAddressSpace -ForestName "xyz.com" -AccessMethod OrgWide -Credential $a
    

    Target Forest:

    Set-AvailabilityConfig -OrgWideAccount "TargetForest\User"
    
  3. In a trust relationship scenario, there are two methods to configure the Autodiscover service. Either export the SCP from the target forest or use DNS to query the host record "autodiscover.targetforest.com."

    • In a trust relationship scenario, export the SCP from the target forest to the source forest by using the following cmdlet:
      $a = Get-Credential (Type "SourceForest\Administrator")
      Export-AutodiscoverConfig -TargetForestDomainController "dc.sourceforest.com" -TargetForestCredential $a -MultipleExchangeDeployments $true
      
      noteNote:
      After you import the SCP from a remote domain, the Autodiscover service may not work correctly, and Outlook 2007 clients may not be able to query Out of Office and Free/Busy information. For information about how to resolve this issue, see 973404, Description of the Outlook 2007 hotfix package (Outlook-x-none.msp): August 25, 2009
    • In a trusted or untrusted scenario, the Exchange 2007 Client Access server is configured to query DNS to resolve "autodiscover.targetforest.com." In this case, create a host record for "autodiscover.targetforest.com."
      noteNote:
      Autodiscover will return the Availability InternalURL to the Exchange 2007 Client Access server.
  4. Whether you have a trusted or untrusted forest, the Exchange 2007 Client Access server in the source forest must validate the certificate installed on each Exchange 2007 Client Access server in the target forest. To make sure that you are using a valid certificate, follow these steps:

    1. If a self-signed certificate is installed on the Exchange 2007 Client Access server in the target forest, you must export it. The same concept applies if there is an internal root CA and a private certificate is installed. Exchange 2007 is installed with a default self-signed Secure Sockets Layer (SSL) certificate. You can use this certificate when enabling SSL for Exchange ActiveSync, Office Outlook Web Access, and the Availability service. However, users will receive a prompt because the certificate is considered invalid by most client applications. Exchange ActiveSync and Office Outlook Web Access support proxying from one Client Access server to another Client Access server. For the proxy process to be successful when a self-signed certificate is used, you must configure the following registry keys as shown:
      HKLM\System\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts = 1 
      HKLM\System\CurrentControlSet\Services\MSExchangeOWA\AllowExternalUntrustedCerts = 1
      
    2. After you export the self-signed certificate or the root CA certificate, you will import it into the computer account store on each Exchange 2007 Client Access server.
  5. To successfully test the Autodiscover service and Availability service, use one of the following methods:

    • Exported SCP: From the Exchange 2007 Client Access server, in the source forest, go to the Autodiscover Web site, and then run the following cmdlet in the target forest:
      Get-ClientAccessServer | fl name, AutoDiscoverServiceInternaluri
      Get-WebServiceVirtualDirectory | fl name, InternalUrl
      
      Repeat this procedure on the Availability service Web site for the target forest.
    • DNS: From the Exchange 2007 Client Access server in the source forest, go to the Autodiscover Web site, and then run the following cmdlet in the target forest:
      Get-WebServicesVirtualDirectory | fl name, ExternalUrl
      
      Repeat this procedure on the Availability service Web site for the target forest.

For detailed syntax and parameter information, see the following cmdlet reference topics:

To ensure that you are reading the most up-to-date information and to find additional Exchange Server 2007 documentation, visit the Exchange Server TechCenter.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.