The destination database for an on-premises mailbox move can be on
the same server, on a different server, in a different domain, or in a
different Active Directory site. Exchange Server 2013 performs move
operations as a series of steps that allows a mailbox to remain
available to a user while the move operation is being completed. When
the move is completed, the user begins accessing the mailbox in the new
location. Because users can continue to access their email account
during the move, you can perform online moves at any time.
The online move process hasn’t changed substantially since it was introduced with Exchange Server 2010:
-
On-premises mailbox moves are initiated with a Move Mailbox request
that is sent to the Microsoft Exchange MRS running on a Client Access
server in the source forest. The MRS queues the request for processing,
handling all requests on a first-in, first-out basis. When a request is
at the top of the queue, the replication service begins replicating
mailbox data to the destination database.
-
When the replication service finishes its initial replication of a
mailbox, it marks the mailbox as Ready To Complete and periodically
performs data synchronization between the source and destination
database to ensure that the contents of a mailbox are up to date. After
a mailbox has been moved, you can complete the move request and
finalize the move.
When you are working with PowerShell, you initiate a move using
New-MoveRequest and then start the actual move using Start-MoveRequest.
Although the online move process allows you to move multiple mailboxes,
with each move handled as a separate request, the process isn’t ideal
for batch moves of multiple mailboxes, and this is where mailbox
migrations come in. With mailbox migration, you can move multiple
mailboxes in an Exchange on-premises organization, migrate on-premises
mailboxes to Exchange Online, or migrate Exchange Online mailboxes back
to an on-premises Exchange organization.
Note
You
can use the batch migration process to move single or multiple
mailboxes within on-premises Exchange. With a single mailbox, the batch
migration is handled as a local move.
From a high level, the standard batch migration process is similar to a mailbox move:
-
Batch mailbox migration is initiated with a Migration Batch request
that is sent to the Microsoft Exchange MRS running on a Client Access
server in the source forest. The MRS queues the request for processing,
handling all requests on a first-in, first-out basis. When a request is
at the top of the queue, the replication service begins replicating
mailbox data to the destination database.
-
When the replication service finishes its initial replication of a
mailbox, it marks the mailbox as Ready To Complete and periodically
performs data synchronization between the source and destination
database to ensure that the contents of a mailbox are up to date. After
a mailbox has been migrated, you can complete the migration request and
finalize the migration.
Where things get complicated are on cross-forest batch migrations
and remote migrations. With a cross-forest migration, you perform a
batch mailbox migration from an Exchange server in one Active Directory
forest to an Exchange server in another Active Directory forest. With a
remote migration, you perform a batch mailbox migration from
on-premises Exchange to Exchange Online or vice versa.
Cross-forest and remote migrations use migration endpoints. You
create a migration endpoint in the target environment. The endpoint
identifies the source environment where the mailboxes are currently
located. You then initiate the migration in the target environment.
With a cross-forest migration, this means you:
-
Create a migration endpoint in the target domain.
-
Initiate the migration in the target domain.
With a migration from on-premises Exchange to Exchange Online, this means you:
-
Create a migration endpoint in Exchange Online.
-
Initiate the migration from Exchange Online.
With a migration from Exchange Online to on-premises Exchange, this means you:
-
Create a migration endpoint in on-premises Exchange.
-
Initiate the migration from on-premises Exchange.
A complete cross-forest or remote migration has four parts. You
create a migration endpoint using New-MigrationEndpoint and then create
the migration batch using New-MigrationBatch. You start the migration
using Start-MigrationBatch. When the migration has finished initial
synchronization, you can finalize the migration using
Complete-MigrationBatch.
In Exchange Admin Center, you can initiate move and migration
requests using the options on the Migration page. To access this page,
select Recipients in the feature pane and then select Migration (see Figure 1).
Although the PowerShell commands for moves and migrations give you
complete control over the process, you’ll find that Exchange Admin
Center greatly simplifies the process:
-
For local moves, you log on to a Client Access server in the Active
Directory forest where the source mailboxes are located. On the
Migration page, select New and then select Move To A Different
Database. Follow the prompts in the New Local Mailbox Move dialog box
to perform the move.
-
For remote migrations, you can use the options in Exchange Admin
Center for Exchange Online to initiate the process, whether migrating
from or to Exchange Online. On the Migration page, select More Options,
select Migration Endpoints, and then follow the prompts to create the
required migration endpoint. Next, select New and then select either
Migrate To Exchange Online or Migrate From Exchange Online as
appropriate. Follow the prompts in the New Migration Batch dialog box
to perform the migration.
-
For cross-forest moves, you log on to a Client Access server in the
target Active Directory forest. On the Migration page, select More
Options, select Migration Endpoints, and then follow the prompts to
create the required migration endpoint. Next, select New and then
select Move To This Forest. Follow the prompts in the New Cross-Forest
Mailbox Move dialog box to perform the move.
On the Migration page, you also can track the status of move and
migration requests. If a move or migration request fails, you can get
more information about the failure by double-tapping or double-clicking
the request and then tapping or clicking View to the right of the
Failed Message entry.
When
you move mailboxes from one server to another, to a different
organization, or even to a different database on the same server, keep
in mind that the Exchange policies of the new mailbox database might be
different from the old one. Because of this, consider the following
issues before you move mailboxes to a new server or database:
-
General policy
. Changes to watch out for include the storage limits,
the deleted item retention, and the default offline address book
settings. The risk is that the users whose mailboxes you move could
lose or gain access to public folders. They might have a different
offline address book, which might have different entries. This address
book will also have to be downloaded in its entirety the first time the
user’s mail client connects to Exchange after the move.
-
Database policy
. Changes to watch out for pertain to the maintenance
interval and automatic mounting. If Exchange performs maintenance when
these users are accessing their mail, they might have slower response
times. If the mailbox database is configured so that it isn’t mounted
at startup, restarting the Exchange services could result in the users
not being able to access their mailboxes.
-
Limits
. Changes to watch out for pertain to storage limits
and deletion settings. Users might be prohibited from sending and
receiving mail if their mailbox exceeds the storage limits of the new
mailbox database. Users might notice that deleted items stay in their
Deleted Items folder longer or are deleted sooner than expected if the
Keep Deleted Items setting is different.
