What trouble are you having?

NIS Domain Migration Wizard or command-line utility completes successfully, but no maps are added to Server for NIS.

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.

Migration conflicts occur even though test migration with "Do Not Migrate" option succeeded.

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.

A conflict occurs while trying to migrate more than one user with the same user identifier (UID).

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.

NIS Domain Migration Wizard or command-line utility reports Network Information Service (NIS) name conflicts with system account.

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.

The ypmatch utility on an HP-UX computer fails.

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.

The first request to Server for NIS fails.

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.

Objects migrated to nonstandard containers do not appear in Windows Active Directory Users and Computers.

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

Solution:  On the View menu, click Advanced Features.

After upgrading to version 3.0, netgroup data no longer appears in Active Directory.

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.

The ypcat utility sometimes displays incorrect passwd information, but ypmatch provides accurate information.

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.

Users with new Windows accounts created by NIS migration cannot log on to Windows and cannot log on NIS client computers.

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.

A user account disabled in Active Directory is not also disabled on UNIX hosts.

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).