Troubleshooting

Cause:  The "Do Not Migrate" option was in effect.

Solution:  Because migration is irreversible, the "Do Not Migrate" option is the default. To override the default when running the wizard, select either Overwrite existing entry or Preserve data. To override the default when running the command-line utility (Nis2ad.exe), specify the -m argument on the command line.

Cause:  If data in the Network Information Service (NIS) maps being migrated conflicts, the conflict might not be reported until the maps are actually migrated because only conflicts between NIS maps and Active Directory are reported.

Solution:  Resolve the conflicts in the original NIS maps and then migrate the NIS data that was not migrated using the nis2ad –r yes option.

Cause:  The NIS Migration Wizard cannot migrate users that have the same UID. Only the first user will be successfully migrated.

Solution:  Make sure all users have unique UIDs before migrating NIS maps.

Cause:  A user name in NIS is identical to a reserved Windows account name. Reserved account names include such names as Network, System, Users, and Computers.

Solution:  Resolve the conflict by renaming the UNIX account, and then remigrate the entry.

Cause:  A map contains keys in mixed case. HP-UX converts all keys to lowercase before sending the NIS request. This is an issue with HP-UX that is beyond the control of Server for NIS.

Solution:  Convert keys to lowercase before migrating them.

Cause:  If the number of objects migrated to Server for NIS was very large, Server for NIS can take a long time to build the map cache.

Solution:  Make the request again after waiting 30 minutes or more. Subsequent requests might succeed.

Cause:  Active Directory Users and Computers does not display nonstandard containers by default.

Solution:  On the View menu, click Advanced Features.

Cause:  Windows Services for UNIX does not preserve netgroup data when upgrading Active Directory schema.

Solution:  Use the Server for NIS Migration Wizard to migrate the netgroup data from the map source file originally used to migrate the data.

Cause:  Server for NIS data has not yet updated the map cache after data in Active Directory has changed. The ypcat utility takes its information from this cache; the ypmatch utility takes its information directly from Active Directory.

Solution:  Decrease the interval between map updates, or check updates immediately upon making changes in Active directory. For more information, see To change frequency of map updates to UNIX subordinate (slave) NIS servers and To propagate changed maps now.

Cause:  To avoid exposing new accounts to misuse, the Migration Wizard sets the password of the new accounts to a random value. This password then is propagated to NIS clients.

Solution:  Immediately after completing migration, change the password on all newly created Windows user accounts to temporary values. Notify users of the temporary passwords and instruct them to change their Windows passwords as soon as possible. Inform them of how often map changes are propagated (see Sending periodic map updates to subordinate (slave) NIS servers) so they will know when they can expect their UNIX passwords to be updated.

Cause:  Windows and UNIX accounts must be disabled separately because the mechanism for doing so is fundamentally different, and the method for disabling UNIX accounts differs based on system version and administrator preference.

Solution:  After disabling an account using Active Directory Users and Groups, you must also disable or lock the corresponding UNIX account by the usual means (such as by changing the password to a value unknown to the user, by adding a special character to the user's password in the passwd file, by changing the account's login shell, or all three).