Lately, on both Simple-Talk and its companion SysAdmin-Talk, There have been a lot of articles which describe the several processes and pitfalls of moving mailboxes around. To make sure we can keep track of what’s happening when we try and use the knowledge we’ve so scrupulously gleaned, let’s have a look how you can monitor the mailbox moves during a move, and also after a move has been completed. You might find this last option interesting if you want to move the mailbox again, and you need to know how long it took for the mailbox to be migrated. In terms of the practicalities, there are several ways to monitor the mailbox moves:

• Using the Exchange Management Shell (EMC)
• Using the Exchange Management Console (EMS)
• Using the performance monitor

We’ll go through each of these in order, and cover what you need to know to use whichever method you prefer as effectively as possible. At the end of this article, I’ve provided a table which compares all methods, so you can decide which will work best for you.

Exchange Management Shell

To explode the number of options available to us even more, when using the EMS, we actually have several cmdlet options to monitor the move requests:

• Get-MoveRequest
• Get-MoveRequestStatistics
• Get-MailboxStatistics

Get-MoveRequest

Let’s start with the first one, Get-MoveRequest; by itself, this PowerShell cmdlet will only give you a brief overview of the move requests which are currently active or queued. Without using the |fl command in the pipeline, it will only display:

• displayname
• status
• targetdatabase

Which may , in some cases, be enough, particularly if you only want an overview of the move-requests currently active or queued, and you’re not interested in more detailed information. The returned displayname and targetdatabase fields don’t really need any further explanation, but what about the status field? This field will give the current status of a mailbox move, and will report one of the following status values:

• AutoSuspended – the move request is currently suspended; it can only get this status if you’ve used the SuspendWhenReadyToComplete parameter when submitting the move request. The SuspendWhenReadyToComplete parameter will allow the mailbox move to start, but the move will be suspended when it reaches the CompletionInProgress status, which we’ll come to in a moment.
• Completed – the move request has been completed.
• CompletedWithWarning – the move request has been completed with at least one warning, which can happen due to several reasons; For example, if the old mailbox could not be cleaned up
• CompletionInProgress – the move request process is performing the last sync with the old mailbox before the new mailbox is marked as active.
• Failed – the move request has failed, which can happen due to several reasons; for example, the permissions set on specific folders might be corrupted, or the maximum number of bad items is reached.
• InProgress – the Microsoft Exchange Mailbox Replication service (MRS) is currently moving the mailbox.
• Queued – the move request is currently waiting to be picked up by the Microsoft Exchange Mailbox Replication service (MRS).
• ReadyToComplete – the move request has been suspended, and is now waiting for a manual action from the administrator before it can be completed.
• Suspended – the move request is currently suspended, which can be the result of using the suspend parameter when submitting the move request. When using the suspend parameter, the move will still be submitted, but the actual move will not start until the Resume-MoveRequest cmdlet is performed.

Of course, the information displayed by the Get-MoveRequest cmdlet by itself may not be sufficient for some cases. For example, if you would like to know what kind of move is being performed, or if the mailbox is available during a move, you’re going to need more information. In these kinds of situations, you’ll need to add |fl to the cmdlet, which will make some additional information available:

As you can see in the screenshot above, there are a few fields which might be very useful when monitoring the move process:

• Flags – this reports which options are being used for the move, such as CrossOrg, Pull, Offline, or RemoteLegacy. This information will tell you if a mailbox is being moved from another forest which runs, for example, Exchange 2003, and that the mailbox is not available during the move.
• MoveType – this field reports the type of move which is being performed, and is more generic than the Flags field. For example, CrossOrg (from another forest), or IntraOrg (from another Exchange server in the same forest)
• Direction – the possible values of this field are pull or pushed; pull can be seen when performing a migration from another Exchange server, whereas pushed can be seen when moving a mailbox to another Exchange server. So if, for example, we start a mailbox move on an Exchange 2010 server which will migrate a mailbox from an Exchange 2003 server, this is a pull migration. If, on the other hand, a mailbox move is started on an Exchange 2010 server which will move the mailbox to another Exchange 2010 server, this will be a pushed migration.
• IsOffline – This tells us whether the mailbox is available during a move. If the value is true, then the mailbox will not be available, and if of the value is false then the mailbox will be available.

