IORepl and Exchange 2010 SP1
Published Mar 28 2011 11:58 AM 9,399 Views

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).

Exchange 2010 RTM

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:

  • Upgrade the Exchange 2003 organization to Exchange 2007 SP2 and deploy at least one 2010 CAS server in this organization. (Exchange 2007 SP2 includes down-level proxy improvements)
  • Upgrade the 2003 organization to a pure Exchange 2010 organization.

Exchange 2010 SP1

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:

  • IOREPL needs to be run on a 32-bit Windows 2003 SP2 Server.
  • Exchange 2003 SP2 System Manager must be installed on the machine running IOREPL.
  • CAS+Mailbox Role - The IOREPL tool was created to work in an Exchange 2003 environment and there is a requirement to have a Public Folder on the same server as the end point (KB826449). In an Exchange 2010 environment, the MAPI client will connect to the CAS server. When the service account profile is configured it will access the CAS server and will look for the Public Folder on the same server. To resolve this, we need to install CAS and Mailbox roles on the same server.

    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.

    For new SP1 installs, RPC encryption is disabled by default. For servers that were upgraded from Exchange 2010 RTM, RPC encryption has to be disabled:

    Get-RpcClientAccess -Server <ServerName> | ft Server,EncryptionRequired
    Set-RpcClientAccess -Server <ServerName> -EncryptionRequired $false

  • One of the IORepl endpoints needs to be an Exchange 2003 SP2 server. Other configurations aren't supported.
    (Direct Exchange 2010 <> Exchange 2007, 2007 <> 2007 or 2010 <> 2010 replication is not supported)

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.

Migrating Permissions

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

5 Comments
Not applicable

Great post!

Couple of weeks ago I have set up the IOREPL against three Exchange organizations for a coexistence setup during a migration period to the new environment (Exchange 2003 OrgA <-> Exchange 2010 SP1 <-> Exchange 2003 OrgB).

IOREPL/InterOrg replicates only the F/B information between the Exchange 2010 and Exchange 2003 organizations and not between the Exchange 2003 orgs. An existing QCS setup replicates the F/B (and the GAL objects) between the Exchange 2003 orgs. Due to QCS upgrade considerations we had to use the IOREPL tool for the F/B replication, for the GAL exchange I have wrote a custom PowerShell script to create the GAL objects in the three Exchange orgs (including the orginal legacyExchangeDN for F/B matching).

Two CAS and two Mailbox servers exists on seperated servers and PF's exist on all mailbox servers. Corresponding GAL object are succesfully created and F/B PF's are manualy created, according to the MS description on the IOREPL tool, on all involved Exchange orgs (including the changes for the availability addressspace to point to the PF for the F/B lookup). This setup works without any errors, except a IOREPL warning for a redirection from the CAS tho the Mailbox server but this can safely ignored. The only thing what I see in the IOREPL logging is that a lot (not all) of F/B msg are ignored from the Exchange 2003 to the Exchange 2010 organization but not from the Exchange 2010 to the Exchange 2003 organization. I can't put my finger on what is causing it. Do you guys have any ideas what is causing this?

Not applicable

Good to see these updates, helping friend of mine on the same :)

Not applicable

I wish i knew this 2 weeks ago.  I just deployed an Ex2007 server in my new forest to provide support for PF replication. Doh!

Not applicable

A good way of creating the Top Level PFs in the Exchange 2010 is as follows:

1) Export all Public Folders from the Exchange 2003 organisation to PST using Outlook.  Use a subject line filter of a random text string such as '&%$^&' which will ensure that no content is exported, just the actual folders themselves

2) Connect to the IORepl's service account mailbox again using Outlook

3) Copy each Top Level PF to the All Public Folders hierarchy (not including ExchSyncSecurityFolder).  Unfortunately this has to be done one step at a time.

This gets around the issue whereby the EMC or EMS can only create folders that contain posts or mail items rather than Calendars, and as a bonus also brings across mail user permissions (assuming as above you have some form of replication and have run the preparemoverequest script along with ADMT for SidHistory).

Not applicable

here are my post about interorg in cross-forest migration. I have some doubts

social.technet.microsoft.com/.../104e4b5e-458f-401e-9b74-c40af322d9b2

Version history
Last update:
‎Jul 01 2019 03:58 PM
Updated by: