No. The solution is not yet been applied. It still the same.
This is causing a major problem in the TP now, as the Import is not working from 17th of this month and we cannot see any new users imported to the TP and we cannot raise the ticket in the TP by selecting their names.
Can anyone please help on this matter? any solutions to fix?
Let us know, ASAP... (or some please respond to this), atleast we come to know thats someone's watching us.
Presumably you've logged an Incident with Avocent Support on this one and stressed the urgency of a fix/workaround?
yes, few minutes ago.
I get the same error but it doesn't stop the user import progressing, from what I can tell its caused by trying to import end users who already exist as analyst users, therefore causing a mismatch. I run my user import from a staging table database so I can apply a view on the table to exclude analysts, alternatively a query filter could be used to do the same.
Hope this helps.
I'm sorry you didn't get a response to your original post, I hope you get the advice you need from your Support incident. On initial look at the log entry you put in your post I'd say your end user import has found a record in your import source with the same username as a user that already exists in Service Desk as an Analyst.
Say a user EMP01 is imported for the first time and the import happens successfully.
Now say, the import executes second day... EMP01 is already exists and EMP02 is new one.... so EMP01 data must be updated and EMP02 data must be inserted.
If the TP is trying to insert EMP01 again, then...?
I am not saying it stopping from progressing...
Actually the schedular did not execute at all from 17th of this month... so when it does not execute it does not thorws error neither it makes an entry in log file/s
We do not use staging database here... its a simple straigt LDAP connection... Its just as simple...
If New user
I am not sure what is the cause.
Thanks Anthony for reply.
Say a user E1 is added to the TP database via imort and he is moved from End User to Analyst.
When the Import runs again... E1 is not in End User but Analyst.... and definitely as you all said, this error/warning is written to the log file...
so how do you check this and stop throwing error for all time sake?
We do not have staging database, as we use is direct connection to the Active Directory and fetch the users....
But, if you map the key on NAME field, that is where it supposed to work on condition depending on that it update or insert will be choosen.
Hope to see some help? (is there something we have to change in configuration?)
I think this comes back to putting some type of filter on the import so you don't get the errors. In my schedule I created two imports, one for the analyst users and one for the end users, the distinguishing criteria for the filter being the departmental value, I haven't done a direct import from AD before but I'm sure you could put something in place which would achieve the same result. Even if there isn't a straightforward value to use, you could explicity list your analyst users in the filter.
If we use the filter or modify the existing filter...
Say now from import, 5 users are added to the database, so next time the import exeucutes I need to modify the filter not to pick these users by adding there alias or AD id in to the filter criteria?
The only users you need to exclude are your analysts users, my filter excludes certain departments and also some named individuals to cover all my analysts.
I guess this is the only filter with longest criteria you have got in there.
This is fine for some level with analyst I agree.
But from the End User import... we have like 7 end user imports which covers like different regions all over, new Users are added every week.
So every time all these imports execute, it shows one or the other errors in the log.. could not update the phone, email cannot be mapped...System.Analyst != System.EndUser...
Analyst are added/removed frequently... so i cannot go and modify all these filters wherever the change takes place... its lot of work and it does not look professional. If you have fixed list and change happens like say once in a year or twice? that fine... but no for me...
I need consistant solution where this fixes properly like if the user is in the database and is_deleted is false and account_lock is false, then just add the new users, if not the update the existing with the new data if anything changed in the AD on any of each profile. So we do not have to worry about the users at all.
We actually disable and lock the a/c when the user becomes x, when next import works this particluar user is not updated at all, I have to set it locked = true in dataase and soft delete them.
I see there are some issues in the core of the import, it needs a lot of fine tuning.
Thank you so much Anthony for your reply. I am sure that I am not going in right direction, at least I feel, TP needs to come up with a import patchor something