SCCM Resource ID Creates sys_object_source Entry Against cmdb_software_instance Instead of Computer

[BharatC]

I'm facing an issue with SCCM integration and CMDB identification.

We observed that some SCCM-discovered servers were not being created as Computer/Windows Server CIs. After investigation, we found existing entries in the sys_object_source table where the SCCM Resource ID was already mapped to a cmdb_software_instance record instead of a Computer CI.

As a workaround, we deleted the affected sys_object_source records and reran the SCCM import. The missing Windows Server CIs were then created successfully.

However, the issue continues to occur for newly discovered SCCM devices:

A new SCCM device is imported.
A sys_object_source record is created.
The target_sys_id points to a cmdb_software_instance record.
No corresponding Computer/Windows Server CI is created.

hi @Vishnu-K  pls guide me on fixing this issue, thanks

[Vishnu-K]

Hi @BharatC ,

So the core issue here is how sys_object_source works with IRE and SG-SCCM, and
there's a well-documented fix for this.

When SG-SCCM runs, IRE writes an entry into sys_object_source linking the SCCM
resource ID (combined with your connection alias sys_id) to a CI's sys_id via the
target_sys_id field. On every subsequent run, IRE hits sys_object_source first as
a shortcut and goes straight to whatever target_sys_id is stored there - completely
bypassing your identification rules. So if that entry is pointing to the wrong CI
or a stale record, IRE will keep updating the wrong one every single time.

The fix is straightforward. Either delete the bad sys_object_source entries so IRE
falls back to your identification rules and re-identifies the CI cleanly on the next
run, or update the target_sys_id to point to the correct CI. Deleting is generally
the safer option:

// Delete bad entries

var gr = new GlideRecord('sys_object_source');
gr.addQuery('name', 'SOURCE_NAME'); 
gr.addQuery('target_sys_id', 'BAD_CI');
gr.query();
while (gr.next()) {
gr.deleteRecord();
}

After the cleanup, the next SG-SCCM run will go through your identification rules
for cmdb_ci_computer (serial number, name etc.) and write a fresh correct entry back
into sys_object_source automatically.

One thing worth knowing if you're on SG-SCCM 3.x - the source native key stored in
sys_object_source is no longer just the SCCM resource ID. It's a concatenation of
the resource ID and the connection alias sys_id in ServiceNow. So when you're
querying sys_object_source to find the bad entries, filter by the source name field
rather than trying to match on the native key directly, it's much easier to find
what you're looking for that way.

Before re-running the integration after cleanup, I'd also recommend enabling debug
logging on identification_engine under System Diagnostics > Debug Log Levels so you
can confirm IRE is identifying and writing the entries correctly on the next pass.

Hope this helps,

If it helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu

[BharatC]

Hi @Vishnu-K ,

is there any automation  for all new CI creation, So when a New CI is created in SCCM after that we pull those CI's in servicenow using service graph connector then it should automatically map to cmdb Computer table not to sys_object_source table. 

[Vishnu-K]

Hey, just to clear up a small misunderstanding here - sys_object_source is not a

destination or a target table for your CIs. It never stores the CI itself. It's a

metadata table that IRE uses internally to track which source owns which CI and to

speed up subsequent runs. Think of it as a lookup cache that sits behind the scenes.

When SG-SCCM pulls a new CI from SCCM and IRE processes it, the CI gets created in

cmdb_ci_computer (or the appropriate child class) as you'd expect. At the same time

IRE writes a separate entry into sys_object_source that simply records "this SCCM

resource ID maps to this CI's sys_id". That entry is what IRE uses on the next run

to skip re-identification and go straight to the right record. So both things happen

together - the CI lands in cmdb_ci_computer AND sys_object_source gets an entry for

it. It's not one or the other.

To answer your actual question about automation - yes, this is already handled

automatically by the SG-SCCM integration. You don't need to build anything custom.

When SG-SCCM runs on its schedule it pulls new devices from SCCM, IRE identifies

them, creates the CI in cmdb_ci_computer, and writes the sys_object_source entry

all in one flow. If you're seeing new SCCM devices not showing up in cmdb_ci_computer

the issue is usually either the identification rule for cmdb_ci_computer not matching

correctly, the device landing in cmdb_ire_partial_payloads due to missing required

attributes, or the SG-SCCM schedule not being active. Those would be the first three

things to check.

Hope this helps,

If it helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu