Resolution
Can I change or extend the property mapping for attributes between the Source and Target account in Domain Migration Administrator?
fact
Domain Migration Administrator 7.x
fix
Manipulating how attributes are mapped can be accomplished through Database Modeling. By default, without enabling Database Modeling, DMA will migrate attribute for attribute between domains of the same Operating System and attribute. For a Windows NT to Windows 2000 migration the mapping is done based on the following:
| NT Attribute | AD Attribute |
Login Name (SAMAccountName) | CN |
Login Name (SAMAccountName) | SAMAccountName |
Login Name (SAMAccountName) | User Logon Name |
Login Name (SAMAccountName) | User Logon Name (Pre-Windows 2000) |
Full Name | Display Name |
Description | Description |
If you wish to add or manipulate how DMA migrates attribute information, you can do so through Database Modeling; however, please keep in mind that manipulating the DMA database is unsupported by technical support and can cause other issues if not tested completely in your environment . You can also extend data modeling to include other Active Directory default schema attributes. The NT and Active Directory attributes correspond to the ADSI names as defined by Microsoft. Please refer to the Microsoft Knowledge Base or MSDN for more information regarding the available attribute names.
There is an Access 2000 database for each migration project. The project database is located on the DMA console in:
- C:\Project Files\NetIQ\DMA\Projects\<projectname>\<projectname.mdb>
The following tables are in each project and are used in building the database modeling information:
- PropList - Contains the list of properties that can be modeled based on target domain version.
- PropMap - Contains mappings used by DMA to collect information from source domain that is in a different version from the target.
The PropMap and PropList tables are only used during Database Modeling.
To extend the properties that can be modeled by DMA a user would need to .
manipulate these tables. To add properties to be modeled the user can add an entry into the PropList table. Following is an example of one such entry. Adding this entry would allow users to model the telephone numbers for objects when migrating to a Windows 2000 domain. Microsoft Access 2000 is required to edit these tables. Close the DMA user interface and backup the database before editing it.
Adding an Attribute for Editing in Database Modeling
The following example will add the Telephone Number attribute in the Database Modeling table for editing. Refer to Microsoft for the full list of attributes used by AD or NT.
The PropList table contains the list of properties that can be modeled based on the target domain version. To extend the properties that can be modeled by DMA, the administrator would need to manipulate this table. To add properties to be modeled the administrator can add an entry into this table. Following is an example of one such entry. Adding this entry would allow users to model the telephone numbers for the objects when migrating to a Windows 2000 domain.
DomVer | PropName | PropType | Include | Ndx | UserObjects | groupobjects | computerobjects |
5 | telephoneNumber | Memo | Yes | 6 | Yes | Yes | Yes |
- DomVer- represents the target domain version. (NT=4, W2K=5)
- PropName- the attribute name
- PropType- the property type (Memo is the most common)
- Include- Yes/No to include in database modeling
- Ndx- The place it will be listed in the Database Modeling Table
- UserObjects, groupobjects, ComputersObjects- Yes/No to be shown when editing during database modeling for the specific object
Once added the attribute will appear in the database modeling for editing and migration.
Manipulating how data is mapped between account migrations can be done through database modeling. Actual editing does not have to take place but in order to implement the mapping changes, the object must be migrated with Database Modeling enabled as the source for account information (by selecting the checkbox for 'Migrate data using modeling database as source?' in the user or group migration wizard). The PropMap table contains the mappings used by DMA to collect information from the source domain that is of a different version than the target domain.
If you are migrating accounts between domains with different versions and you want the properties to be pre-populated in the database with different properties from the source domain, then you could add an entry into the PropMap table to accomplish this. The following is an example that maps the NT 4 FullName property to the Windows 2000 displayName property.
Source | Target | SrcProp | TgtProp |
4 | 5 | FullName | displayName |
Note: These instructions are based on the design of DMA but they have not been tested. These instructions are to be tried by users at their own risk. NetIQ will not support this configuration. If you require assistance we have a fee-based Custom Solutions department that can assist with custom deployments..