During migration, conflicts might occur between objects that already exist in Active Directory and objects that are being migrated. These conflicts can arise because Server for NIS extends the existing Active Directory classes for users, groups, and computers, and merges incoming objects in these classes. Conflicts can also occur because Server for NIS allows one Network Information Service(NIS) domain to merge with another NIS domain that has already been migrated to Server for NIS.
For example, consider a passwd map source file being migrated to Server for NIS. Suppose there is a UNIX user with a user name johndoe. If there is no existing user with a user name johndoe, migration of this user to Server for NIS is simple. If there is already a user with that user name previously migrated from another NIS domain, however, a conflict would occur.
When the NIS Server Migration wizard encounters a potential name conflict during migration, it resolves the conflict by prefixing the name being migrated. If the name being migrated is a user name, the prefix consists of the NIS domain name plus the characters _u_. If the name being migrated is a group name, the prefix consists of the NIS domain plus the characters _g_. This allows the migration to complete even if there is a conflict.
For example, if you are migrating a user named johndoe in an NIS domain named mktg, and a user with the same name was previously migrated from another NIS domain, then user name of the johndoe in the mktg domain will be changed to mktg_u_johndoe during the migration.
When such conflicts occur, you need to examine the migration logs and then determine how to handle each case. You need to consider whether the conflicting name represents the same user or group in both domains, or different users or groups. If not, you will probably want to rename one or both users or groups. If they do represent the same user or group, then you will need to decide whether the user or group really needs to be in both domains (in which case, at least one of them needs to be renamed) or whether the user or group in one of the domains can be deleted.
Rather than deal with the conflict after the domain migration has occurred, you can determine in advance whether a conflict will occur and then take steps to prevent the conflict (such as by changing the name of a user or group in the NIS domain).
By default, the NIS Server Migration wizard performs what is known as a dummy migration. During this process, the NIS Server Migration wizard goes through all the steps required to migrate an NIS domain to Active Directory, but does not actually change Active Directory. This lets you record the anticipated migration results in a log file and then, if potential conflicts are found, deal with those conflicts appropriately before actually performing the migration.
When identical names are detected during a dummy or actual migration, the conflict can be logged to a conflicts file. This file lists conflicts that have arisen during the migration of a particular map. If there was a conflict, the conflicts file lists the NIS entry being migrated and the existing entry in Active Directory. Consider the following two examples. In the first one, the conflict file states that there were no conflicts in the migration of the passwd file.
--------------
## Tue Jun 1 16:22:47 1999 : Conflicts between entries from map file 'passwd' and existing entries in Active Directory. ##
-------------
In the next example, the conflict file states that there was a conflict in the migration of the map. It lists the existing entry in Active Directory and the new entry being migrated.
-------------
## Tue Jun 1 16:22:52 1999 : Conflicts between entries from map file 'aliases' and existing entries in Active Directory. ##
EXISTS : having DN = 'CN=al1,CN=nisadmin,CN=DefaultMigrationContainer,DC=nis, DC=sfu,DC=nttest,DC=microsoft,DC=com'
OLD : staff:wnj,mosher,sam
NEW : staff:pradeep,peter,wjs
-------------
According to the file, the "staff" map already exists in Active Directory. The entry in Active Directory is different from the entry being added. In such a case, you can change the name of the alias "staff" either in Active Directory or in the map source file, that is, the plain text file from which the NIS map database is compiled. You can also preserve or replace the existing entries by force.
In addition to a conflict file, you can specify a log file where the entire migration steps will be logged. The following is a sample output of such a log file:
## Start of NIS to Active Directory migration of 'passwd' @ Tue Jun 1 16:26:21 1999 ##
MESSAGE : Migrating 'passwd' entries from UNIX NIS domain 'nis01' to Active Directory domain 'CorpDomain.'
SUCCESS : Migration of object 'nis0101' of class 'User' into 'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.
SUCCESS : Migration of object 'nis0102' of class 'User' into 'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.
## Start of NIS to Active Directory migration of 'passwd' @ Tue Jun 1 16:41:46 1999 ##
MESSAGE : Migrating 'passwd' entries from UNIX NIS domain 'conflicts' to Active Directory domain 'conflicts'.
CONFLICT : Can't migrate 'nis0101' to
'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'. An object having same attributes(name/uidNumber/gidNumber) exists at 'CN=nis0101,CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.
For more information on dealing with migration problems, see Troubleshooting.