Cause:  The Do not migrate (log only) option was selected.

Solution:  Because migration is irreversible, the Do not migrate (log only) option is the default. You can override the default when running the wizard by selecting either Overwrite or Preserve on the Manage Migration Conflicts page of the NIS Data Migration Wizard. To override the default when you are running the command-line utility to migrate instead (Nis2ad.exe), specify the -m option on the command line.

Cause:  If data conflicts in the Network Information Service (NIS) maps you are migrating, the conflict might not be reported until an actual migration is complete, because Server for NIS reports only conflicts between NIS maps and Active Directory.

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

Cause:  The NIS Data Migration Wizard cannot migrate users that have the same UID. Only the first user is 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-based account, and then remigrate the entry by using the nis2ad –r yes command-line option.

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

Solution:  Convert keys to lower case 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:  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 refresh interval between updates to the map cache, or check that the updates have been cached immediately upon making changes in Active Directory. For more information, see Changing the frequency of map updates and Propagate changed maps now.

Cause:  To avoid exposing new accounts to misuse, the migration wizard disables the new accounts.

Solution:  After completing migration, enable new accounts only when users are ready to use them. For security reasons, it is recommended that you 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 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 by 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).

Cause:  Possible configuration errors on the client computer.

Solution:  Perform the following troubleshooting steps for the indicated client operating system.

• Ensure that the Windows-based computer that is running Server for NIS is added to the /etc/hosts file on the Solaris client. Then run the ypwhich command on the client and check that it shows the correct Windows-based computer.
  
  
• Ensure that the /etc/nsswitch.conf file contains an entry similar to the following:
  
  passwd:   files [NOTFOUND=continue] nis
  
  
• Ensure that the user is not listed in the local passwd file.
  
  
• Add the following to the end of the /etc/passwd file on the client computer:
  
  +::::::
  
  
• Ensure that shadow files, if any, are also migrated to Server for NIS.
  
  
• Ensure that the ypcat password command does not show X in the user's password field.
  
  
• Ensure that the file /var/yp/securenets is configured to allow authentication from the client computer.
  
  

• Ensure that the Windows server running Server for NIS has been added to the /etc/hosts file on the client computer and that the ypwhich command on the client computer correctly shows the name of the Windows-based computer.
  
  
• Ensure that the USENIS entry in the /etc/sysconfig/authconfig is set to USENIS=yes.
  
  
• Ensure that the nsswitch.conf file is properly configured.