/build/static/layout/Breadcrumb_cap_w.png

What would cause duplicate records after LDAP scheduled import for users?

What would cause duplicate records after LDAP scheduled import for users? We set up the import the exact same way as we did the initial import and it duplicated user records.


3 Comments   [ + ] Show comments
  • When you jump into the USER table in the database (if you can?) are the records identical there as well (aside from ID?) - Wildwolfay 11 years ago
  • Cannot get there :( - ajfee 11 years ago
  • To connect to the database, check the instructions here:

    http://www.kace.com/support/resources/kb/article/How-to-connect-to-the-K1000-appliance-database-using?action=artikel&cat=9&id=10&artlang=en - grayematter 11 years ago

Answers (1)

Posted by: brucegoose03 11 years ago
5th Degree Black Belt
0

There are 2 causes to this that I have seen:

 

  1. End user logs in before import happens
  2. 2 imports happening at the same time, and user exists i both
1. The first one is a simple fix; whenever you have new users added to your environment, make sure to not have them log in to the appliance until you have a chance to import them.
 
This really only matters if your LDAP import schedule requied mapped fields (the 3 in red, username,email,objectguid) are mapped to anything other than what the default is (ldapui,mail,samaccountname). 
For example, some customers use their email address as their username instead of samaccount name. 
 
2. This ones a little trickier. Download your server troubleshooting logs and look in the cron_server_error log for something like this:
 
[2013-09-14 08:00:21 -0700] KCronServer[78081]: running /kbox/bin/schedule_userimport.php --id=3 --db=1
[2013-09-14 08:00:21 -0700] KCronServer[78083]: running /kbox/bin/schedule_userimport.php --id=4 --db=1
[2013-09-14 08:30:14 -0700] KCronServer[88380]: running /kbox/bin/schedule_userimport.php --id=2 --db=1
kbox#

This issue I worked on had really only one schedule set in the UI, but somehow there were 2 others that were running that weren't suppose to so we had to remove those via root access. 

To go a step further, you can see what imports are setup in teh DB:
select * from USERIMPORT_SCHEDULE 

Then see where they are set in IM_CRON. Replace X with the ID you want to look at:
select * from IM_CRON where ID = X
 

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