There are some articles already which should help with this - one article has videos as an extra bonus!
Creatingt connections to LDMS and setting up import mappings is included in this article:
Associating imported CIs with users:
I hope this helps you.
I did this mapping that Craig refers too but if gives me a bunch of errors:
Target Key Attribute Value cannot be null User Configuration Item.User
11/15/2011 5:09:16 PM : Could not find Related Object User.Title =
Then after the = it gives the fully qualified path of the name CN=blah,DC=this....
Has anyone made this work?
Depending on the source data you've imported from your management tool, the user informaiton may be stored as the LDAP distinguished name which won't correctly match the User.Name field as Craig has used and given the error you've descrivbed it certainly sounds like this is the case. To get around this I would suggest creating a new field on the user object called "LDAP Dist Name" or something similar then map the LDAP distinguished name to this field in your User Imports.
You can then edit your mapping for the User>CI linking and map the Primary Owner data to this new "LDAP Dist Name" field and set it as the target key attribute and it should import fine.
This is great advice!
I just tried this but it is giving me the same result.
11/16/2011 10:48:09 AM : Target Key Attribute Value cannot be null User Configuration Item.User
11/16/2011 10:48:09 AM : Could not find Related Object User.LDAP Dist Name =
It doesn't look like everyone so does this mean it can't find the account? Also, where would I go to verify that this actually is working?
You can check if it is working for any user by opening a user account and clicking the Add/Remove Configuration Items and it should list linked CI's there, or alternatively write a query against the User COnfiguration items object.
The error "11/16/2011 10:48:09 AM : Target Key Attribute Value cannot be null User Configuration Item.User" would indicate one of the imported CI's has a null value set for the LDAP Dist. Name attribute so it cannot link to any user, hence you get this error. If you write a query against Config Item and add a condition to show all CI's where this field is NULL it should help identify the problem CI's.
There are no associations made. I get over 500 of these errors so I think something is mapped wrong. Does "Title" need to be mapped to from something since it's a primary value for "User"?
I'm at a loss here. This is one of my last hurdles to jump.
You only need to map a minimum of one field in a data import, and set this as a Target Key Attribute. It is irrelevant which field you use but it should be unique. So first step, lets check a few things-
If you check all four of these items and the answer is Yes to all four then something odd is going on, but I would suspect that at least of these has been missed, or possible point 1 would indicate the information about the primary owner in your CI source doesn't match the LDAP Dist. Name in your User source resulting in a mismatch.
Have you made this happen in your environment? Do you have some snaps you can provide.
The only thing that might be weird is the matching of the LDAP name. Even those it all looks correct, it's possible there is a rouge space or something that I'm not seeing. This shouldn't be this hard. lol
Please see the attached for the way I have it mapped. It looks correct so there must be some type of naming mismatch.
I have set this up a couple of times for customers but I don't have any snaps to hand sorry. Your mappings look fine, however the only difference I can see between yours and mine is that I don't map anything on the main object, only the related objects, so that may be something you could try.
If that fails I would suggest raising this with support as it sounds like something very odd is happening.
EDIT: You could try mapping Login Name from the data source to Name on User instead, as Login Name is the LDAP login used to login to the machine so this may work for you instead of LDAP distinguished name.
I tried the mapping you suggested in the edit and got a new result... data!
However, it doesn show the actual user and Config Item. Is this normal if you map a level down from the main object?
Those errors are normal, because in most cases not every item in the source will have a Primary Owner/Login Name so you will get the occasional one like this. What you can do with those errors is track down the CI's and look at updating the data manually in the source, but that is another discussion Congratulations on getting this working.