Partager via

Performing Local Moves using MigrationBatch in Exchange 2013

  • Article

History of Local Moves

Migrating/Transitioning from an Exchange version to another consists of moving of mailboxes. Moving Mailboxes has always been a significant step as we are dealing with sensitive and confidential information of company users. Performing local moves for bulk users in Exchange 2007 and Exchange 2010 required get-content cmdlet which will have –path as the parameter defining the .txt file location. This has to be piped further using Move-mailbox in Exchange 2007 and New-MoveRequest in Exchange 2010. One other option in Exchange 2010 is the MoveMailbox.ps1 script installed at C:\Program Files\Microsoft\Exchange Server\V14\Scripts.

  • Performing move for bulk mailboxes in Exchange 2007 can be achieved using below cmdlet:

    Get-Content userlist.txt | Get-Mailbox | Move-Mailbox -TargetDatabase ‘Exch2007\First Storage Group\Mailbox Database’

  • Performing move for bulk mailboxes in Exchange 2010 can be achieved using below cmdlets:

    Get-Content -Path C:\MoveMailbox\batch1.txt | New-MoveRequest -TargetDatabase "Mailbox Database"
    OR
    .\MoveMailbox.ps1 -MailboxDatabase DB1 -TargetDatabase "Mailbox Database"

MigrationBatch Concept in Exchange 2013

Exchange 2013 introduces a new concept called MigrationBatch. Exchange 2013 also carries forward the New-MoveRequest cmdlet as in Exchange 2010. However, New-MigrationBatch provides advanced architectural improvements. It still relies on Mailbox Replication service (MRS) with enhanced management capability. If you are in co-existence mode with Exchange 2013, moving mailboxes using MigrationBatch requires Exchange 2007 SP3/Exchange 2010 SP3.

New-MoveRequest cmdlet is also available in Exchange 2013, however it does not provide enhanced capabilities as mentioned below.

* Large Batch move mailbox capability.
* Generating Move report Notification emails after the move.
* Manual move request finalization
* Facilitate Automatic retry of the moves
* Incremental syncs to update migration changes occur periodically.

Migration Mailbox in Exchange 2013

When the first Exchange Server 2013 is installed in the organization, an Arbitration mailbox called Migration mailbox (Guid) is created.

We use the Get-Mailbox -Arbitration cmdlet to identify the Migration mailbox. (Migration.8f3e7716-2011-43e4-96b1-aba62d229136)

This mailbox is located in Users container in Active Directory Users & Computers. This mailbox is used for mailbox migration activities in Exchange 2013.

For move mailboxes by using MigrationBatch cmdlet, the Migration mailbox must be available and enabled.

MigrationBatch Procedure

This can be accomplished using two ways:

  • Exchange Admin Center (GUI mode)
  • Exchange Management Shell (command line mode)

Before we begin, you need to create a csv file that contains a single column with the email address for the mailboxes that will be moved.

The header for this column must be named EmailAddress. Save it in .csv format.

Using Exchange Admin Center (GUI mode)
On the Exchange 2013 server, login to Exchange Admin Center. Click on Recipients in the left pane.

Click on Migration and click in the drop-down for + symbol. Select 'Move to a different database' option.


 

Select the .csv file which we have created for moving bulk mailboxes.

Specify a Title to the Migration Batch, select the necessary Archive options and a Target Database.

It is mandatory to select a user who will receive a report of the move after the batch completes. (In most cases, it’s the Administrator)

Further, we get an option for Autostart/manual start of a migration batch.

Likewise, Autocomplete/Manual completion of the batch.

Once the move has begun, the Syncing status can be seen for the Migration Batch process.

The Sync status changes from 'Syncing' to 'Synced'.

Once the Sync status shows as 'Synced', it waits for the Administrator's input to select the 'Complete the migration Batch' in the right pane.

Click 'Complete the migration Batch' in the right pane.

This will change the status to 'Completing' and eventually complete the Migration Batch request.

 

Once the batch move shows as ‘Completed’, the administrator receives an email notification as below:

This concludes the Migration Batch procedure using Exchange Admin Center.

Using Exchange Management Shell (command line mode)

Following sequence of steps should be executed to achieve this:

Step 1: New-MigrationBatch

Using Exchange PowerShell, run the below command:

New-MigrationBatch -Local -Name MigrationBatch1 -CSVData ([System.IO.File]::ReadAllBytes("E:\Migration\MigrationBatch1.csv")) -TargetDatabases TestDatabase1

This cmdlet only creates new migration request for a batch of users.

Step 2: Start-MigrationBatch
For commencing the actual move, we need to use the Start-MigrationBatch command. The Start-MigrationBatch cmdlet starts a pending migration batch that was created in Step 1.

Start-MigrationBatch -Identity MigrationBatch1

