Share via

Resolving migration conflicts

  • Article

Applies To: Windows Server 2003 R2

Resolving migration conflicts

During migration, conflicts may occur when Server for NIS attempts to merge incoming user accounts, groups, and computer names into classes that already exist in Active Directory. 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 of johnwood. If there is no existing user with a user name of johnwood, 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 Data 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 johnwood in an NIS domain named mktg, and a user with the same name was previously migrated from another NIS domain, then the user name of johnwood in the mktg domain will be changed to mktg_u_johnwood 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 Data Migration wizard performs what is known as a dummy migration. During this process, the 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 conflicts 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 conflicts 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 conflicts 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 about dealing with migration problems, see Server for NIS Troubleshooting.