If you would like to read the other parts in this article series please go to
- Moving Mailboxes in Exchange 2010 (Part 1)
- Moving Mailboxes in Exchange 2010 (Part 3)
- Moving Mailboxes in Exchange 2010 (Part 4)
Introduction
In part one of this three-part article series on the new move request feature of Exchange 2010, we covered what the move request feature is and revealed that the Microsoft Exchange Mailbox Replication service is used to process mailbox moves. We then proceeded to create a new local move request using the Exchange Management Console. Obviously it is also possible to use the Exchange Management Shell to create move requests and that will be the focus of this part of the article series. As you might expect, there are additional settings regarding move requests that can be controlled using the Exchange Management Shell that are not available when using the Exchange Management Console. Consequently, this part of the article series will be a little more in-depth than the previous part that covered the Exchange Management Console.
Creating a Move Request – PowerShell
To create a local move request using the Exchange Management Shell you can use the New-MoveRequest cmdlet and its associated parameters. A very simple cmdlet to create a local move request to move a mailbox from one database to another could look like this:
New-MoveRequest –Identity neil –TargetDatabase ‘Mailbox Database 004’
Here, the Identity parameter is used to identify the mailbox that is to be moved, whilst the TargetDatabase parameter obviously identifies the database that the mailbox is to be moved to. Running this cmdlet will produce an output similar to that shown in Figure 6.
Figure 6: New-MoveRequest Cmdlet
What you will notice from Figure 6 is that some of the column information is somewhat obscured by the default formatting used by the Exchange Management Shell. To fix this, you can pipe the results of the New-MoveRequest cmdlet into the format-table cmdlet (abbreviated to ft in the cmdlet example below) and also use the –AutoSize and –Wrap parameters as shown in this example cmdlet:
New-MoveRequest –Identity neil –TargetDatabase ‘Mailbox Database 004’ | ft –AutoSize -Wrap
This produces an output similar to that shown in Figure 7 which obviously makes things much easier to read.
Figure 7: Formatted New-MoveRequest Cmdlet
One thing that I want to mention here is an error that you may see at this stage. If I now try and move the same mailbox to a different database I get the following error message:
Mailbox {name} has a completed move request associated with it. Before you create a new move request for the mailbox, run the Remove-MoveRequest cmdlet to clear the completed move request.
This error is shown in Figure 8.
Figure 8: New-MoveRequest Error
As the error message states, the mailbox already has a completed move request associated with it that must be removed before any further move requests can be created. Therefore, this means that move requests must be removed once they have been completed.
Note:
Move requests are not automatically removed even if the mailbox has moved successfully. This also has implications for the removal of mailbox databases which we will look at later in this article series. We will also look at management of move requests later in this article.
There are many parameters available with the New-MoveRequest cmdlet that can be used to control the move request. As you might expect if you are familiar with Exchange 2007, there are more ways to control move requests using the Exchange Management Shell than there are using the Exchange Management Console. You can find a full list of the parameters here but for now we will cover a few of the more important parameters right here in this part of the article series:
- BadItemLimit – As you saw in Figure 5, it is possible to decide how many corrupt mailbox items you are willing to tolerate when moving a mailbox. In the Exchange Management Shell, the BadItemLimit parameter controls this setting.
- BatchName – This is a useful parameter that allows you to specify a batch name when moving a number of mailboxes. It is then possible to use this batch name to search for particular mailboxes when using the Get-MoveRequest cmdlet as you will see in part three of this article series.
- IgnoreRuleLimitErrors – If you encounter any rule limit errors when moving a mailbox, you might decide not to move the user’s rules as part of the mailbox move. This parameter allows you to do this. You could, for example, alter the parameters of a move request after it has been submitted to ensure that rules are not processed. We will cover this in part three of this article series.
- MRSServer – Ordinarily, the move request is processed by one of the Client Access Servers within the Active Directory site. To specify a particular Client Access Server, use the MRSServer parameter using the Fully Qualified Domain Name (FQDN) of the Client Access Server.
- SuspendWhenReadyToComplete – This parameter is used to suspend the move request before the mailbox is finally moved to the target database. In other words, all the actual mailbox data is moved but the final move is not completed until the administrator resumes the move request using the Resume-MoveRequest cmdlet. One application of such an approach could be to allow a final approval of a mailbox move. We will look at this parameter in part three of this article series.
Controlling Target Databases
One very interesting piece of information is that the TargetDatabase parameter of the New-MoveRequest cmdlet is actually optional. In the examples at the start of this article series you can see that this parameter has been used to ensure that the mailbox was moved to the database called Mailbox Database 004. If you exclude the TargetDatabase parameter, the move request process will automatically select a mailbox database for you.
If you have one or more mailbox databases that you wish to exclude from this selection process, then you can change the value of the IsExcludedFromProvisioning parameter of the databases that you wish to exclude. This parameter is shown in Figure 9 and as you can see it has a default value of false, meaning that the database is available for mailbox provisioning. If I wished to change the value of this parameter for Mailbox Database 004 to true, then I would run the following cmdlet:
Set-MailboxDatabase ‘Mailbox Database 004’ –IsExcludedFromProvisioning $True
Figure 9: Excluding a Mailbox Database From Mailbox Moves
Managing Move Requests
Now that the local move request has been created, you will need to track the progress. Back in the Exchange Management Console click the Move Request object found under the Recipient Configuration node in the console tree. This will present a screen similar to the one shown in Figure 10. In this figure, I have removed the action pane for clarity.
Figure 10: Managing a Move Request
Here you can see that a list of move requests is displayed. At the moment, there is only a single move request that is in progress and the Move Request Status field shows a status of Moving. By default, only the Display Name, Alias, Move Request Status and Move Request Type fields are shown in the Exchange Management Console. There are two ways of increasing the information available to you:
- In the Exchange Management Console, click the View menu followed by the Add/Remove Columns… menu option to bring up the Add/Remove Columns window as you can see in Figure 11. Here you can see that the Name, Remote Host Name, Source Database and Target Database fields are also available. Using the various buttons presented on this screen, you can choose which additional fields to display and also the order they should be displayed in.
Figure 11:
Adding Additional Information Columns
- The other way of increasing the amount of information available to you in the Exchange Management Console is to examine the properties of a move request. To do this, simply right-click a move request and choose Properties from the context menu. Doing so brings up the properties window of a move request which will look similar to the one shown in Figure 12.
Figure 12: Properties Of a Move Request
One of the more interesting fields that is presented in Figure 10 and Figure 12 is the Move Request Status field. In Figure 12 you can see that the status is Completing but of course there are many other possible status settings such as InProgress, Completed, Failed and so on. This allows you to understand where in the overall process the move request currently is.
Summary
That completes part two of this article series on moving mailboxes in Exchange 2010, where we have learnt how to create a move request using the Exchange Management Shell and then gone on to look at how you can start to manage this move request. In part three, we will complete our look at move requests by covering additional management topics as well as more configuration parameters.
If you would like to read the other parts in this article series please go to
