I'm looking to see if anyone can help confirm if what we want to accomplish is possible or not. Logically I would expect to be able to maintain information about Analyst that is sourced from AD, but I am not having success finding the solution.
Background:
* We implemented (at go-live - as newbies, with help from our consultant) an interface from our Active Directory to the LANDesk user object.
* We use the interface still - and when we have an LDSD Analyst we wait for the 1st interface to run, and then convert the User to an Analyst and all is well so to speak.
* The Interface maps a number of data elements that are of importance to all users AND Analyst - and that can change over time (Title, Phone Number, Manager - for Service Request approvals, etc.). Although the User Interface is an "Import" - it clearly works as both an Import (New) and Update function. That is - changed AD data like a new manager will be updated for existing Users - with matching as you would expect on the "Key" that is defined in the mapping (in our case the UPN - but that is irrelevant).
Now - for the longest time we have "seen" that once a User is changed to an Analyst the User Import no longer processes any updates for that "person" - we get the error that I can find all over the community "Object Type Missmatch. System.Analyst != System.EndUser" - and none of the AD data is updated for that user. In our case (and I suspect other companies) the Analyst has a relationship in LDSD that uses the same data as a normal User (they have PC's for example - and the data maintained for the CI assignment is important to be up to date. Or - they also process Service requests that get approved by their Manager).
The volume of these Analyst (~100) together with the rate of change in any of 10-15 HR data Elements we use in the system has gotten to the point it is impossible to try and manually keep the Analyst accounts up to date. We had just assumed that Analyst could never be interfaced - because of the error we get about the Object Type mismatch. But then in frustration I wanted to look if there was any way to disable this limitation - and I stumbled over the part I was missing and thought perhaps there was an answer at hand. While the "Data Connection" only has users - the "Data Import" is configured to import to the target "Module: System - Business Object: Users" - this was the clue I needed. Sure enough - I just created a new Import - and changed the Target business Object to be "Analyst". I was quite sure I had the answer - and ran the interface ....
However, unlike the User import, every single record failed (I had not yet made changes to have an Import that found only analyst - I was expecting to break things in my test system for normal users until I proved the solution). So - even for my existing Analyst - they do not interface (update) - they all fail with a duplicate key error ("Cannot insert duplicate key row in object 'dbo.tps_user'"). Of course this is true - the row already exists - so an insert would fail.
But - this is true of the User Import as well. Every day that interface runs - and the records update but do not error as duplicates. I am looking to see how I accomplish the same for Analyst records - where I can process the updated AD information into the Analyst detail (in reality they are 2 different Objects in LDSD - but 1 table tps_user). I know there are triggers on the tps_user table - but these don't appear to have anything to do with the situation. Can anyone point me in a direction or tell me if this is even a possibility. I can't imagine why anyone would want to avoid mapping changed AD information only to Analyst - yet I can't find any such discussion.
I do of course have the last resort to rewrite my interface from our HR system to AD to also interface to LDSD database directly. This seems silly as I have a functional interface for all by 100 (of 5,000) people - but I can't seem to find another solution.
Any ideas? And thanks in advance - and sorry for the long winded detail!
Terry