Moving mailboxes and data is probably
the most critical part of any migration. Any mistakes made here will
almost certainly result in a meeting where you are asked to explain
your actions, which everyone would prefer to avoid.
We have witnessed some painfully difficult
scenarios over the years where mailbox data migrations went wrong. For
example, take the scenario where a Lotus Domino migration to Exchange
2007 mixed up the source and the target mailbox data. The result was
that some users logged on the morning after the migration only to be
presented with someone else's mailbox and calendar data.
Another scenario occurred when a migration
team decided to migrate only the last 30 days' worth of email and no
calendar data but hadn't informed the business of this. While the IT
team viewed this as a successful migration since it met all of their
requirements, the business units held a somewhat different viewpoint.
The bottom line is that end users are rightfully very protective of
their data, and there will be quite an uproar if any of it goes
missing, whether intentionally or not.
Mailbox Replication Service
For Exchange-to-Exchange migrations, moving mailbox data is handled by the Mailbox Replication Service (MRS).
The MRS was introduced in Exchange Server 2010, and it brought with it
some extremely useful benefits over the legacy approach for moving
mailboxes:
- Mailbox moves are now asynchronous, and they are performed by the MRS.
- Mailboxes can be kept online during the move process.
- The items in a mailbox's Recoverable Items folder are moved with the mailbox if the source mailbox is on Exchange Server 2010.
- As soon as the mailbox move begins, content indexing starts to scan
the mailbox so that fast searching is available on completion of the
move.
- You can configure throttling for each MRS instance, each mailbox database, or each mailbox server.
- Remote mailbox moves work over the Internet by way of the Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service.
- MRSProxy helps to simplify migration over firewalls because of fewer ports being required.
- Mailbox moves can be managed from any Exchange 2013 Server within the organization.
- Mailbox content doesn't move through an administrative computer.
- The mailbox's move history is maintained in the mailbox.
Exchange Server 2013 incorporates MRS from Exchange Server 2010 and adds the following improvements:
- The ability to move multiple mailboxes in large batches.
- Email notification during a move with reporting.
- Automatic retry and automatic prioritization of moves.
- Primary and personal archive mailboxes can be moved together or separately.
- An option for manual move request finalization that allows you to review your move before you complete it.
- Periodic incremental syncs to update migration changes.
- Migration endpoints for cross-forest or remote moves.
At its heart, the MRS
is a mailbox move-queuing service. It takes requests to move a mailbox
from a source to its destination and then processes each request on the
administrator's behalf.
One of the most important things to
remember is that the mailbox data is not routed via the administrator's
management console, as it was in Exchange 2007 and prior. The actual
mailbox data movement is controlled via an instance of the Exchange
2013 Mailbox role in the target AD site. This means that you can
generate a move request for a mailbox between two databases in Hong
Kong from a PowerShell session in London, and the migration data will
remain within Hong Kong.
Here is a link to a great post on the Exchange Team Blog that talks in some detail about how MRS in Exchange Server 2010 works:
Although Exchange Server 2013 has made
improvements, the fundamental mechanics of moving a mailbox via MRS
remain the same. This article is highly recommended in order to obtain
a working understanding of MRS prior to beginning your migration
planning.
Preparing for Inter-Org Mailbox Moves
We have already discussed inter-org migration
considerations. This section is intended to take a look at what you
need to do to prepare your target user objects to get them ready for
migration. Before MRS can move a mailbox into another forest, there
must be a mail-enabled target object in the target forest with matching
attributes. A list of mandatory attributes is provided in Table 1.
TABLE 1: Mandatory attributes for a cross-forest move
Note: The proxy addresses of the source
mailbox user must contain an SMTP address that matches the
authoritative domain of the target forest. This allows the New-MoveRequest cmdlet
to select the target address of the source mail-enabled user correctly
(converted from the source mailbox user after the mailbox move request
is complete) to ensure that mail routing is still functional.
These mandatory attributes can be managed
in two ways. The first is via the Forefront Identity Manager 2010 (FIM
2010), which can be configured to synchronize between the source and
the target environments in such a way as to support MRS mailbox moves.
The necessary code and configuration information for this approach can
be found here:
http://technet.microsoft.com/en-us/library/ee861124.aspx
If you do not have FIM 2010 available,
then there is an alternative method that works just as well. The
Exchange team provides a PowerShell script called prepare-moveequest.ps1. This script is installed as part of every Exchange Server 2013 installation in the C:\Program Files\Microsoft\Exchange Server\V15\Scripts
folder. This script has been the cornerstone of many migration projects
since it was introduced in Exchange Server 2010. The script is capable
of creating and updating user objects in the target forest, and it
ensures that they are ready for a cross-forest mailbox move with all of
the mandatory attributes in place.
Use of this script is detailed here:
Storage Capacity
Storage capacity
within the target Exchange infrastructure is a predictable, though
frequently overlooked, consideration during a migration. There are two
areas to consider.
MAILBOX DATABASE VOLUME SIZE
Mailbox database Volume size is simply how
large your mailbox databases will become when you migrate your
mailboxes into them. Rather than attempting to plan for this
specifically during the migration, it is better to plan your target
environment adequately to accommodate all of your mailboxes at their
maximum quota size during the design phase. It's easiest to use the
Exchange Mailbox Server Role Requirements Calculator to help you with
this since it provides the best approximation of the size required to
store each mailbox in your environment. Your completed design should
specify a limit on the number of mailboxes at the maximum quota size
that can safely fit into each mailbox database. As you are planning
your migration, you must ensure that no target mailbox database exceeds
the design target. Additionally, it is recommended that you validate
the predictions at around 25 percent migration complete in order to
ensure that the database sizes agree with those predicted during the
design phase. Do not be tempted to do this validation check too early
since Exchange mailbox databases contain an amount of whitespace that
may make things look worse than they are.
TRANSACTION LOG VOLUME SIZE
Transaction log Volume size has been a
problem for Exchange migrations since the very beginning of Exchange.
The main problem is that transaction logs record all changes made to
the mailbox database, including the data that was added or modified.
This is done so that, in the event of a mailbox database problem, the
transaction logs can be used to replay changes from the last full
backup and bring the database back to a consistently healthy state.
This has always been a great feature of Exchange, and it has saved many
an administrator's bacon when things have gone awry. It also means that
if you move a 1 GB mailbox from the source environment to the target
environment, you need to account for the space to hold both the mailbox
data in the mailbox database and the transaction logs. So while
transaction logs are indeed great, they are also something you need to
watch carefully during a migration.
As a general rule of thumb, the size of
transaction log data generated on the target database will be roughly
equal to the size of the mailbox data being moved. We generally advise
adding 10–20 percent headroom when calculating this to account for
variations. You should also try to leave the log drives with a minimum
of 25 percent free space after each daily migration batch. This may
seem like an overly conservative approach. If you do run out of
transaction log space, however, then the mailbox database will
dismount, and you know what happens next. Thus, all things considered,
it's better to migrate conservatively and work upward rather than begin
with a tidal wave of mailbox migrations, only to begin day two of your
migration in the IT director's office explaining why the new
super-highly available Exchange solution was offline after only half a
day in production. (Yes, this really happened to one of our more
zealous customers.)
Having said all of this about storage
capacity during a migration, make no mistake that failing to account
for it adequately is a very easy trap we have all fallen into at some
point in our careers. All it takes is a failed backup or someone
accidentally scheduling in a few too many or too large mailboxes, and
you too can run into this scenario. Our best guidance here is to define
a plan of action to bring service back online quickly after a
transaction log volume has filled up, and make
sure that your support teams know what to do if it does occur.
Monitoring and alerting can sometimes help here, but typically the rate
of change during the migration is very fast, and so, by the time
someone has been contacted because of a log volume running low on
space, it is generally too late.
Content Indexing
Content indexing (CI) in Exchange has
evolved greatly over the years. CI is the process by which the content
of a mailbox is stored to improve its searchability. As mailbox sizes
have grown over the years, so too has the difficulty in finding what
you are looking for. Maintaining a content index allows you to search
against mailbox contents based on keywords. Initially, it was very
resource-intensive and it provided a fairly poor experience, so most
customers chose not to enable it. Exchange 2007 brought with it a much
better CI implementation, which was retained in Exchange Server 2010.
This new implementation of CI was enabled by default since it was more
efficient. However, the downside of having CI enabled permanently was a
fairly dramatic increase in CPU utilization during mailbox migrations.
With Exchange 2007 and Exchange 2010, a newly migrated mailbox is
scheduled for indexing once it has been successfully migrated. This
means that during a typical migration window, the migration processes
are fighting with the CI processes for system resources. This can
dramatically reduce migration throughput.
Exchange Server 2013 introduced a
totally new CI mechanism based on the Microsoft FAST Search technology.
Furthermore, mailbox migration data is now indexed as it is added
rather than post-mailbox migration. The idea here is to ensure that the
CI is as up to date as possible if the user logs on directly after a
mailbox migration. Initial lab testing suggests that Exchange Server
2013 is throttling index generation during migrations, and disabling CI
during your migration window may no longer have any significant benefit.
