A new feature added in version 1.0.264 of the DiRT restore application is the ability to remap subscriber alias strings during the restore process.  Typically this is to handle situations where you’re backing up Unity data from a voice mail only deployment and moving it into a unified messaging deployment where the alias naming convention is different.  The mechanism for doing this is very simple: construct a CSV file that contains the old alias strings found in the Unity backup and the new alias strings you would like to use in the restored system.  During the restore process, DiRT will search for all the old alias strings and, if found, will replace them with the newer version you specify.  This is done _before_ the directory synchronization is kicked off so Unity will bind to users based on the new alias string (or create new accounts as the case may be).

The format of the CSV file is very simple.  It must contain the first line that looks like this:

OLD_ALIAS, NEW_ALIAS

When you select the CSV file to use for alias mapping, if it doesn’t see that first line with those column names it will not accept the file.  You will find a file named “AliasMap.CSV” that’s added to the installation directory you can use as a template.  There can be other columns in the file, however those two must be there or the file will not be used.

If the old alias provided is not found in the restored database, it’s simply noted in the log file and skipped.  This is not considered an error condition.  All aliases that are found and replaced in the local system are noted in the DiRT restore output log.

Only aliases for _local_ subscribers on the server are searched for and replaced – subscribers in the global subscriber table from other Unity servers are not searched for.

NOTE: The new alias string is used as is – if an illegal string is passed then the synch will fail for that user.  All responsibility for conforming to appropriate alias conventions is up to you.

NOTE: The Alias and UID columns in the subscriber table are nearly always the same string – in some rare cases they are different.  If you use the alias mapping function but the UID and the alias columns are changed to match the new alias string provided. 

NOTE: The same search criteria are used when looking up users in the directory regardless of if you remap the aliases or not.  So if you remap the alias name but the DirectoryId of the user is found in Active Directory, that user is bound to.  So you cannot use this mechanism to change the alias strings for standing users in a system.  See the Creating New Accounts or Binding to Existing Accounts above for details on this process.

IMPORTANT NOTE: The alias remapping functionality runs through the CSV file you provide and changes the old alias to the new one in a linear fashion.  If the new alias conflicts with an alias already in the subscriber table, that alias remap will be skipped, and error will be logged and an error dialog will pop up notifying you of the fact.  You may continue and the restore will complete but that user will still have their old alias assignment.  It is up to you to make sure the alias naming convention you use and the order in which the changes are applied do not result in conflicts, the DiRT restore process does not do advanced "prechecks" for such conditions ahead of time.