Posted by: seanv | November 19, 2009

Scheduling Mailbox Moves in Exchange 2010

Over the past few days, I have answered some questions on the Exchange 2010 forums in regards to scheduling mailbox moves.   In Exchange 2007 and below, users would be affected by mailbox moves (which are required for migrations, fixing an issue with a mailbox or database, etc.), so we would be forced to either interrupt the end-user or schedule these moves in off-peak hours.  Once we are in Exchange 2010, we can now perform online moves which allows the user to continue to work throughout the move; follow the link for an excellent deep dive guide on online moves written by Amit Tank.

Many organizations tend to skip a generation when it comes to upgrading technologies, therefore a lot of Administrators are now looking at moving from Exchange 2003 to Exchange 2010.   They are now realizing that while it is great that Exchange 2010 supports online mailbox moves, they still have to get there the old-fashioned way with an offline move.  Now here is where the dilemma comes in.  The interface for Exchange 2007 and below allowed for us to delay the start of the moves to a specific time, but the new-moverequest feature used for mailbox moves in Exchange 2010 has no ability to schedule the start of the moves.  Understandably, migrations from Exchange 2007 SP2 supports online moves to Exchange 2010, but how about the bulk of Exchange deployments which are Exchange 2003?  Read on as I have a solution for you.

The full execution of a mailbox move in Exchange 2010 involves three steps:

  1. Creating the move request.
  2. Checking that the execution of the move request completed successfully.
  3. Clearing the move request.

This can all be accomplished with a pre-built powershell script that is included with the installation of Exchange 2010 called MoveMailbox.ps1.  This script supports the ability to move a single mailbox or a group of mailboxes, but will only work for local move requests, therefore you cannot use this solution for cross-forest mailbox moves.  The script itself does not support the ability to schedule the mailbox moves, but it does simplify the move so that the entire move is performed in one automated command.  Once we have formulated our MoveMailbox.ps1 command, we can plug this into a batch script that can of course be scheduled by Windows Task Scheduler.

Lets say we have an Exchange 2003 server called Server1 with a Storage Group called SG1 that contains a database called DB1.  Now, assuming we have a default installation of Exchange 2010 that has a database called DB2, then the following executed in an Exchange Management Shell would move all mailboxes from the source database to the target database:

C:\Program Files\Microsoft\Exchange Server\V14\MoveMailbox.ps1 -MailboxDatabase Server1\SG1\DB1 -TargetDatabase DB2

Taking this command and appending it to a Remote Exchange powershell execution would be accomplished as follows:

 PowerShell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; ‘C:\Program Files\Microsoft\Exchange Server\V14\Scripts\MoveMailbox.ps1 -MailboxDatabase Server1\SG1\DB1 -TargetDatabase DB2’

We can then place the above within a batch script and schedule it with Windows Task Scheduler, thus allowing us to schedule our mailbox moves.  Keep in mind that the mailbox moves will follow the settings contained within the following file C:\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config which would default the maximum simultaneous moves to five mailboxes at a time.

Your friendly neighbourhood Exchange Admin.

Advertisements

Responses

  1. Wow enjoyed reading your blogpost. I added your rss to my google reader.

    • Thanks for the add and I appreciate the feedback 🙂

  2. Great information.

  3. Nice blog. One thing we have picked up with our Exch 2003 to Exch 2010 migration.
    Although mbx moves are now online, the update of the user’s mail profile on hios computer can take up to 30 minutes due to AD replication etc. – so the move itself is fast and tidy, but the end user sits without service for 30 min or more sometimes. That is why we move mailboxes after hours. And now this script comes in handy.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: