This post discusses the considerations for coexistence and migration of public folders from your Exchange Server 2003 environment to Exchange 2007/2010 organization.
IORepl (also known as Exchsync or Inter-Org Replication tool) is a MAPI-based application that allows for the replication of public folder data between two Exchange organizations. If you intend to replicate only Free/Busy information and you have Outlook 2007 (or later) clients, we suggest that you use Availability Service as a more reliable and scalable solution for Free/Busy.
Vandy's post on How to Configure the Availability Service for Cross-Forest Topologies has the configuration information for setting up Cross Forest Availability Service between an Exchange 2010 and an Exchange 2007 organization. Availability Service will accomplish the Free/Busy solution for Exchange 2007 and Exchange 2010 end points, which isn't supported by IORepl. IORepl needs an Exchange 2003 server as one of end points.
Note: If using Outlook 2003, users in the Exchange 2003 forest must be synchronized to the Exchange 2010 forest or contact objects must exist (in that forest).
With Exchange 2010 RTM, IORepl was not supported to replicate directly with an Exchange 2010 Public Folder store. You were able to configure the tool and get public folder data to replicate, but free/busy information would not replicate. If your organization needed to provide free/busy sharing between Exchange 2010 and Exchange 2003 organizations, you needed to have an Exchange 2007 SP2 server in the Exchange 2010 organization or use federation (an Exchange 2010 feature, see Understanding Federation for details), which has one of the following requirements:
Exchange 2010 SP1 includes support for the IORepl tool. The Tools section in the Exchange Supportability Matrix has been updated to reflect this:
It's important to emphasize that although Exchange 2010 SP1 includes support for IORepl tool, you must make sure the following requirements are met to get it working properly:
Another related configuration that might be necessary is to hardcode the CAS server used by the mailbox database. This will prevent the client from attempting to connect to another CAS server, which can result in the replication failing.
Set-MailboxDatabase <database of Exchsync 2010 MBX> -RpcClientAccessServer <CAS Server Name> Get-MailboxDatabase <database of Exchsync 2010 Mailbox> | fl PublicFolderDatabase
If enabled, disable RPC encryption requirement on the CAS server used by IOREPL.
Get-RpcClientAccess -Server <ServerName> | ft Server,EncryptionRequired Set-RpcClientAccess -Server <ServerName> -EncryptionRequired $false
Follow the existing documentation on IOREPL and follow the same steps for Exchange 2010 where Exchange 2007 is referenced. Install the tool on the Exchange 2003 server and then create two one way sessions as documented.
It's important to note that that the IORepl service account's mailbox for the Exchange 2010 organization should be on a database that is on the server where a Public Folder store exists.
The top level public folders have to be created manually on the target Exchange 2010 server.
Once the preparation, installation, configuration and testing phases are complete and you are successfully able to replicate public folders and free/busy content between Exchange organizations, the next phase is to export Public folder permissions. In order to do that, we need PFDAVAdmin to export permissions on Exchange 2003 side and ExFolders to import permissions on Exchange 2010 side.
Note: It's important to retain public folder replicas on Exchange Server 2003 until all mailboxes have been migrated to Exchange Server 2010. This is to allow for access to public folders via Exchange 2003 OWA as well as Exchange 2010 Outlook Web App. It's assumed that you have already followed the steps to move mailboxes cross forest as explained in Exchange 2010 Cross Forest Mailbox Moves.
You can use either the legacyExchangeDN or the account name (Domain\User) while exporting Public Folder permissions using PFDAVAdmin. Since the PrepareMoveRequest script will update the source object's proxyAddresses to include the target object's legacyDN as X500 address, it's straightforward to just use the legacyExchangeDN. Otherwise, you'll need to edit the domain name in the exported "Account name" file to match the Exchange 2010 domain.
Thanks to Henrik Walther for reviewing this post.
Nagesh Mahadev, Julio Vieira and Pierre Touratier