We have found that many of our clients are running into snags when trying to implement this process. So to help, we thought it would be useful to outline the most common pitfalls.
Pitfalls:
1) The target address space, defined by the ILM contact objects, must match the autodiscover name space of the corresponding forest. In perspective, the “TargetAddress” starts the entire chain of events. By checking the availability of a user, Exchange will invoke the “TargetAddress”” attribute to determine where to get more information about that forest contact object. From there, the process will either use DNS or SCP to find a CAS server in the other forest. If the “TargetAddress” name space is aligned with the autodiscover name space, there should not be any naming conflicts relative to certificates involved!
2) There is a 10 second timeout in the entire availability process. Though DNS is easier from a referral point of view, exporting the forest availability (SCP) to the other forest dramatically cuts the time signature used with the process.
3) 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; meaning that 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. Because of this, there is means to set an affinity or preference for a CAS server in one particular forest. All of the CAS servers must be routable and available from a port perspective.
To Review the Microsoft Exchange blog on How to Configure the Availability Service for Cross-Forest Topologies:
For more information contact us at: info@rutter-net.com
Comments