The Exchange Control Panel (ECP) was designed to allow administrators and users the ability to perform common management tasks within Exchange 2010 without installing any Management Tools. This is a great option that the Exchange team included with Exchange 2010.
With Exchange 2010 RTM, it was not possible to log into the ECP unless the user logging in had a mailbox. This is ok for most users since one of the design goals of ECP was to provide a way for users to “self-service” their account. Users can get to the ECP by selecting Options –> See All Options…within OWA.
Where this breaks down is that best practices state that users which require administrative rights should split accounts so that the user has an everyday account (that is mail enabled) and a privileged account (that is not mail enabled). With Exchange 2010 RTM, this pushed administrators to enable their administrator accounts for email or just use their everyday account to administer Exchange.
Starting with Exchange 2010 SP1, non-mail enabled accounts can now log into the ECP. As an example, the following user ExchangeAdmin is a member of Organization Management and does not have an email account.
Most users access the ECP from the Options menu in OWA. If ExchangeAdmin tries to log into OWA, they will get the following error:
In order for the ExchangeAdmin to be able to log into ECP, they will need to use the URL that takes them directly to the ECP to log in. In my example, this is https://mail.lab.com/ecp. The non-mail enabled account can now log in and access the ECP:
Now with Exchange 2010 SP1, non-mailbox enabled accounts can log in to the ECP.
Exchange 2010 introduces the concept of Move Requests instead of the traditional Mailbox Moves found in earlier versions of Exchange.
This is a complete redesign for how mailbox moves are managed.
So why the change?
- Mailbox moves are now asynchronous and are carried out by the Exchange Mailbox Replication Service located on each CAS server (instead of being carried out by the actual cmdlet or console)
- Mailboxes are kept online during the asynchronous moves (users do not lose their connection to their mailbox during the move and can continue to send and receive email)
- Items in a mailbox’s Recoverable Items folder are moved with the mailbox
- Content indexing starts to scan the mailbox as soon as the mailbox begins to move
- Throttling can be configured for each mailbox replication service, database or server
- Moves can be managed from any Exchange 2010 server
- Mailbox content doesn’t move through the server creating the request, this allows shut down of the console during the mailbox move
There are two types of Move Requests: Local and Remote. Local is used for any mailbox moves within the same Exchange Organization. Remote is used for any cross-forest migrations. A Move Request can be initiated two different ways: from EMC and EMS.
From EMC, navigate to the Recipient Configuration –> Mailbox node. Right-click on a mailbox and select New Local Move Request. After the wizard is complete, a new Move Request will be created and the mailbox will be moved.
The same function can be performed in the EMS by running the following command:
New-MoveRequest –Identity Alias –TargetDatabase “DatabaseName”
Note that if a database name is not specified, a random database is selected.
Status of the Move Request can be viewed by navigating to the Recipient Configuration –> Move Request node and selecting the properties of the Move Request.
Also a complete report can be generated from the EMS by running the following command:
Per Mailbox: Get-MailboxStatistics –Identity Alias –IncludeMoveReport | fl
For a complete report for all moves including specific fields and outputting to a text file:
Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, TotalItemSize, TotalMailboxItemCount, PercentComplete, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:\temp\FullMoveUserLog.txt”
One thing that is different is that the Administrator will have to clear out any Move Requests if a mailbox needs to be moved again or a database deleted. Through the EMC, if a Move Request still exist, the administrator will not even have the option to create a New Local Move Request. From the EMS, the error that an administrator will see if the Move Request is not cleared out is shown below.
Move Request can be cleared either from the EMC or EMS. From the EMC, simply right-click on the Move Request within the Recipient Configuration –> Move Request node and select Clear Move Request. From the EMC, the following command can be executed to clear any Move Request.
Get-MoveRequest | Remove-MoveRequest –Confirm:$false
The complete Move Request workflow is shown in the following diagram (courtesy of Microsoft):