As you see, the additional output will provide some extra information, but won’t provide a detailed status overview of how long each step took or answer questions like “how many megabytes are transferred?“, “what was the time needed to perform the move?“, “what is the current bytes-transferred-per-minute?“, and, in case of CompletedWithWarning, “what is the problem that occurred?“.

Get-MailboxRequestStatistics

If you would like to see this kind of fine-grained information, then you’ll need to use the Get-MoveRequestStatistics cmdlet which, as the its name implies, will give you detailed information about the move. Without using the |fl pipeline, this cmdlet will display:

• Displayname
• Status
• TotalMailboxSize
• TotalArchiveSize
• PercentComplete

This information will give you a good overview of the current status of a move, and since the identity parameter is required for this cmdlet, it will also display the details of only one move request. To get an overview of all the move-requests currently active or queued, you can pipe the output from the Get-MoveRequest cmdlet as input for Get-MoveRequestStatistics:

This will give an overview similar to what you can see below:

Fig. 2 Piping the Get-MoveRequest cmdlet into Get-MoveRequestStatistics

In addition, just like the Get-MoveRequestcmdlet, the Get-MoveRequestStatistics cmdlet will give a lot more information when used in conjunction with the |flcommand. Of course, compared to using |flwith Get-MoveRequest, the Get-MoveRequestStatisticscmdlet by itself will already provide plenty of information which is very useful when troubleshooting move requests. Nevertheless, below is a screenshot of the output of the Get-MoveRequestStatistics cmdlet with the |fl command:

Fig 3. Using Get-MoveRequestStatistics with the |fl command.

Bear in mind that this will not necessarily be very useful when done in combination with the pipelined GetMoveRequest|Get-MoveRequestStatisticscmdlets, as this will potentially generate a huge and unreadable overview.

But what if you want to use the Get-MoveRequest|Get-MoveRequestStatistics command, but would like to display information which is only available when using the |fl parameter? Well, in that case, you can use the Select parameter, which will give you the option to just select a subset of the complete overview. For example, if we want to get an overview of the move requests which will display the following information:

• Only move requests which are currently active and have the status InProgress will be shown,
• The Displayname of the mailbox should be displayed,
• The percentage completed should be displayed,
• The size of the mailboxes should be displayed,
• The current MB/s should be displayed.

Let’s start with the first part, generating an overview of move requests which are currently InProgress:

Now that we know which moves are currently active, we need to gather some extra details about the move. As mentioned earlier, we will need to pipeline the results into the Get-MoveRequestStatisticscommand to gather the additional information. To get the displayname, percentage completed, size of the mailbox and the bytes transferred per minute, we will need to use the fieldnames available from the Get-MoveRequestStatistics cmdlet. So in this case, DisplayName, PercentComplete, TotalMailboxSize and BytesTransferedPerminute:

When combining these two cmdlets, you will get the command like this:

…which will give the following result:

Fig 4. Specifying exactly what information you want to retrieve from the pipelined Get-MoveRequest and Get-MoveRequestStatistics cmdlets.

As you may already know, you will need to clean up the move request manually by running the Remove-MoveRequest cmdlet. Once you’ve performed that cleanup, you won’t be able to use the Get-MoveRequest and Get-MoveRequestStatistics cmdlets anymore. However, it’s still possible to view the move request history by using the Get-Mailbox cmdlet together with the IncludeMoveHistory parameter. Alternatively, if the request hasn’t been removed yet, you can use the IncludeMoveReportparameter to find out plenty of useful details. The difference between the parameters, besides the fact that IncludeMoveReport is not available once the move request has been cleared, is the information which will be provided to you:

Specifically, the difference between the two parameters is the amount of information you will receive. If you just want to know certain specific information about the last completed move – date and time, target database, size of the mailbox and the duration of the move process – then you can use the IncludeMoveHistory parameter:

…which will give the following result:

