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]

Hello,

To cite the documentation:

The SCCM integration uses CI identification to update CIs created from data imported from SCCM with a resource ID. The Hardware Rule identifier returns the resource ID of a computer from SCCM and stores it in the Source [sys_object_source] table. When resource IDs are first imported, either from SCCM or Discovery, the [sys_object_source] table is populated with IDs for each CI it identifies. In subsequent imports, if an incoming ID matches that of an existing CI, IRE (Identification and Reconciliation Engine) updates the information for that CI in the CMDB. If the incoming resource ID does not match that of an existing CI, IRE creates a new CI and populates it with the resource ID.

What you will need to do is modify your cmdb identifiers for the hardware classes (in your case the cmdb_ci_computer class). Ootb these are set to first check for the correlation_id. Deactivate that first identifier action and it will start with the next one (which is the serial_number(s) check). You should be fine after that adjustment. (Link to the documentation: https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/product/configuration-management...)

Two answer your question: Since the correlation_id is set to any customer related value it is indeed possible that two systems fill this value with arbitrary values which by chance match. This is also the reason why i dislike using this identifier for hardware (as the serial numbers should be accurate). In return this also makes it possible, although highly unlikely, to result in your case.

Regards

Fabian

[Darren22]

Thank you so much for the reply Fabian.

The change you have suggested to make sounds like what I am looking for. Can I ask where this change is made?

Does it sit under the first initial script?

Or is it the script that is used within the field maps that is then used to coalesce on.

Again, thank you so much for your help on this. I am struggling to get help on the matter and I am the only person looking after our instance.

[Fabian Kunzke]

Hello,

Neither of them. The Identifiers are part of the reconciliation within the cmdb. Go to "CI Class Manager" under the menu "Configuration". This is the place where all configuratoin for your cmdb can be done. Then search for "cmdb_ci_hardware". This will open the ci class manager for the Hardware class. Then click on "Identification rule". This will list all identification entries. The first one should be "correlation id". Click on it and deactivate it.

If this entry does not show up, your issue may lay somewhere else. If so, then the next place to check would be the transform maps.

Regards

Fabian

[Darren22]

Well I was way off!

Thank you so much. I will check in this area shortly and come back to you. Fingers crossed its there.