If you have created multiple batches, run the below cmdlet to start all of them in one go:

Get-Migrationbatch | Start-MigrationBatch

Step 3: Monitoring the Batch moves

The move status can be monitored using the below cmdlet. This is useful for monitoring the current status of migration for individual Mailboxes.

Get-MigrationBatch -Identity MigrationBatch1 | fl

In cases of multiple batches, we can run the below cmdlet. The output will show Batch name, status, Items synced and Items skipped.

Get-MigrationUser | Get-MigrationUserStatistics

The migration batch will halt at the 'Completing' stage. Screenshot below:

Step 4: Complete-MigrationBatch

The administrator has to execute the Complete-MigrationBatch cmdlet to finalize a migration batch.

When you finalize a migration batch, the cmdlet does the following for each mailbox in the migration batch:

  • Runs a final incremental synchronization.
  • Configures the user's Microsoft Outlook profile to point to the new target domain.
  • Converts the source mailbox to a mail-enabled user in the source domain.

Further, you can use the –NotificationEmails parameter so that status reports are sent to after the migration batch is completed.

Complete-MigrationBatch -Identity MigrationBatch1 –NotificationEmails administrator@unni.com

Step 5: Remove-MigrationBatch

We use the Remove-MigrationBatch cmdlet to delete a migration batch that either isn't running or has been completed.

Remove-MigrationBatch MigrationBatch1

In case of corrupted Migration batch, we have to use the –Force parameter.

Remove-MigrationBatch1 -Identity LocalMove1 –Force

Note: If you use the Force parameter with this cmdlet, the individual user requests and subscriptions that were part of the removed migration batch aren't removed. You have to remove the individual migration user requests with the Remove-MigrationUser <Identity> -Force command.
This concludes the MigrationBatch using Exchange Management Shell .

Collating in a single cmdlet:
For simplifying and avoiding the overhead of performing multiple steps as mentioned above, we can use the –AutoStart, –AutoComplete and -NotificationEmails together.

This way we can achieve the Migration Batch moves using a single cmdlet.

  • -Autostart parameter starts the Migration Batch automatically once the New-MigrationBatch is created.
  • -Autocomplete parameter completes the Migration Batch without any admin intervention.
  • -NotificationEmails parameter will fire status email once the Migration Batch is complete.

Hence, the consolidated cmdlet will be:

New-MigrationBatch -Local -Name MigrationBatch1 -CSVData ([System.IO.File]::ReadAllBytes("E:\Migration\MigrationBatch1.csv")) -TargetDatabases TestDatabase1 –AutoStart –AutoComplete –NotificationEmails administrator@unni.com

Other optional parameters:

Stop-MigrationBatchThis cmdlet stops the migration batch that's being processed. The migration of mailboxes that are being actively migrated is stopped immediately . This cmdlet has following conditions:

  •  Migration batches that are still in the process of being migrated (Sync status)
  •  Migration batches that are waiting to be migrated can be stopped. (Queued status)
  •  Migration batches that have either Failed or Completed, this cmdlet won’t run.
  •  This won't affect mailboxes that have been migrated already

Set-MigrationBatchThis cmdlet is used to configure your existing migration batches to migrate mailboxes and mailbox data during the local move.

You can use following parameters along with the Set-MigrationBatch cmdlet:

  • AutoRetryCount : The AutoRetryCount parameter specifies the number of attempts to restart the migration batch to migrate mailboxes that encountered errors.
  • AllowIncrementalSyncs: New messages sent to the source mailbox are copied to the corresponding target mailbox. The synchronization is incremental during which the source and target mailboxes are synchronized every 24 hours.

Set-MigrationBatch -Identity MigrationBatch1 -AutoRetryCount 5 -AllowIncrementalSyncs $true

Hopefully, you find this post useful!

Comments

  • Anonymous
    January 01, 2003
    Thank you for the work you put in here, Darshan.
  • Anonymous
    May 22, 2014
    Thanks
  • Anonymous
    June 12, 2014
    nice blog Darshan :))
  • Anonymous
    January 14, 2015
    Can New-MigrationBatch be used on an on-prem Exchange 2010 server? Or does the on-prem server also need to be Exchange 2013?
  • Anonymous
    February 25, 2015
    When a mailbox is moved between sites in a multi-site Exchange organization, for best performance should the 8f3e7716-2011-43e4-96b1-aba62d229136 mailbox be placed where the source mailbox is located or the destination mailbox?
  • Anonymous
    March 20, 2015
    It can be on any target database.
  • Anonymous
    July 29, 2015
    Very nice article. Thank you Darshan.
  • Anonymous
    August 31, 2015
    can I remove a migration batch which is in syncing status? I did a migration batch but it's still in syncing status for two days now and need to remove and re-run..