Remote mailbox move (a.k.a. cross-forest mailbox move) refers to the process of migrating an Exchange mailbox from one Active Directory forest to another. Exchange 2010 supports remote mailbox moves via the MoveRequest cmdlets. Here are some of the considerations for performing remote mailbox moves on mailboxes which are enabled for Unified Messaging (UM). This article assumes that readers are familiar with Unified Messaging and how remote mailbox move operates in general.

So... why do you care?

Prior to Exchange 2010 SP1, if you want to perform remote mailbox move on a UM-enabled mailbox, you need to do the following:

1. Prior to the move, UM-disable the mailbox in the source forest
2. Execute move request on the mailbox
3. After the move completes, UM-enable the mailbox in the target forest

In addition, you need to update the telephony configuration for the corresponding phone set so that all phone calls for the mailbox owner are correctly covered by the telephony system to the UM servers in the target forest.

This process poses several pain points, most importantly:

• Admin hassle - The admin having to manually disable and re-enable the mailbox for UM every time a UM-enabled mailbox is moved.
• User hassle - Voice Mail stops working for the user whose mailbox is being moved for the entire duration of the move process since the mailbox is UM-disabled. This is problematic for users with large mailboxes where the move process can take a long time to complete.

In Exchange 2010 SP1, we've extended the MoveRequest cmdlets to alleviate these pain points by removing the need for an admin to UM-disable/re-enable the mailbox and reduce voice mail downtime.

How it works

For this to work correctly, you need to "map" the UMMailboxPolicy objects in the source forest to the UMMailboxPolicy objects in the target forest. This is achieved by stamping the name of the UMMailboxPolicy object in the source forest on the SourceForestPolicyNames attribute on the UMMailboxPolicy object in the target forest. Here's an example to explain what I mean:

1. Suppose you have some mailboxes which are UM-enabled in the source forest and are associated with UMMailboxPolicy object (Policy S). You would like these mailboxes to be UM-enabled and associated with UMMailboxPolicy object (Policy T) in the target forest after the move completes.
2. Prior to executing the New-MoveRequest on these mailboxes, you need to stamp the name of Policy A on Policy B's SourceForestPolicyNames attribute by running the following Exchange cmdlet in the target forest:

   Set-UMMailboxPolicy -identity "Policy B" -SourceForestPolicyNames "Policy A"

3. Once the mapping is created, you can start moving the mailboxes by executing the New-MoveRequest cmdlet without having to UM-disable the mailbox first. While the move is in progress, UM continues to operate for these mailboxes in the source forest since the mailboxes are still UM-enabled. As the move request completes for a particular mailbox, the following happens:
   • In the target forest:
     1. Upon detecting that the mailbox is UM-enabled, the migration process obtains the name of the UMMailboxPolicy object which the mailbox is associated with in the source forest. It then looks for a corresponding UMMailboxPolicy object in the target forest whose SourceForestPolicyNames attribute contains this name.
     2. The migration process also figures out what UM extensions are currently assigned to the mailbox in the source forest. Using these extensions and the UMMailboxPolicy object found earlier, the migration then UM-enables the mailbox in the target forest.
     3. The migration process also copies over information about the user's UM PIN into the target forest, ensuring the user's existing UM PIN is preserved during migration.
     4. A UM welcome message is then sent to the user, showing the access telephone number for the UMDialPlan in the target forest. Access telephone number is what users dial on their phone to get to Outlook Voice Access.
   • In the source forest:
     1. As part of move request, the Active Directory mailbox object is updated into a Mail-Enabled User (MEU) object. All UM configuration on the MEU object is automatically removed.

Once the migration process completes, voice mail outage begins. This is because your telephony system is still sending calls to the UM servers in the source forest. Voice Mail outage continues until the telephony configuration for the corresponding phone set is updated to cover calls to the UM servers in the target forest.

Further reducing voice mail downtime

If you want to reduce the amount of downtime even further, this is what you can do:

1. Make sure the name of the UMMailboxPolicy object in the source forest is correctly stamped on the SourceForestPolicyNames attribute of the UMMailboxPolicy object in the target forest.
2. Execute New-MoveRequest with SuspendWhenReadyToComplete parameter set to $true. This ensures that the New-MoveRequest pauses right before finalization occurs.
3. As you resume the move request by running Resume-MoveRequest, you also update your PBX configuration.

As the mailbox move finalizes, the mailbox in the source forest is deleted and the mailbox in the target forest becomes functional. If you update your telephony configuration as the mailbox move finalizes, you can reduce the window of voice mail outage. Note that this method can be cumbersome since it requires precise coordination between your Exchange admin and your telephony admin.

SourceForestPolicyNames Attribute

The SourceForestPolicyNames attribute on the UMMailboxPolicy object is part of Exchange 2010 SP1 schema. It bears the following characteristics:

1. Multi-valued - This means that you can have multiple UMMailboxPolicy objects in the source forest mapped to a single UMMailboxPolicy object in the target forest.
2. Unique - No two UMMailboxPolicy objects in the same forest can have the same value stamped in their SourceForestPolicyNames attribute. This prevents you from stamping the name of a single UMMailboxPolicy object in the source forest on multiple UMMailboxPolicy objects in the target forest. This is needed to avoid any ambiguity when the migration process looks for a matching policy object in the target forest.
3. By default, when you create a new UMMailboxPolicy object using Exchange 2010 SP1 cmdlets or admin console, its SourceForestPolicyNames attribute is automatically populated with its own name. An easy way to handle remote mailbox moves is to create UMMailboxPolicy objects in both source and target forests with the same name, thereby avoiding the need to manually configure the SourceForestPolicyNames attribute.

Other considerations

1. If the mailbox is UM-enabled in the source forest but you don't want the mailbox to be UM-enabled in the target forest, you should UM-disable the mailbox prior to the move. Conversely, if the mailbox isn't UM-enabled in the source forest but you want to UM-enable the mailbox in the target forest, you should UM-enable the mailbox in the target forest after the move. Doing so helps to reduce complexity in managing the move request since you don't have to take UM configuration into account.
2. When you first execute New-MoveRequest, the migration process will perform a series of UM-specific validation up front if mailbox is UM-enabled, including looking for a matching UMMailboxPolicy object in the target forest as well as validating that the UM extensions assigned to the mailbox are unique in the target forest. If the validation fails, New-MoveRequest will return an error immediately.
3. Under rare circumstances, the UM-specific validation may succeed up front when New-MoveRequest cmdlet is executed but the migration process fails to UM-enable the mailbox as the mailbox move finalizes. When this occurs, the mailbox move will complete with warning and the mailbox will not be UM-enabled in the target forest. You will need to manually UM-enable the mailbox in the target forest. The corresponding warning message, which can be obtained through Get-MoveRequestStatistics cmdlet, looks like this:

   Warning: User 'John Doe' can't be enabled for Unified Messaging in the target forest for the following reason: Extension 12345 is already assigned to another user on dialplan DP1 or an equivalent dial plan. Please fix the problem and enable the user for Unified Messaging manually.

   An example of how this can happen is that the UM extension assigned to the mailbox was available in the target forest when the UM-specific validation occurred but is no longer so right when the move finalizes.

4. A UM-enabled mailbox may be assigned extensions from multiple UMDialPlan objects in the source forest. Only extensions from the primary UMDialPlan will be used to UM-enable the mailbox in the target forest. Extensions from secondary UMDialPlan(s) will not be preserved.

Chun Yong Chua