- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 04:19 AM
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
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2020 02:24 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2022 09:34 AM
This article has been removed. The docs link above is not longer valid. Is there an update to this issue as we are experiencing it on San Diego.
Clint
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2022 09:35 AM
This article has been removed. The docs link above is not longer valid. Is there an update to this issue as we are experiencing it on San Diego?
Clint
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-28-2022 11:29 PM
Hi Clint
We are experiencing somewhat similar issue. Were you able to solve this?
Regards,
Himanshu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-01-2022 05:34 AM
Himanshu,
No, we have not. But I suspect that when we updated to the new version of SCCM on new servers, no data was brought over. I think the transform script in the SCCM transform map is coalescing on the sccm field of resource ID. This field is only numbers and it is possible that the new SCCM server is randomly using some of the same resource ID's that already have related records (by resource ID) in Service Now. The orifginal records are overwritten, but history is still indicated in the activity feed, and the old asset data is overwritten. We are having our partner look at this script and possibly change the colescing field to the serial number field and then updating the old asset records with the old information for tracking purposes.
Clint