Click here to monitor SSC
  • Av rating:
  • Total votes: 13
  • Total comments: 1
Johan Veldhuis

Monitoring Mailbox Moves

17 November 2010

Mailboxes moves happen all the time, and given how precious the data in mailboxes can be, you should know exactly how to monitor their progress and make sure they transition smoothly. You also need to know what happens when something goes wrong. Johan imparts the necessary skills.

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:

Get-moverequest|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:

Get-moverequest –MoveStatus 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:

Get-moverequeststatistics
|select DisplayName,PercentComplete,TotalMailboxSize,BytesTransferedPerMinute

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

Get-moverequest –MoveStatus InProgress
|Get-moverequeststatistics
|select DisplayName,PercentComplete,TotalMailboxSize,BytesTransferedPerMinute

...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:

Get-mailboxstatistics –identity johan –includemovehistory |fl

...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:

Get-mailboxstatistics –identity johan –includemovereport|export-csv c:\reports\johan.csv Using the Exchange Management Console

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.

Johan Veldhuis

Author profile:

Johan Veldhuis is a Techncial Consultant for Communicativ. Prior to working for Communicativ Johan worked several years for AXIANS a system integrator in The Netherlands, first as service desk engineer and later as server & storage engineer. Johan is a MCSE-M and MCITP and was awarded the Microsoft MVP Award (Exchange Server) for his contributions to the messaging and collaboration community. Johan has also his own website where he blogs and publishes tutorials mostly about Exchange. You can reach Johan at j.veldhuis@communicativ.nl. j.veldhuis@communicativ.nl or follow him on twitter via @jveldh

Search for other articles by Johan Veldhuis

Rate this article:   Avg rating: from a total of 13 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Powershell Script to monitor moves in Progress
Posted by: SRed13 (view profile)
Posted on: Thursday, April 05, 2012 at 6:14 AM
Message: Hello Johan! Three weeks ago we had to migrate in mass all of our user's from Exchange 2003 to 2010 after a hardware failure.

Because this was such a high-profile operation, I wrote the following script to monitor moves in progress, complete with a one minute downtime between updates (with a fancy progress bar too, thanks to Matt Brown's Pause Program.ps1 script)

Hopefully your visitors will find it useful.

This will run forever, or until you hit Crtl+C and displays all users whose move status is not Queued or Suspended.

function Sleepytime
{param($min=1)
$x = $min*60
$length = $x / 100
while($x -gt 0) {
$min = [int](([string]($x/60)).split('.')[0])
$text = " " + $min + " minutes " + ($x % 60) + " seconds left"
Write-Progress "Pausing Script" -status $text -perc ($x/$length)
start-sleep -s 1
$x--
}
}

for (;;){

$a = Get-MoveRequestStatistics -MoveRequestQueue DAGDB1 | ? {$_.Status -ne 'Queued'} | ? {$_.Status -ne 'Suspended'} | Select DisplayName, Status, TotalMailboxSize, PercentComplete
$b = Get-MoveRequestStatistics -MoveRequestQueue DAGDB2 | ? {$_.Status -ne 'Queued'} | ? {$_.Status -ne 'Suspended'} | Select DisplayName, Status, TotalMailboxSize, PercentComplete

$a,$b | ft -auto

Write-host "Total remaining:" (Get-MoveRequest).Count

Sleepytime 1
}

 

Top Rated

Migrating to Microsoft BPOS - Part II
 In his last article, Johan gave us a crystal clear guide to preparing to migrate from an on-premises... Read more...

Emulating the Exchange 2003 RUS for Out-of-Band Mailbox Provisioning in Exchange 2007
 Exchange's Recipient Update Service was important in Exchange 2000 or 2003 in order to complete the... Read more...

The Postmasters
 The Exchange Team introduces themselves, and keeps you up-to-date Read more...

For this Exchange Server Archiver, “Transparency” Fits
 Sometimes, it is a great relief when a user of your software gives it a tough test and then reports... Read more...

Hunting in Packs, Seamless-ness and Happy Holidays
 I attended DevConnections (Exchange) last month and was blown away by the technical talks. Speakers... Read more...

Most Viewed

Upgrade Exchange 2003 to Exchange 2010
  In this article, the first of two in which Jaap describes how to move from Exchange Server 2003... Read more...

Upgrade Exchange 2003 to Exchange 2010 - Part II
 In Jaap's second article on upgrading straight from Exchange Server 2003 to 2010, he explains how to... Read more...

Goodbye Exchange ExMerge, Hello Export-Mailbox
 ExMerge was a great way of exporting a mailbox to an Exchange PST file, or for removing all occurences... Read more...

Exchange E-mail Addresses and the Outlook Address Cache
 Because Exchange auto-complete cache uses X.500 addresses for e-mail sent to addresses within the... Read more...

Using Exchange 2007 for Resource Booking
 The process of booking various resources to go with a meeting room just got a whole lot easier with... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.