ExchangePro: How to support Schedule+ Free/Busy coexistence between Exchange 2003 and Exchange 20 (4294894)

Purpose

The purpose of this document is to educate our clients on Free/Busy coexistence. If your project requires Free/Busy coexistence between Exchange 2003 and Exchange 2010 or 2013 you will need to configure the Exchange availability service for cross-forest topology. Please read the following article for further clarification. 

Article

In the course of a migration, support for Free/Busy coexistence is a common requirement. E2E Complete supports the synchronization of Schedule+ Free/Busy as published within the public folder hierarchy from one Exchange organization to another. However, mailboxes hosted on an Exchange 2013 server will not acknowledge this data, even if the Schedule+ Free/Busy data is located on an Exchange 2010 server in the same organization.

If your project requires Free/Busy coexistence between Exchange 2003 and Exchange 2010 or 2013 you will need to configure the Exchange availability service for cross-forest topology. 

Additionally, Schedule+ Free/Busy is prone to lag, by nature. Exchange Server requires time to acknowledge updated Schedule+ Free/Busy information, once the new data has been received. It is for this reason that Binary Tree recommends the use of native processes for Free/Busy collaboration.

Binary Tree recommends that you follow Microsoft’s best practices for setting up the required infrastructure. More information may be found at this link:
http://technet.microsoft.com/en-us/library/bb125182(v=exchg.141).aspx

While this document is unable to provide specific instructions for your environment, we would like to share some general guidance which can be used to establish Free/Busy sharing between Exchange 2003 and Exchange 2010 or 2013.

To provide some background, the central challenge is as follows: Exchange 2003 does not natively support the availability service, while Exchange 2013 does not natively support Schedule+ public folder data. The resolution is to add a component which can bridge the gap between these two environments. In this case it involves adding an Exchange 2010 SP2 RU5 server (or greater) installed in the Exchange 2003 source organization. Once this has been established, the Exchange 2010 server can be used to proxy this information from Exchange 2003 to the Exchange 2010 or 2013 server in the target environment.

This general outline assumes that a 2 way trust is in place:

1.         Define DNS conditional forwarders so that servers from either side are resolvable in the opposing forest.

2.        On the source forest, create a DNS A Record for autodiscover.source.com and direct it to the source Exchange 2010 server.

3.         Verify that autodiscover.source.com resolves to a trusted certificate from every Exchange server in the target (valid SSL cert, either public or private).

4.        Establish directory coexistence with a process creating the mail-enabled user objects in a manner compliant with the Exchange availability service, such as Binary Tree DirSync.

5.         On the source Exchange 2010 server, add a local replica of the Schedule+ folder.

6.        On the source Exchange 2010 server, open the Exchange Management Shell and execute the following command:
Set-WebServicesVirtualDirectory -identity “

7.          On the source Exchange 2010 server, open the Exchange Management Shell and execute the following command:
Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User  "

8.        On the source Exchange 2010 server, open the Exchange Management Shell and execute the following command:
$a = Get-Credential             

When prompted enter credentials for Target\Administrator

Export-AutodiscoverConfig -TargetForestDomainController "

9.        On the target Exchange 2010 or 2013 server, open the Exchange Management Shell and execute the following command:
Add-AvailabilityAddressSpace -ForestName

10.    On the target forest, create a DNS A Record for autodiscover.target.com and direct it to the target Exchange 2010 or 2013 server.

11.     Verify that autodiscover.target.com resolves to a trusted certificate from every Exchange server in the source (valid SSL cert, either public or private).

12.    On the target Exchange 2010 or 2013 server, open the Exchange Management Shell and execute the following command:
Set-WebServicesVirtualDirectory -identity “

13.     On the target Exchange 2010 or 2013 server, open the Exchange Management Shell and execute the following command:
Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User  "

14.    On the target Exchange 2010 or 2013 server, open the Exchange Management Shell and execute the following command:
$a = Get-Credential

When prompted enter credentials for Source\Administrator

Export-AutodiscoverConfig -TargetForestDomainController "

15.     On the source Exchange 2010 server, open the Exchange Management Shell and execute the following command:
Add-AvailabilityAddressSpace -ForestName

At this point users from opposing forests should be able to request Free/Busy information from their Outlook or OWA clients.