Resolution
Exchange Migrator 1.x
fact
Exchange Migrator 2.x
symptom
When importing DMA mappings into Exchange Migrator it is not working when DMA has been used to translate security on Exchange.
cause
When the DMA mappings are imported it maps the mailbox with the NT user account, however, if you have translated security on the Exchange Mailboxes using DMA, then DMA has changed the primary NT account. This means the mapping that is imported into Exchange Migrator will not be correct since the mapping shows that the primary NT account is still the 'old' Source domain NT account.
fix
A work around to this problem would be to migrate with SIDHistory and not translate security on the Exchange Mailboxes using DMA. By having SIDhistory the target users will still have access to the source mailboxes. Another solution would be to modify the DMAMapping's table in the SQL EMA database.
To do this, you would edit the SourceSAMAcctName column to be the primary NT account of the Source mailbox. If DMA has been used to translate security on Exchange mailboxes, then the SourceSAMAcctName and the DestSAMAcctName should both be "Targetdomain\UserName". When this is the case, you want to modify the SourceSAMAcctName column to reflect the Source mailbox's primary NT account.
For more information on how to manually create a CSV file to import into the DMAMapping table see:
- NETIQKB904: How to create a mapping file between mailboxes and existing NT user accounts?