In the migration project we are starting, user accounts in the target will not, by default, have any matching details with the source accounts. We’ve chosen to use Employee IDs for logon names and other security measures.
The batch wizard seems to match on email address and logon name and causes zero matches and much manual effort. Is there a better way?
There is an ability in the wizard to use a custom matching routine, however before this is used it may be better to analyze exactly why matching is not occurring.
The batch wizard’s matching routine uses a few common, but unique values to perform matches. The match algorithm is as such:
For each source account, get its Primary SMTP Address, NT Logon Name, Mail Alias, and directory name.
Search the target AD for an account where ANY ONE of the following is true:
- Source email address matches target email address
- Source mail alias matches target alias
- Source mail alias matches target logon name
- Source logon name matches target logon name
- Source logon name matches target mail alias
- Source directory name matches target logon name
Given the above, it is possible for an ambiguous match to occur. Consider a case where the source user’s mail alias and logon name is ‘jsmith’. However in the target there is one account with the logon name JSmith but another, distinct account with a mail alias of JSmith (but with a different logon name). The search would return both accounts for the one source and would be left unmatched.
It is also possible that there simply is no match between any of the source attributes used and any detail of target accounts.
It is likely a better strategy to examine how it could be possible to ensure that at least one of the attributes matches.
Priasoft recommends the creation of target accounts either by our dir-sync solution or by some solution that can enable target users as mail-enabled users before migration (a mail-enabled user being a user account that forwards mail elsewhere, not a mailbox-user). This allows for a match on primary smtp to be established as well as to allow for mail-flow coexistence. It could be that, even if all mailboxes are to be migrated in the same event, some application or service in the target environment needs to send mail to users before migrations complete. Having the forwarding objects in the target environment, pointing at source mailboxes, allows this to happen.
However, it is understood that there may still be a valid reason for an alternative to the default search pattern. Using a registry override the batch wizard can be made to do a custom attribute matching, as follows:
KEY: HKEY_CURRENT_USER\Software\Priasoft\Mailbox Migration Manager 6.5\Control
NAME: UseCustomAutoMatch
TYPE: REG_DWORD
VALUE: 1 = Enabled; 0 (or missing) = Disabled
When this value is enabled, the Auto Match button in the wizard will use the LDAP attributes you define in the next key for establishing a match between source and target.
KEY: HKEY_CURRENT_USER\Software\Priasoft\Mailbox Migration Manager 6.5\Control
NAME: CustomAutoMatchParams
TYPE: REG_STRING
VALUE: SourceLDAPProp:TargetLDAPProp
The value in the key above should be 2 LDAP property names separated by a colon and no spaces. The properties chosen must be single valued string properties, but do not have to be the same on both sides; for instance it is valid to have this “DisplayName:ExtensionAttribute5”, but this is not valid: “DisplayName:URL”.
The behavior of AutoMatch will, for each source account, grab the SourceLDAPProperty, and attempt an LDAP search for the value in the TargetLDAPProperty. Note that by default AD does not perform case sensitive searches on strings.
