Edit: This post has been updated on 5/11/07 to change the wording around hybrid forest deployment.

Cross-org Mailbox Moves

Cross Org migrations are the ones where a mailbox needs to be moved from one Exchange Organization to another. Since there can only be one Exchange Organization per Forest, that means moving the mailbox between two different Forests.

Exchange Migration Wizard was used to perform this task in Exchange 2003. Exchange 2007 has incorporated Cross Org migrations into the server code base, so now Administrators can perform these moves by using the same task used for Intra Org migrations: Move-mailbox.

The following versions are supported for this kind of move:

Source Server:

Exchange 2000 SP3 (or later)

Exchange 2003 SP1 (or later)

Exchange 2007

Target Server:

Exchange 2003 SP1 (or later)

Exchange 2007

Exchange Permission requirements:

Logon account for the user who is running Move-Mailbox needs to be a granted the "Exchange Recipient Administrators" role for Source and Target Forests and "Exchange Servers" role for both source and target Server. Permissions for legacy Exchange Servers remain the same as they were for Exchange 2003 Migration Wizard.

Process Overview

Move-Mailbox in a Cross Org scenario can be divided in the following steps:

Open Server Connections

Connect to the source and target server - checks if credential and server version is valid

Gather Source Information

Read source User Mailbox attributes

Check if source mailbox is a system mailbox (Fail if it is)

Check if source user does not have a mailbox (Fail if it does not)

Gather Target information

Check mailbox size limit against target database limits

Check if we can match the source NT account in the target Forest (account match based on SMTP address, source objectSID and target sidHistory, and legacyExchangeDN). If match is found, this account will be email enabled.

Check if target mailbox exists (used to determine if merge is needed)

Check if source mailbox is a resource mailbox (If it is the target user must be disabled)

Update Directory Information before Move

Lock access to source mailbox

Create the target mailbox

Lock target mailbox

Move Mailbox Content

Move the mailbox content

Update Directory Information after Move

Update mailbox location attributes on source and target user accounts

Unlock target mailbox

Post-Migration Cleanup:

Remove Source mailbox / Remove AD User if cleanup parameter was used

Unlock Source mailbox if no cleanup was specified

New functionality added for Exchange 2007

Pre-Validation and New and Improved Logging

As described in my previous post, move-mailbox has added a pre-validation feature that performs a series of checks before actually trying to move the mailbox. This feature saves time by identifying errors right away instead of waiting until they happen during an actual move.

Also, Exchange 2007 Move-mailbox improves greatly on logging available for Migration Wizard (event logs). We now have more comprehensive Event logs, a XML Report and a troubleshooting log. All logs are enabled by default and are located at <Exchange Root> \Logging\MigrationLogs\.

New Options available

A variety of new options are available to Administrators when moving mailboxes across Exchange Organizations. Here are a few examples that demonstrate their syntax:

Credentials example: Before going into move-mailbox examples, it is worth mentioning how the credentials variables are populated for the moves. Here is an example to add a credential to a variable called $s. After typing the command, a user and password dialog will pop up. You should enter the credential that will be used for the move, using the domain/user format for the user name:

$s = get-credential

Example 1: The following command moves mailboxes in clone mode (specified by the NTAccountOU parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). Eight mailboxes will be moved simultaneous threads (-MaxThreads 8) and at the end the source NT account will be deleted (-SourceMailboxCleanupOptions DeleteSourceNTAccount).It also uses the -ReportFile parameter to specify the directory and file name for the migration XML report:

Example 2: The following command moves mailboxes in clone mode (specified by the NTAccountOU parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). By using the PreserveMailboxSizeLimit option the command preserves the existent mailbox limits after moving them to the target database. It also uses the IgnorePolicyMatch option which will move the mailbox without trying to match Managed Folder, Unified message and ActiveSync policies and therefore losing these settings (move-mailbox by default will try to match source mailbox's existent policies to same named policies at the target Organization and fail the move if no match is found). Finally, the command deletes the source mailbox after the move is complete (by using -SourceMailboxCleanupOptions DeleteSourceMailbox) :

Example 3: This command moves mailboxes in merge mode (specified by the AllowMerge parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). We only want to merge content that matches the specified date interval (-StartDate and -EndDate) and that has the work "Exchange" as part of the message subject (-SubjectKeywords). We also increased the Interval and Timeout settings for lookup operations (-RetryInterval and -RetryTimeout). No cleanup option is used because this is a merge move:

The following options present in Migration wizard are no longer supported:

Creating new enabled user accounts: This option was removed because we found that most customers were already using ADMT to migrate their user accounts instead of creating a new account during migration and adding detailed information later. Move-mailbox is still able to create mailbox enabled disabled user accounts (used in the Resource Forest configuration).

Graphic interface: Currently the only way to perform a Cross Org migration is by using the move-mailbox task from an Exchange Management Shell. An EMC wizard is planned for later versions.

Support for Exchange 5.5 servers: Exchange 5.5 mailboxes need to be migrated to Exchange 2000/2003 first and then to Exchange 2007.

Move Mailbox Cross Org and Active Directory Forests

Most of the Move Mailbox Cross Org scenarios are closely related to the Active Directory Forests involved in the migration. Before looking at the customer scenarios and at their respective move-mailbox syntax, let's go over the definition of the different Forests types and all the supported combinations among them.

Active Directory Forests Configurations

There are basically four types of Forests related to Cross Org migrations:

Single Exchange Forest: A single forest that has Exchange installed and it is not connected to any other Active Directory forest.

User Forest: Forest that contains only User Accounts. An Exchange server is not installed in this forest. It can be connected to other Active Directory Forests but it does not require any synchronization.

Exchange Forest: Forest that contains mailboxes and user accounts (enabled or disabled) and contacts. This type of configuration is actually divided in two distinct types: In a Single Forest and Cross Forest set up, user accounts are always enabled and mailbox enabled. In Resource Forest, the mailboxes are attached to disabled user accounts in one Forest and associated to user accounts in the user forest.

Hybrid Forest: This is a Forest configuration that are each a mix of User and Exchange Forests. That is, each may contain a combination of enabled and disabled User Accounts that are either mail enabled or mailbox enabled. This configuration is different than a Resource Forest because both Forests have mailboxes, and is also different than a classic Cross Org configuration because you might find mail enabled users and disabled mailbox enabled users in the same Forest.

If we represent these types as blocks, we would have the following combinations:

Even though Move-Mailbox supports migrating content among all the four Forest types described above, By default, GALSync in MIIS does not synchronize recipients in both forests in a hybrid forest scenario. However, you can create a customized MIIS solution so that GALSync will synchronize recipients in both forests.

Customer scenarios for Cross Org mailbox move

These are the supported customer scenarios for Cross Org migrations:

Company Divestiture (Single Forest to Cross Forest)

This is a scenario where a company decides move some part of its business like a division, to separate forest, be it because the division will become an independent company or because it has different technical requirements. In this situation, the Administrator should use ADMT to move user's accounts from the source Forest to the target Forest and then use move-mailbox to move that same user's mailbox.

Company Merger/Acquisition (Cross Forest to Single Forest)

This is the scenario where a company decides to consolidate mailboxes from various Forests into a single Forest. Administrators should first migrate users using ADMT and then use move-mailbox to move that same user's mailbox.

By separating the User Account Forest from the Mailbox Forest, Exchange and Windows administrators can be completely separated. In this scenario mailboxes should be migrated by move-mailbox, leaving the enabled user account on the source Forest. Therefore the cleanup option used should be delete source mailbox.

Host External Company (Single Forest to Resource Forest)

Another scenario for migrating from a Single Forest to a Resource Forest is that of a company that outsources email management but retains User Account management. Technical requirements should be similar to the previous scenario.

Bring Email Management in House (Resource to Single Forest)

This is the opposite of the last two scenarios. If for some reason a company that had its mailboxes in a separate Forest decides to bring them to the User Forest, the easier solution would be to migrate all the external mailboxes back into the Login Account Forest. In this case however, the cleanup option should be to delete user account since the linked disabled user on the Resource Forest will not be needed anymore.

Upgrade Exchange Server

This is the case where an Exchange 2007 server is installed (in any Forest configuration) and mailboxes from a legacy server (Exchange 2000/2003) are moved to this server. Since this applies to any of the scenarios above, the cleanup option used should follow the requirements described earlier depending on the Forest configuration.

Re-Alignment due to organizational or physical location changes

This is the case where mailboxes are moved among Exchange 2007 servers inside a company due to some logical or physical change. Like the previous scenario, this applies to any of the Forest configurations described above and therefore the cleanup option used should follow the requirements described earlier accordingly.

An additional question. Are there any version requirements of the DCs? I tried to move a source mailbox from a Exchange 2000 SP3 which talks to a Windows 2000 SP4 DC.
The Error message:
Domain Controller 'lima.contoso.com' Operating System version is 5.0 (2195) Service Pack 4. The minimum version required is 5.2 (3790) Service Pack 1.

And what about a model that need splits accounts and mailboxes, but preserve mailboxes in a current 'source Forest' (MbxF) and will use news accounts that bellong to another Forest (AcctF)?
There is no 'move mailbox' in this cenario.

I think to make a one-way trust-relationship (Acctf is trusted by MbxF) and assing rights, trought MbxF ExchangeSystemManager, directly to
AccF accounts), and after that, delete MbxF current accounts.

I am not sure I understand your scenario, but it looks like you are descriing a Resource Forest, that is, mailboxes in one Forest and User accounts in another.

If you just want to move out of a Single Forest to a Resource Forest and want to keep your mailboxes in the source Forest, all you need to do is to use ADMT to migrate the User accounts. You are right in the sense that this scenario does not require move mailbox, but we do have tools available (ADMT) and you don't need to assign rights manually. You do need to set up the one way trust like you mentioned.

Yes, I do need to keep my mailboxes on the MbxF Forest, and use the accounts of AcctF; and finally 'discard' MBxF accounts.

But, all the accounts of the AccfT already exists! (these two forest was born separated years ago).

Now, to 'joing' these objects, I thing that trust-relationship is the only way.
If so, the ExchangeSystemManager will work with mailboxes (and Exchange Servers) of the MbxF Forest; and accounts of the AccTF forest.
My concern is: Will this scneário works at all?

If I go from a Resource Forest config (E2k3) to single forest and it will take me several days/weeks to complete the migration, are there any recommendations or issues that might arise for migrating users? For example, do we lose delegates, mailbox rules, calendar permissions, free busy, etc?
Thanks!
-doug

I think I understand now. First, you need to somehow match the mailbox to the user accounts (move-mailbox account match is based on SMTP address, source objectSID and target sidHistory, and legacyExchangeDN). If you want to use the move-mailbox option to delete the source account (the one that is currently associated with the mailbox) you need to disable it first.

The recommended way to go from Resource Forest to a Single is to migrate the user accounts (using ADMT or similar tool) to the mailbox Forest. This way you don't need to worry about Exchange sync. You should not lose any functionality.

I've successfully moved mailboxes to a different forest. Somehow whenever a migrated mailbox sends SMTP mail to an external recipient, the reply address shows up as <IMCEAEX-_O=_OU=_CN=RECIPIENTS_CN=JSMITH@DOMAIN.COM>.

The LegacyExchangeDN attribute for these mailboxes is /o=/ou=/cn=Recipients/cn=jsmith

Any idea on what's going on and how I can resolve it? I've been searching for hours on everything I can think of to fix it and nothing seems to make any difference.

Additional Question:
If two Domains in seperate forests are linked together with external trusts (NOT a Forest Trust), is move-mailbox between the two Exchange Orgs still working?
Details: The source Forest consists of one single domain with exchange 2000 and W2k DC's in native 2000 mode. The destination forest consists of a empty root domain and a single subdomain, in which all new Exchange 2007 servers are located. All Domains and the forest itself are in W2003 Mode.
The external trusts are built in both directions between the domain in the source forest and the subomain in the new destination forest.

Additional Question:
If two Domains in seperate forests are linked together with external trusts (NOT a Forest Trust), is move-mailbox between the two Exchange Orgs still working?
Details: The source Forest consists of one single domain with exchange 2000 and W2k DC's in native 2000 mode. The destination forest consists of a empty root domain and a single subdomain, in which all new Exchange 2007 servers are located. All Domains and the forest itself are in W2003 Mode.
The external trusts are built in both directions between the domain in the source forest and the subomain in the new destination forest.

Can someone tell me where this tool is? I have a W2K3 domain with exchange and looking to migrate mailboxes over into a new domain name and exchange. I tried to use the target 07 exchange mailbox move but can't see the trusted source exchange. Any help is greatly appreciated.