Migrations tend to be complex affairs. Migration from
old-style to modern public folders is unlikely to be simple for many
organizations, especially when the hierarchy is large. It is a one-time
cutover in that after you perform the switchover to modern public
folders, it is difficult if not impossible to revert without losing
data because no synchronization facilities exist between one type of
public folders and the other.
Microsoft
includes a set of scripts with Exchange 2013 to assist in the migration
of content from public folder databases. It has also documented an
approach to the migration that you can read at http://technet.microsoft.com/en-us/library/jj150486.aspx.
This is a useful framework on which to build a customized migration
plan for your organization after you do some up-front planning.
However, it’s almost inevitable that new and valuable techniques will
be discovered that help perform public folder migrations more
effectively or quickly, so it’s always wise to read available sources
of information to establish the current state of the art before you
start.
No migration can be successful if you do not possess full
information about the data that has to be moved. Accordingly, some
basic questions have to be answered, including:
What
business use exists for public folders today? Is the correct go-forward
decision to move to modern public folders, or should another solution
be used? For instance, site mailboxes are a better choice for
document-centric collaboration, albeit at the expense of requiring an
investment to deploy SharePoint 2013 and Outlook 2013.
What applications (electronic forms) are used with public folders? Are all these applications still required?
How many public folders exist in the hierarchy?
How much data (items, size) are held in the public folders? How old is this data?
Who
manages the data and permissions for public folders? How long is the
data retained, and what arrangements are in place to maintain (clean
up) the data? This information is necessary to set the retention period
for the new public folder mailboxes.
How
many public folder databases are in use, and why are they in use? For
example, do large populations of public folder users exist in
particular locations that depend on a local public folder database?
You
can answer some of the more fundamental questions by running the
AggregatePFData.ps1 script (available on Exchange 2010 servers) to
provide an overview of the current public folder infrastructure,
including the names of folder owners, the date a folder was last
accessed, whether a folder is mail-enabled, and how many items it
contains. It is a good idea to run the script and then review the
output to cull unwanted and obsolete public folders from the hierarchy
before migration begins. If a need exists to retain information from an
obsolete public folder, the data can be copied to a PST before the
folder is removed.
Before
commencing any migration, you should move user mailboxes to Exchange
2013. Exchange 2013 users can still access old-style public folders,
but the reverse is not true because Exchange 2010 and Exchange 2007
mailboxes do not understand the new format.
After rationalizing the current public folder infrastructure, the migration process can begin. The recommended steps are:
Take
a snapshot of the current public folder infrastructure. You can do this
by running the AggregatePFData.ps1 script or by following the steps
outlined in TechNet. The purpose of this step is to have a baseline
that you can use for post-migration comparison to ensure that all the
necessary information has been moved across to modern public folders.
Prepare
Exchange 2010 by removing any trace of a previous migration attempt. Do
the same for Exchange 2013. This means that you remove any public
folder migration jobs and any public folders that you previously moved
in an incomplete migration. In other words, you create a clean
environment for the migration to commence.
Run
the Export-PublicFolderStatistics.ps1 script on Exchange 2010 to
generate a file containing a list of public folder names and their
sizes.
Run the
PublicFolderToMailboxMapGenerator.ps1 script to read the set of public
folder names and map them against a set of public folder mailboxes. One
of the parameters for the script is the maximum mailbox size (in
bytes), so you have some control over the number of public folder
mailboxes that will be used. The aim is to distribute public folders so
that the public folder mailboxes take equal load. This is done purely
by folder size rather than by taking account of user demand, so you
might have to move public folders between mailboxes afterward.
The
output from the script is a CSV file. However, Exchange does not read
the CSV file and create the necessary public folder mailboxes for you.
Instead, you use the contents to know how many public folder mailboxes
you have to create. You then create the mailboxes and place them in
appropriate databases. These public folder mailboxes are created with
the HoldForMigration parameter set so that (as the name implies) they are reserved for migration purposes and won’t be exposed to clients.
The
CSV file is now used as input to a public folder migration job that the
Migration service runs to move content from the old public folders to
the new. Make sure that the contents of the CSV file reflects the names
of the public folder mailboxes that you created. Microsoft suggests
that the migration will proceed at between 2 GB and 3 GB per hour,
depending on system resource availability and other load. The migration
job, which uses the New-PublicFolderMigrationRequest command (similar
in concept to the New-MigrationBatch command to move batches of
mailboxes), copies all the content from the source folders that is in
place when the migration starts to the public folder mailboxes and then
holds the migration.
After
checking the migration job report and making sure that everyone is
ready to make the switchover, lock down the old public folders by
running the Set-OrganizationConfig command to put the organization into
locked mode. The flag used for this purpose is replicated through the
organization, and clients cannot add new content to public folders at
this time.
Release the suspended
state of the public folder migration job. The Migration service
performs an incremental synchronization of the source public folders
and moves any new content it finds to the public folder mailboxes.
Take
a snapshot of the data in the public folder mailboxes and compare it to
the snapshot taken prior to the migration to assess whether all the
folders and data have been migrated successfully.
If the migration is complete, run the Set-OrganizationConfig command to set the PublicFolderMigrationComplete flag to $True. The CAS now redirects users to public folder mailboxes instead of to the old public folder databases.
If
more than a few days elapse between when the Migration service copies
over data in a migration job (step 6) and when the cutover occurs, you
can perform incremental synchronizations to ensure that minimal data
needs to be copied from the old public folders during the finalization
process (step 7 onward). An incremental public folder synchronization
is performed by running the Resume-PublicFolderMigrationRequest cmdlet,
which then copies any new data and updates that have occurred in the
old public folders since the initial synchronization occurred. You can
run as many incremental synchronizations as are necessary to keep the
two sets of public folders in steps pending the cutover.
Only
the finalization stage, when the cutover actually occurs, requires
downtime during which public folders will be unavailable to users.
However, the ideal situation is to perform public folder migrations
over a weekend or holiday period when it is less likely that users will
need to access public folders, and administrators can take the
necessary time to prepare, execute, validate, and complete the
migration. It is also valuable to run a practice migration by using a
test environment that contains a complete copy of the production public
folder environment because this gives real-life guidance about the
effectiveness of the procedure and the time the migration is likely to
require.
