Not all users import to iPrint Appliance

Most users import from the source directory to the iPrint Appliance's directory.  However, some do not. Investigating the differences between importing and not importing users within the source directory doesn't reveal an explanation as to why some import and some don't.

Workaround:
Force an invalid foreignName value within the MySQL database for the affected user or users.  This will cause the User Import process to delete the user from the MySQL database the next the LDAP import is executed. Once you run the LDAP import a 2nd time, the user will import with the correct format for the foreignName and populated ldapGuid attribute.

1. Set invalid foreignName value for the affected user:

This example assumes the id for the problem user is 58.  To find the id number for the user, see the commands in the Additional Information section of this TID.

mysql -uroot -proot
use sitescape;
update SS_Principals set foreignName=58 where id=58;
commit;

2. Run User Import two times

The first will delete the user.  The second time will import the user.

3. Sync the MySQL database to the iPrint Appliance's copy of eDirectory:

python /opt/novell/iprintmobile/python/migrate/migrateusers.pyc

For reasons not yet known, the users which don't import have a blank value for the ldapGuid attribute within the iPrint Appliance's MySQL user database.  For those same users, the format for the foreignName attribute within the MySQL user database is not correct.  The foreignName attribute format should look like this:

cn=userjoe,ou=acct,o=mycompany

However, for the non-importing users, the foreignName attribute format looks like this:

userjoe

When the ldapGuid is blank and the foreignName attribute format is wrong, the user fails to import from the MySQL user database to the iPrint Appliance's copy of eDirectory. 

To display all user ldapGuid and foreignName attributes:
These commands are not optimal if thousands of users are being imported.

mysql -uroot -proot
use sitescape;
select id,name,disabled,ldapGuid,foreignName from SS_Principals where deleted=0;

Determine which users have a blank value for the ldapGuid attribute.

mysql -uroot -proot
use sitescape;
select id, name, lastName, disabled, foreignName, ldapGuid from SS_Principals where deleted = '0' and type = 'user' and ldapGuid='';

Note the end of this command has two single quotes.  Not double quotes.

To turn on debug logging:

1. Open /opt/novell/filr/apache-tomcat/conf/log4j.properties
2. Remove the # from the following line:
• #log4j.category.org.kablink.teaming.module.authentication=DEBUG
• This enables logging for authenticate for both LDAP imported users and users locally created on the Appliance. It also logs the LDAP sync process.
3. Remove the # from the following line:
• log4j.category.org.kablink.teaming.gwt.server.LdapBrowser.LdapBrowserHelper=DEBUG
• This enables extra logging for LDAP sync process.
4. Save the changes to the log4j.properties file
5. Restart Filr:
• rcfilr restart

Log file locations:

/opt/novell/filr/apache-tomcat/logs/catalina.out
/var/opt/novell/log/iprintmobile/ipmigrate.log
/var/opt/novell/tomcat-filr/logs/appserver.log