SCCM updating wrong records

[Darren22]

Good morning, (Apologies for the lengthy issue)

We currently have two SCCMs feeding into our instance, SCCM2012 (windows 8.1) and SCCM2016 (Windows 10). 

We are trying to move away from any of our SCCMs creating assets. So the general rule is that when we purchase new laptops, we upload the basic machine data into ServiceNow, deploy them and then over night SCCM2016 comes in and updates the information (Operating system, Processor and Machine details). 

What I have noticed recently is that SCCM 2016 is not updating the correct record and seems to update a random machine originally created by SCCM2012. When checking the import set I am being told the following,

Message: SCCM import CI: L12345678 (16783829) matches L12345678 in the CMDB.

Source: Import transform entry script (This tells me it hasnt even checked the field it needs to coalesce against)

When I check the machine in the CMDB I noticed its correlation ID is the same as the one coming in 167833829 so assuming this is why its matched.

FIRST QUESTION: Can SCCM2016 really have created the machine with the same ID as the one in SCCM2012? I mean I guess its possible.

If the above is true then I need a different way to coalesce and so I decided to change the transform map to coalesce against Serial Number.

However when I set this to yes nothing changes. Its as though it ignores this command and still uses the entry script to coalesce against.

If I don't coalesce against Serial number and leave it as SyS_ID then the other answer result I get is

Message: SCCM import CI: L12345678 (16783829) matches L12345678 in the CMDB.

Source: Identifier: SCCM ID & Class Name

So again if I leave this as true and set it to ALSO use serial number to coalesce why does it not accept this.

SECOND QUESTION: How do I force the import to use Serial number instead of SyS_ID and ignore the entry script.

I'm really struggling with this and every day it goes on it gets worse so any help will be appreciated.

Are we really that unlucky that we have assets in each SCCM with the same resource ID?? Has anyone come up against this issue and what did you do to resolve it?

Happy to post scripts if people need to see them

[Fabian Kunzke]

No worries. This is one of the most overlooked CMDB features as most remember the Identification as a "discovery" feature.

You can use the same API btw. for all other cmdb imports: https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/product/configuration-management...

This allows you to manage identification parameters for all classes (your custom ones as well) in one place instead of splitting them to multiple transform maps.

Further, you can use this in request workflows, ui actions and many other cases.

It is a great feature to prevent duplicates in your cmdb.

[Darren22]

I found the rule!

I am going to set this to inactive and start testing the SCCM import to see if it resolves the issue.

Thank you so much for point me here. I will let you know how I get on.

One thing I will say... Today I have realized I know far less about CI's in ServiceNow than I thought I did.

Learning ahead for me. THANK YOU

[Fabian Kunzke]

You are not alone. Imagine how i felt, when i learned, that the IPs, Serial Numbers and applications are CMDB tables as well. The Configuration Management is far more powerful than most (including me) belive. Even without the eventmanagement, the suff you can do ootb with it is amazing.

I might write some stuff about it, when i have the time to do so.

Regards

Fabian

ps.: keep me updated on if it worked.

[ServiceNow Tec2 · Accepted solution]

This has been resolved by ServiceNow Technical Support. Please refer to KB0796021 for more information.

[Fabian Kunzke]

Uhhh... How does the IRE data source ruling fix an identification issue? With that solution ANY insert is prevented even IF it would be correct. This for sure fixes the symptom but not the underlying problem.