Best practices for doing an Exchange Dry Run using the Priasoft Migration Suite for Exchange

What is a dry run?

The priasoft Migration Suite for Exchange allows you to do a ‘dry run’. An Exchange dry run is a testing process where the effects of a possible migration failure are intentionally mitigated. For example, an aerospace company may conduct a “dry run” test of a jet’s new pilot ejection seat while the jet is parked on the ground, rather than while it is in flight. In addition, a dry run allows you to understand how long your migration will take and what loads can be expected on both source and target Exchange systems.

What are we testing?

The intent of a dry run is to simulate the Exchange migration in a controlled state in order to determine if any potential problems exist that can be remediated prior to the actual production migration. The following list shows the most common reasons for doing a dry run:

• To monitor and understand the loads placed on the source, target, migration console, and network during the operation
• To determine the proper level of concurrency to use during the migration. (concurrency refers to the total number of mailboxes being migrated simultaneously)
• To review the proposed configuration and determine if any configuration issues exist that would limit or risk a successful migration
• To determine if any database corruption exists, and if so, how much and who is affected.
• To get an estimated or more accurate time of how long the production migration will actually take.

Understanding the process

During a dry run the application will create place holder windows accounts in the target for each migrating user. Each user will be assigned a mailbox and the data and attributes for the source user will be migrated to the place holder target. These target objects are intentionally named and will be created is such a way as to not interfere with the production objects or with any users that may already be using the target system. In addition, the source objects are not modified in any way and the entire process is a read-only operation with the exception of the place holder objects in the target that were created specifically for this purpose. The overall intention is to remove these temporary objects after the dry run is completed. Note: You should never attempt to modify a dry run object is such a way as to attempt to put into production.

Best practices for doing a dry run

Key concepts for doing dry runs that will make for cleaning up post much easier:

• You should create an OU on the target to contain dry run objects that will be created as part of the process.
• Note: The normal matching is disabled and you are only allowed to create place holder windows accounts in the target.
• You should create mailbox databases in the target that are just for dry run purposes (this prevents white space from being created in existing production databases once the dry run objects are removed)
• All dry run database(s) should be enabled for circular logging to avoid any log disk space issues during the dry run.
• You should also monitor the Source exchange servers for disk I/O, specifically the disk read queue length as any value above 3.0 would indicate you have too many users migrating simultaneously and may want to lower the amount of concurrency.
• Keep an eye on the messages per second performance counters on the migration server as this is another key indicator as to the speed and velocity the migration tool can sustain. Too much concurrency and this value can decrease.
• Post dry run; inspect the output of the Migration Summary’s looking for any mailboxes that have a high number of skipped items as this can indicate potential problems. Normal skip counts are less than 1-2% of total items and generally zero…

Enabling dry run mode

To enable dry run mode, select the check box within the Migration Wizard.