Hi @syed_but_not
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.
Also check this - DiscoveryCMDBUtil.useCMDBIdentifiers() is set to false.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thanks
AJ
Linkedin Profile:- https://www.linkedin.com/in/ajay-kumar-66a91385/
ServiceNow Community Rising Star 2024
