Need help with duplicate ID's

[smithl]

In our development instance, I rerouted the ldap import to pull from the physicalOfficeDeliveryName and point that to the location field in ServiceNow. It is NOT a field that coelesces; however the objectGUID field is. Everything worked beautifully in development (isn't that how it always works?). I completed the update set and exported it into production. Production didn't pull the new location immediately, so I went into the LDAP import chart and changed the location title (as done originally in dev), and woolah! Production started pulling the correct field for location; however, every user has a duplicate record now. The complete record, with email, phone, userID, and location is not the original record. The original records are missing most everything, but a phone number. I've checked development, and this issue doesn't exist there so I'm at a loss as to how to fix this. Can anyone help!?

[bernyalvarado]

Hi Latanna, i just have to tell you... you're not alone . I'm sure that almost everybody that has some LDAP experience has gone in the past through something like that.

The key on this case is whether the original user records in production are referenced by other items (incident, change requests, tasks, etc...). I will expect this to be the case unless you're not LIVE yet.

Often this procedure is done on the following way:

a) The first load is done by coalesce on the user_name (user id) or which ever field that more accurately can related the current production users to the ones existing in LDAP. As part of this first load, you pull the objectGUID to make it part of the user record in ServiceNow. Once the association is done, the coalesce can then be switched to the objectGUID.

I don't quite understand all the details of your scenario but what I will recommend you doing is to bring back to a good state the field that most accuretely associate the production users to the LDAP. This needs to occur for all of your original user records. Once you do that, then you can proceed on making a load a suggested in point a) where the first load associates first the records, and you then you switch for future/sustaining load coalesce to the objectGUID.

I hope this is helpful!

Thanks,

Berny

[bernyalvarado]

I should have added, try this clean up method first in Development with a couple of users. Make sure you cover all angels of it. Also, if you turn out to have to do a bulk update of your user records for a clean up, I also recommend you first run it through a couple of test records and you run the bulk update as a on demand scheduled job. Often that's sort of a best practice when needing to update a big group of records.

Best of the lucks!

Thanks,

Berny

[Deepak Ingale1]

Hi Latanna,

I recently implemented LDAP integration where we imported location details along with user object from LDAP and it went quite smooth.

First question, are you using transform map to import location data as well while importing user object or you are just using mapping field mechanism to map the location field on user table to that with location attribute coming from LDAP.

If you are using field mechanism, to map , then it is not the best way to do it. Because location is a 'Reference' type field and should not me mapped while importing user object from LDAP, rather writing down 'onBefore' transform map script with GlideRecord mechanism should be the way to load or set location details.

[smithl]

Hello Deepak!

We run 4 ldap imports (users, groups, resources, admins) based off AD containers. These four are imported and then transformed. I do see several transform maps that take the data from the imports and place them into their tables. Location has it's own (which is working). The issue that I face is duplicate ID's, with the same objectGUIDs (doesn't make sense), and roles being stripped from the duplicate records (which are the only working records at this point). So I am going into the system daily and re-adding roles for those who work in IT (oddly, not everyone in IT was impacted), and when LDAP runs, it strips those users back out.