
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2020 12:04 PM
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:
- Why isn't Discovery honoring SCCM as a source with higher precedence and not overwriting values sourced from SCCM?
- 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?
Solved! Go to Solution.
- Labels:
-
Discovery

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-12-2020 06:42 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-25-2020 09:40 AM
If you take the 1.0.2 version off url you will be able to request the app.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-12-2020 06:42 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-07-2020 02:01 PM
Check out post I just made. https://community.servicenow.com/community?id=community_article&sys_id=e7202b51dbc4585c13b5fb2439961...