.png){kind=spacer}
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: 2011-07-25
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.
 Note: |
|---|
| 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.
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.
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:
-
Microsoft Identity Integration Server 2003 ScenariosMicrosoft Identity Integration Server 2003 Scenarios
-
Microsoft Identity Integration Server 2003Microsoft Identity Integration Server 2003
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.
| Note: |
|---|
| 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:
-
Troubleshooting Free/Busy Information for Outlook 2007
-
What does Exchange 2007 Availability Service do? What does Exchange 2007 Availability Service do?
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:
-
Exchange 2007 Autodiscover Service White Paper
-
Configuration tips and common troubleshooting steps for multiple forest deployment of Autodiscover service
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:
-
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"
-
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"
-
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
Note: 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."
Note: Autodiscover will return the Availability InternalURL to the Exchange 2007 Client Access server.
-
In a trust relationship scenario, export the SCP from the target forest to the source forest by using the following cmdlet:
-
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:
-
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
-
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.
-
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:
-
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:
Repeat this procedure on the Availability service Web site for the target forest.Get-ClientAccessServer | fl name, AutoDiscoverServiceInternaluri Get-WebServiceVirtualDirectory | fl name, InternalUrl
-
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:
Repeat this procedure on the Availability service Web site for the target forest.Get-WebServicesVirtualDirectory | fl name, ExternalUrl
-
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:
For detailed syntax and parameter information, see the following cmdlet reference topics:
usually happens when the Cross Forest Trust has not been given proper Extended
Rights for ms-exch-epi-token-serialization" or “exchange Web Services
Impersonation”
Run the following cmdlet from both Forests to gather the
Extended Rights:
Get-clientAccessServer <destination-target-cas> |Get-ADPermission -User "Exchange Servers" | where {$_.AccessRights -eq "ExtendedRight" } | fl User,Deny,IsInherited,ExtendedRights >C:\ExtendedRights.txt
The results will have one or both of the Extended Rights missing for the target forest for the serialization or Impersonation.
Or the CAS server is not part of the Exchange Servers groups in AD, so verify if the CAS servers in question are included.
User : TargetForest\Exchange
Servers
Deny : False
IsInherited : False
ExtendedRights :
Run again in both Forests for the target forest. From Forest A run both cmdlets for Forest
B. Then from Forest B run both cmdlets
for Forest A.
Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "TargetForest\Exchange Servers"
Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRIght –ExtendedRights “ms-Exch-EPI-May-Impersonate” –User “TargetForest\Exchange Servers”
Application
Source:
MSExchange Availability
Date:
5/12/2011 4:37:58 PM
Event ID: 4002
Task Category: Availability Service
Level: Error
Keywords: Classic
User: N/A
Computer: xxxx
Description:
Proxy request CrossForest from <no context set> to
https://CAS FQDN/EWS/Exchange.asmx failed. Caller SIDs:. The exception returned
is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException:
System.Web.Services.Protocols.SoapException:
Microsoft.Exchange.InfoWorker.Common.Availability.ProxyRequestNotAllowedException:
Authenticated user does not have sufficient privileges to issue this request.
---> Authenticated user does not have sufficient privileges to issue this
request.
Application
Source:
MSExchange Availability
Date:
5/12/2011 11:41:58 AM
Event ID: 4001
Task Category: Availability Service
Level: Error
Keywords: Classic
User: N/A
Computer: xxxx
Description:
Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestWithAutoDiscover
failed. Exception returned is
Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException:
A cross-forest Availability service that can fill request for mailbox <user>SMTP:user@company.com
could not be found.. This event may occur when Availability Service cannot
discover an Availability Service in the remote forest.
If issue still persists manually add the Extended Rights permissions to each CAS in the Target Forest using ADSIEDIT.
Effective permissions for the CAS can also be verified through ADSIedit.
Go to the configuration container, Services, Microsoft
Exchange, Organization , Administrative Groups, Exchange Administrative Group, Servers, SourceForestCAS
-Properties, Security Tab, Advanced button, Effective Permissions tab
-Select... button, object types button, check computers, ok,
enter TargetForestCAS
Scrolling down the list about one quarter the way, you should
find the "Exchange Web Services Impersonation" and "Exchange Web
Services Token Serialization" rights
From Adsiedit expand/navigate down the following containers
+ Configuration Container>Services>Microsoft Exchange>Organization>Administrative Groups>Exchange Administrative Groups>Servers
Select SourceForestCAS properties>select the Security Tab>click the Advanced button>Effective Permissions tab
Select Object Types button>Check Computers &
OK>Enter the CAS server of the TARGET forest to add the TARGET CAS with Extended Rights, Scroll down Effective
Permissions and check "exchange Web Services Impersonation" &
Exchange Web Services Token Serialization" rights. Ok out of Adsiedit.
Complete this on each CAS server in Source Forest adding
each Target CAS server to Effective Permissions.
Close Adsiedt
- 5/18/2011
- Sanlaf
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. A software update is currently under development for this issue and is scheduled to be released in an upcoming Cumulative Rollup for Outlook 2007.
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. Apply KB 973404 for Outlook 2007 to resolve this.
- 5/11/2011
- Sanlaf