Fig 5. The result of using the IncludeMoveHistory parameter in a Get-MailboxStatistics cmdlet.

However, if you want some more detailed information, then the last option available is to use the IncludeMoveReport parameter. This parameter is very useful when troubleshooting a move request and not enough information is provided by the Get-MoveRequestStatistics |fl cmdlet, as the parameter will cause a verbose log of the move request to be generated. This log contains a lot of data, and for this reason I recommend to output the command to a CSV file using the Export-csv cmdlet. The complete command will then look like this:

The second method we will consider is monitoring move requests using the Exchange Management Console (EMC). Although it does not provide as much information as when using the cmdlets, it will still give a good overview of the move requests submitted to the server. The move requests can be found under: Recipient Configuration > Move Request.

Fig 6. The Move Request option in the EMC

This will give an overview of all current move requests, including the completed ones, which are displayed by default, and which (if you don’t want them displayed) you will have to manually remove using the Clear Move Request option on the right side of the screen.

When getting the properties of a move request, the following information will be displayed:

Fig 7. The mailbox move information displayed by the EMC.

As you can see it gives a relatively complete overview of the move, including the following information:

• Current status
• Percentage completed
• Duration
• Mailbox size
• Corrupted items
• Source database
• Target database

Normally this should be enough information if you just want to know more about a move request than just its status. The only disadvantage of this method, compared to the PowerShell cmdlets, is that you will need to get the properties of each move request separately.

The details tab will not give you a lot of additional information besides the database versions and the start, queued and completed times for this particular move. However, new in Service Pack 1 is the ability to view the move report, as is available in the Exchange Management Shell when using the IncludeMoveReport parameter. Below is an example of the move request log:

Fig 8. The mailbox move report, as now available in Exchange Server 2010 SP1.

As you can see, huge amounts of information are now made available, which will make a huge difference if you need to troubleshoot a mailbox move request. Compared to the RTM version of Exchange Server 2010, Microsoft has made some improvements to the EMC which I personally think provide a significant benefit, even if we’re just considering this reporting functionality.

Using Performance Monitor a.k.a. Perfmon

When you saw this method mentioned earlier in this article, you may have been a little incredulous. Yes, you can monitor the move-requests using Perfmon, and it may be very useful when, for example, you want view the transfer rate in real-time. The counters which you can use to monitor the requests can be found under the category MsExchange Mailbox Replication Service per MRS Instance:

Fig 9. The appropriate Perfmon Counters for monitoring mailbox moves.

Interesting counters to have a look at during the move requests are:

• Active Moves: Bytes Transfered – the total amount of bytes moved.
• Active Moves: Transfer Rate (KB/sec) – the current transfer rate of the move requests.
• Move Requests/Hour – the average amount of move requests completion per hour.

These are just a few counters, but in total there are more than 60 counters which can be used to monitor the process, and it’s worth experimenting with them to discover how best to employ them. A complete overview of the available counters is available from Microsoft TechNet.

Comparison

So, to help you decide when to use which method for retrieving the correct information, I created a handy table. It does not contain all the available fields, as this would create an enormous table, so I just picked the most import fields to make sure it gives a useful overview:

Conclusion

In this article we’ve discussed several methods for monitoring the process of moving the mailboxes and, compared to the monitoring options available in Exchange 2003, the monitoring process has been vastly improved. Which method you will use will depend on several things, such as the number of mailboxes which you are moving, and the information you want to see.

We’ve also seen a recent addition to the monitoring options in the form of the detailed report now available from the EMC in Exchange Server 2010 SP1. Compared to Exchange 2010 RTM, I think that feature is an excellent decision on Microsoft’s part, as many (if not most) administrators don’t necessarily use PowerShell yet. That being said, I strongly recommend that you start to use PowerShell, as it will give you a lot more options throughout your administration tasks, not only when monitoring the move mailbox process.

Monitoring PST file moves
If you’re looking to move PST files from network locations to Exchange 2007, 2010 or users’ Online Archives, Red Gate’s PST Importer 2010 can be used to monitor the whole import process. Try it for free for 14 days and find where all your PSTs are hiding.