Note: You can move content between mailbox servers using the graphical user interface, but it’s usually easier to use Exchange Management Shell commands because you can perform bulk moves using a single line of code.
Moving mailboxes to Exchange 2010 using PowerShell
In Exchange Server 2010, mailbox moves are performed using move requests. A move request requires the name of the mailbox being moved as well as the name of the target database. If you don’t specify a target database, Exchange will select one at random.
For example, if you wanted to move a mailbox named User1 to an Exchange 2010 database named DB1, you could use the following command:
New-MoveRequest –Identity User1 –TargetDatabase DB1
Now that you know how to move a single mailbox, a more efficient approach is to move all of the mailboxes from an entire mailbox database with a single command. For example, to move all of the mailboxes from DB1 to DB2, use the following command:
Get-Mailbox –Database DB1 | New-MoveRequest –TargetDatabase DB2
It’s also possible to create a detailed report of the moves after they've been completed. The report can be written to a text file or to a CSV file. To create a move report and write the output to a file named C:\MOVE.LOG, enter the following command:
Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, TotalItemSize, TotalMailboxItemCount, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:\move.log”
If you don’t want to wait to check the status of the move, you can also generate a report to find out how it is progressing. If you want to see how far along the move is, use the following command:
Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, PercentComplete, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:\move.log”
When all your mailbox moves complete, you must terminate the move request. If you don’t, you won’t be able to move the mailboxes again should the need arise. To terminate a move request, use the Get-MoveRequest | Remove-MoveRequest command.
Moving public folders to Exchange 2010 using PowerShell
Public folders are not a requirement in Exchange Server 2010 unless you plan on having an Exchange 2010 mailbox server that supports clients running Outlook 2003 or earlier. That said, if you have public folders on your legacy Exchange servers that contain useful data, you can move them to Exchange 2010 using PowerShell.
To move all of the public folder replicas from one Exchange server to the other, open the Exchange Management Shell, and enter the following commands:
CD “Program Files\Microsoft\Exchange Server\V14\Scripts”
./MoveAllReplicas.ps1 –Server <old server name> -NewServer <new server name>
When the process completes, set the execution policy back to RemoteSigned by entering the Set-ExecutionPolicy RemoteSigned command.
Importing PST files into Exchange 2010 using PowerShell
Exchange Server 2010 is the first version of Exchange to support personal archive mailboxes. Many organizations place archive mailboxes onto dedicated mailbox servers that are equipped with low-cost storage, so that user archives do not affect the performance of the primary user mailboxes.
Archive mailboxes offer a great alternative to PST files, and many organizations have begun moving PST file contents to archive mailboxes as a part of the migration process. Note, however, that this method works only for Exchange 2010 SP1. The RTM release of Exchange 2010 used a different PowerShell cmdlet that was buggy. You should also know that this cmdlet doesn’t create the archive mailboxes; so make sure that the archive mailboxes actually exist before using it.
To import a PST file into an archive mailbox, use the New-MailboxImportRequest –FilePath <the path to the PST file> -Mailbox <mailbox name> -IsArchive cmdlet.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in March 2012