Migrating to Exchange 2013 : Inter-Org Migrations (part 1) - Public Folder Data Synchronization, Mail Flow

An inter-org migration refers to migrations between different Exchange organizations. By definition, an Exchange organization is also a single Active Directory forest, and so frequently the terms cross-forest migration and inter-org migration are used interchangeably.

Inter-org migrations are often the cause of most problems for migration teams. The primary reason for this is that the very nature of an inter-org migration involves a second Active Directory forest and a second Exchange organization. Having multiple directories and Exchange organizations often means that there will be a requirement for cross-organization collaboration; that is, users in one organization sharing information with users in another organization. This scenario brings with it complexity, and we all know that complexity is something we can usually do without.

The following items are very likely to impact an inter-org migration:

1. Outlook Client Reconfiguration

Outlook client reconfiguration is always a requirement when you migrate a mailbox. If the mailbox remains within the same Exchange organization, however, then Outlook will receive an ecWrongServer response back from the original Exchange Server, which will prompt Outlook to determine the new location of the mailbox. This process happens automatically, and the end-user experience is best described as seamless.

If the mailbox move is to a new Exchange organization, then the redirection process is more complex. There are generally two approaches to this. The first (and best) approach is to configure autodiscover to return the correct RPC client access endpoint in the new Exchange organization. The second approach is to use Outlook profile files (PRF) to force the client to update. The PRF method requires that a script or some other mechanism act on the client machine. The script detects when the user's mailbox has been migrated and then imports a preconfigured PRF file with a valid destination in the target Exchange organization. Outlook will then connect and determine its actual server connection endpoint. Even though we have reconfigured our Outlook client, we now have another potential problem: How is the client going to authenticate to the new mailbox? Our source user logon account had rights over the old mailbox, but it doesn't necessarily have rights over the new, migrated mailbox. The migration process in an inter-org migration must ensure that the account that the user is going use to log on with post-migration still has the access rights to log on to the mailbox.

2. Availability Data Sharing

Availability data sharing is somewhat taken for granted in most organizations. The ability to see whether someone is free or busy when trying to arrange a meeting, for example, is a critical service for many business users. Historically, system public folders provided this service, but since Exchange Server 2007 and Outlook 2007, availability data is provided by Exchange Web Services (EWS) instead. The Availability service (AS) will proxy availability requests between the two forests and send back the data to the calling client. This assumes, however, that the client access servers have been configured correctly in each Exchange organization and that all dependencies are in place, including certificates, network connectivity, name resolution, and Global Address List Synchronization. The bottom line is that it is possible to provide a pretty seamless cross-organization availability experience, but that solution brings additional complexity.

3. Global Address List Synchronization

The Global Address List (GAL) is a directory of all mail-enabled objects within the organization. It allows end users to pick from a directory rather than having to remember individual email addresses. The problem arises when you have multiple Exchange organizations that want to have a common shared global address list (GAL). This requires a process for synchronizing entries within the GAL across the forests while maintaining all required attributes. Microsoft's Forefront Identity Manager 2010 (FIM2010) has a GALSync component management agent (MA) that provides this functionality. However, this is another added level of complexity that requires designing, testing, and deploying prior to any migration work taking place.

The freely available GALSync MA in FIM2010 has some limitations, but most notably it will only create a mail-contact object in its default configuration. A mail-contact object type is perfectly acceptable for maintaining a common GAL across multiple Exchange organizations, but it is limited in a migration scenario due to it not being possible to log on to a mail-contact object. Typically, it is more useful to customize FIM to generate a mail-enabled user instead. Handily, the Exchange product group has provided some sample code that does exactly this, and it is available for download at the following URL:

http://technet.microsoft.com/en-us/library/ee861124(v=exchg.141).aspx

4. Public Folder Data Synchronization

Public folder data synchronization is also often a migration requirement. Organizations have used public folders for many years, and they maintain a mix of high-priority workflow data and unstructured data stored across their public folder databases. The biggest problem with inter-org migration of public folder data is that the free Inter-Organization Replication (IORepl) tool is limited in functionality and receives limited support from Microsoft. It was updated to support Exchange 2010, but there are no indications currently that it will be updated for Exchange Server 2013. It does a fairly good job of synchronizing folder data between Exchange organizations. There are issues with folder permissions, however, and many organizations have problems with performance. Also, since this tool is not currently supported in Exchange Server 2013, it will require Exchange Server 2010 with a legacy public folder database in the target forest to make it work. In addition, the other end must be Exchange Server 2003.

There are rumors that Microsoft will eventually provide a solution for legacy public folder migration directly to Exchange Server 2013; however, there are no defined timelines available nor is it clear if any solution would include Exchange Server 2003.

If this all sounds like too much complexity, then you have two options: Either move the public folder data to another service (SharePoint, for example, or Exchange 2013 site mailboxes) or look for third-party public folder migration tools. Obviously, none of these routes are very appealing, which is why most migration teams groan whenever public folders are mentioned. By far the best approach for inter-org public folder data migration is to avoid it entirely. Try to classify your public folder data as “old and unused,” “move to alternative technology,” or “stuck in public folders.” Ideally, you are looking to remove or relocate everything prior to the main migration. If you have to deal with inter-org public folder data migration, test it thoroughly in a lab beforehand and validate the deployment in a production environment before migrating any mailboxes. Also, make sure that you have a way to monitor the success of ongoing public folder data replication, because IORepl has a tendency to stop working of its own accord.

NOTE Quest has announced that v9.x of its Migration Manager product will provide support for legacy to modern public folders in Exchange 2013.

5. Mail Flow

Maintaining mail delivery during an inter-org migration is not always a simple task. The most common problem that you need to solve is that both Exchange organizations will be sharing the same primary SMTP name space, for example, exchange-d3.com. When you move a mailbox from one organization to the other, you need to ensure that mail delivery is maintained both prior, during, and after the mailbox move. To achieve this, there are several dependencies:

• All SMTP addresses must be migrated from the source to the target mailbox.
• The legacyExchangeDN attribute from the source mailbox must be added as an X500 proxy address on the target mailbox.
• Each Exchange organization must have a unique mail routing domain.

SMTP addresses on a mailbox are used for mail delivery, and thus it is vital to maintain any valid addresses on the mailbox during its migration. The legacyExchangeDN is also used for mail delivery. Adding the legacyExchangeDN attribute as an X500 proxy address post-migration helps to prevent delivery failures. For example, someone hitting Reply to an email rather than picking an address from the global address list or typing in the SMTP address manually causes Outlook to attempt to deliver the email based on its previously cached information for that user, the legacyExchangeDN. If a mailbox is migrated without the legacyExchangeDN in its X500 proxy address list and someone replies to a previously received email, then Exchange will not be able to identify the correct target mailbox for delivery, and delivery will fail. Luckily, a PowerShell script that ships with Exchange Server 2013 called Prepare-MoveRequest.ps1 handles this.