Windows Server CI not getting created in CMDB; SCCM Resource ID mapped to Software Instance Table

[pallavishah]

Hello Community,
I am troubleshooting an issue where SCCM data is successfully landing in the staging/import tables, but the expected Windows Server CI is not being created in CMDB.
During investigation, I found that the SCCM Resource ID is present in the sys_object_source table. However, the target_sys_id associated with that source record points to a record in the cmdb_software_instance table instead of a cmdb_ci_computer or cmdb_ci_win_server record.
Because of this mapping, the Windows Server CI is not being created as expected.
My questions are:
Can an existing sys_object_source mapping cause IRE to skip creation of a Computer/Windows Server CI?
Why would an SCCM Resource ID be associated with a Software Instance CI instead of a Computer CI?
What is the recommended way to correct this mapping and allow IRE to create the appropriate Windows Server CI?
Are there any IRE or SCCM troubleshooting steps I should review to determine why the server CI is not being created?
Any guidance would be appreciated.
Thank you.

[Vishnu-K]

hi @pallavishah ,

Yes, sys_object_source WILL cause IRE to skip CI creation

This is a known behavior and it's working exactly as designed  just pointed at the wrong record.

When IRE processes incoming SCCM data, one of the first things it does is check the sys_object_source
table to see if that source identifier (your SCCM Resource ID) has already been mapped to an existing CI.
If it finds a match, it skips creation entirely and tries to update whatever target_sys_id is stored there.
Since yours is pointing to a cmdb_software_instance record, IRE thinks it already "knows" this device and
just moves on which is why your Windows Server CI never gets created.

Why is the SCCM Resource ID mapped to a Software Instance?

This kind of mismatch usually happens for a few reasons. At some point, a software instance CI was
accidentally imported with the same SCCM Resource ID and the mapping got locked in. It could also be
that a previous import or integration (maybe a discovery run or a manual data load) created the
sys_object_source entry against the wrong CI class. Another possibility is a class mismatch during
an earlier IRE identification run where the payload didn't have enough attributes to correctly resolve
to cmdb_ci_win_server, so it fell back or matched incorrectly.

How to fix it : Recommended Approach

First, go to the sys_object_source table and filter by the SCCM Resource ID in question. Find the
record where source_name = SCCM (or whatever your source name is) and the target_sys_id is pointing
to the software instance.

Next, verify the software instance CI and check if that cmdb_software_instance record is legitimate
or orphaned. If it's junk, you can delete it along with the source record.

Then delete or correct the sys_object_source record. Once you remove or update that stale mapping,
IRE will no longer find a match for that Resource ID and will proceed with fresh identification
and creation logic.

After that, re-trigger the SCCM import for that device  either wait for the next scheduled import
cycle or manually re-run it. IRE should now go through the full identification process and create
the cmdb_ci_win_server record properly.

Once the CI is created, a new sys_object_source record will be written automatically pointing to
the correct Computer CI so don't manually create one.

Hope this helps

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

Thanks,

Vishnu

[BharatC]

Hi @pallavishah ,

I encountered a similar issue where SCCM data was reaching the staging tables, but the expected Windows Server CIs were not being created.

In my case, the root cause was an existing entry in the **sys_object_source** table. The SCCM Resource ID for the missing server was already mapped to a different CI (a **cmdb_software_instance** record) instead of a Computer/Windows Server CI.

After identifying the affected Resource IDs, I deleted the corresponding **sys_object_source** records and reran the SCCM import. The next SCCM run allowed IRE to process the records correctly, and the missing Windows Server CIs were created in CMDB.

You may want to check whether the Resource ID for the missing server already exists in **sys_object_source** and verify which CI the **target_sys_id** is pointing to.

If the provided solution is useful/working, please Accept as Solution and hit the Helpful.

Thanks & Regards,
Bharat Chavan