We have a situation where someone has created mailboxes for users in our target domain prior to the migration. It seems that the Priasoft tools can “merge” into an existing mailbox, but is this safe/recommended? What issues can arise if we migrate into pre-existing mailboxes?
Priasoft supports the re-use of a pre-existing mailbox for migrations, however there are a few important points to consider with this approach.
Pre-existing Data in Mailbox
The Priasoft migrator, when instructed to merge with a pre-existing mailbox, does NOT analyze any data in the target mailbox. As such, if there is data in the target mailbox that was placed there thru a process other than the Priasoft migrator, and that data is from the source mailbox (perhaps a PST import or use of the Microsoft migration tools), Priasoft will duplicate the data.
Items in a folder do not have a persist-able unique identifier per item. The only way to properly validate that 2 items in 2 separate mailboxes are the same item is by an exhaustive inspection of the items details (body, subject, dates, etc.). Due to this fact, Priasoft does not attempt to prevent duplication of data as it is extremely costly from a time and duration perspective.
However, the Priasoft migrator does keep a copy history of previously copied items from its own efforts. If a mailbox were to be re-migrated for any reason, previously copied items would be skipped. As such, the migrator will not duplicate its own work.
Not a Normal Pattern
In most migrations, mailboxes are not pre-provisioned. As such, any case where ‘merge’ is seen in the Priasoft Batch Wizard for a target account, it often means there’s an issue or should at least be a flag for further investigation.
It is possible that the migrator can cross match accounts from source to target. In the batch wizard’s target matching screen, a review of source-to-target matchings should be reviewed by looking both at the display names and the OU of the matching target accounts. If there is already an account in the target of ‘JSmith’ (Jennifer Smith) and the source account being migrated is also a ‘JSmith’ (John Smith), the batch wizard will have matched them on this ambiguous value. The wizard should show the fact that the display names differ. However, it could happen that there are 2 John Smith accounts of 2 separate people. The target matching OU can help identify that the batch wizard matched to the account expected.
So, if in a batch 1 or 2 or a very few are marked as ‘Merge’ while nearly all other accounts are ‘Unavailable’, then the pattern seems suspect. It very well could be that the mailbox was pre-provisioned for some very specific reason – as long as that is understood, and the guidance in the previous section is also understood, it can be left as merge.
Hosting Provider Scenarios
When migrating to a hosted Exchange provider, or if the target environment is being treated as such (like a private cloud), there can be a situation where the provisioning of new mailboxes must be handled by the target environment. Often in these scenarios there are additional attributes and items that need to be added to a user during provisioning. Priasoft’s creation of new mailboxes would be unaware of such customization and can cause an issue or headache for such scenarios.
In this case, the pattern is reversed from the previous topic. In this scenario, the expectation is that ALL target mailboxes should exist prior to migration. This further means that, in the target mailbox assignment page of the batch wizard, if a user is listed as ‘Unassigned’, an issue or at least a flag for investigation exists.
Non-User Mailboxes
The last scenario in which it is likely that target mailboxes might need to be created prior to migration are with non-user mailboxes.
There are some cases where a 3rd party application – like a help desk ticketing solution – requires its own distinct mailbox in Exchange in order to install or configure the application. As long as the data in that new mailbox (if any) has not been imported or otherwise migrated from the source outside of the Priasoft solution, no issue should exist.
Priasoft, when merging into an existing mailbox, does not attempt to change the type or function of the mailbox – we consider it a case of “it is already the way it needs to be”. We will bring over the source email addresses and display attributes and such, but will not change any Exchange specific attributes.
