ServiceNow Discovery, SCCM, & Data Precedence

cloudyrobert
Kilo Guru

I've implemented the SCCM integration in our development environment (com.snc.integration.sccm2016). My intention is for SCCM to serve as the authoritative source for the devices it covers, supplemented by ServiceNow Discovery where there is not a conflict with data from SCCM. It appears that ServiceNow Discovery & the SCCM integration are overwriting each other. I've set up a Data Precedence Rule for both SCCM (priority 100) and ServiceNow (priority 200) on the cmdb_ci_computer table, yet ServiceNow Discovery continues to overwrite certain fields (disk space and name in particular) and relationships (disks, file systems, serial numbers).

My understanding is that the precedence rule should keep Discovery from overwriting fields set by SCCM. I'm aware that the SCCM integration does not honor the rules (https://hi.service-now.com/kb_view.do?sysparm_article=KB0748948), but shouldn't Discovery?

My questions:

  1. Why isn't Discovery honoring SCCM as a source with higher precedence and not overwriting values sourced from SCCM?
  2. Are relationships included in the precedence rule on the table so that when I resolve question 1's issue, the relationships will also stop being overwritten?
1 ACCEPTED SOLUTION

cloudyrobert
Kilo Guru

This does have to do with the SCCM integration not using the IRE, pre-Orlando. Since there are no entries in the cmdb_datasource_last_update table due to the integration not using the IRE, the data precedence rules aren't followed. The main cases for me are Name and OS Domain. There's a PRB (PRB691517) with a workaround for this in a KB (KB0753063) if you ask for access from HI. They use a couple of properties to change the way these fields are set to make the overwriting not a problem, but they're not a true fix of the underlying issue. We're now just seeing the Discovery source flip back and forth, which is OK until Orlando.

View solution in original post

7 REPLIES 7

cloudyrobert
Kilo Guru

This does have to do with the SCCM integration not using the IRE, pre-Orlando. Since there are no entries in the cmdb_datasource_last_update table due to the integration not using the IRE, the data precedence rules aren't followed. The main cases for me are Name and OS Domain. There's a PRB (PRB691517) with a workaround for this in a KB (KB0753063) if you ask for access from HI. They use a couple of properties to change the way these fields are set to make the overwriting not a problem, but they're not a true fix of the underlying issue. We're now just seeing the Discovery source flip back and forth, which is OK until Orlando.