User records not updating through Scheduled LDAP Import

[harun_isakovic]

Hello Community,

I'm having an issue with my Scheduled LDAP Import, but I cannot figure out why its not updating all users, it updates majority but then there is some that it does not for whatever reason. I was monitoring this specific user (we will name him David W.) and his company is not updating on his LDAP record the company is "A" but on SN its "B".

I can see the data gets loaded into the staging table and I find David W. record there with the latest data from LDAP but for some reason this data does not get updated in his user record in SN.
If I go into the Import Log table and find the error record for this user all that says is "Error during insert of sys_user (David W.)

In the Scheduled Import set the "Run as" was empty even when it was working but, now Ive put a user in that field that has the "import_admin" role but it still does not work.

Coalesce on the transform map is set to employee_number, but this field is hidden by an ACL that restricts view only to security_admin role. 

There is also a field on the user record "Refreshed from LDAP" which tells me when this user was last refreshed and its pretty much same date for 2 weeks now.

Would appreciate some help with this!
Thanks in advance.

[Allen Andreas]

The point I'm saying and that you know...is that this user record already exist. So it should NOT be trying to insert, at all. Sure, deleting that user record may allow it to insert...this time...but the very next time there's an update, you'll be back at this issue again.

It is trying to insert, when it shouldn't. It is trying to insert...because it can't see the field you are coalescing on has ACL(s) only allowing the elevated role of "security_admin" see it. If you were to remove that requirement, replace "security_admin" with just admin OR disable those ACL(s)...I suspect you'd be fine with the load...that it would see the existing user, not try to insert a new one, but instead update the one that is there.

Like....this isn't an edge case issue happening right? It's happening for ANY user who needs/should get an update to their record. This will keep happening and you can't keep "deleting" the user records each time.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[harun_isakovic]

Its only failing to insert this specific user on about 70 other users its just failing to update. I have disabled the ACL preventing read for the employee_number. And there is not any other ACLs that would be blocking these fields that need to be updated by the LDAP.

[Allen Andreas]

Hi,

From your original post, it sounded like this user "David W." was already within ServiceNow. Now, you're saying he's not in ServiceNow and he does need insert? You originally said:

I was monitoring this specific user (we will name him David W.) and his company is not updating on his LDAP record the company is "A" but on SN its "B"....I can see the data gets loaded into the staging table and I find David W. record there with the latest data from LDAP but for some reason this data does not get updated in his user record in SN.

Unfortunately, at this point, I'm not sure what else to say because we don't know how your environment is set up and I'm not sure if this user actually exists or not as you're now saying he doesn't exist in SN. I can only explain the error you are seeing and provide possible troubleshooting points. Did you see if the system log also said anything?

[harun_isakovic]

Hi,

He does exist in the system and what I meant above is that only for this user its showing "Failing to insert" error, but others are just showing "Failing to update".

I checked out randomly about 10 records from these "Failing to update" and they were all inactive/locked out, so it would make sense why they are failing to update.

But for David W specifically no clue, like I said the target record for him was empty.
Nothing in system log and in the import log its only this already mentioned "Failing to insert" even though he does not need to be inserted because he exists in the system.

So data that gets loaded to that staging table also comes to the instance from LDAP correct its just that from staging table to the actual user table is where the issue comes because it refuses to apply those updates.

[rahulpandey]

Hi Harun,

This is a documented( KB0788959 ) error message for below reasons

Cause

1.  The sys_user record already exist in ServiceNow.
2. When importing the sys_user record from AD it will be Coalesced by the objectGUID.  The objectGUID (Global Unique Identifier) is a 128 bit hexadecimal value, that helps uniquely identify an object in a forest.
3. If you look at the objectGUID for the import it will be different from that on the existing sys_user objectGUID.
4. Since the objectGUID are different the record will try to be inserted into ServiceNow.  This insert will fail because ServiceNow sys_user (user_name) needs to be unique.
5. ServiceNow will prevent the insertion of the record because the SAMACCOUNTNAME is mapped to the ServiceNow user_name.  ServiceNow does not allow  duplicate username in sys_user record.

Resolution

You can copy the new objectGUID to the existing sys_user record, or delete the existing sys_user record.  The next time the AD import runs it will because to create/update the record successfully.