How ServiceNow Discovery uses sys_object_source

[Carlos Guidugli]

Hi,

Noticed that in our environment we have more than 50 million records on the sys_object_table. I understand how SCCM uses the table but it is not clear how ServiceNow discovery uses it. While SCCM uses the ID field as a key to find the target CI, discovery have fixed ID as "ServiceNow". So, does discovery uses it only to compare the last scan?

Another question, is it safe to remove entries from this table?

References:

https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/product/configuration-managemen...

https://docs.servicenow.com/bundle/quebec-it-operations-management/page/product/discovery/task/t_Cha...

[Marek Meres]

Hi,

I can see it in the IRE payloads - it is attempted before any actual cmdb_identifiers are tried. Example:

But ootb records cannot be deleted even by admins, a new ACL is needed as per KB0746309

Best regards,

Marek

[Ken K1 · Accepted solution]

The sys_object_source contains the Source Native Key which is used for record correlation in SG-SCCM.  This is different than in the original SCCM integration.    As of this writing, the Source Native Key on sys_object_src contains a concatenation of SCCM resource id and the sys_id of the *connection alias in ServiceNow*.   This changed in the 3.x SG-SCCM code updates from 2.x.   When SG-SCCM runs it uses this value to correlate the source system (defined by the connection record) and the record from the source system (SCCM).   If those values match, SG will pull over all the values through  a transform load.   If they do not match, it will drop into the IRE to do matching.   So if the Source Native Key were empty,  IRE would match on Serial for example and insert/ update the Source Native Key for that related record. 
Correlation ID is no longer used for the integration as I understand it.  So you might want to remove that from your IRE (CI Class Manager> Class).  This change was made so that environments with more than one SCCM environment could co-exist without collission.   

There is a risk by not understanding this and its not well documented when MIGRATING from one SCCM to another SCCM.   
If these two conditions are met, then you will clobber your CI data and it is very very difficult to recover and maintain relationships with existing records (like assets).

Condition 1:  The SCCM team re-uses or has overlapping resource id ranges between the "old" and "new" systems and the same data is not associated with same resource id from the old system.  This is like changing the primary key on a record and will point to a completely different resource configuration.  e.g.  something that used to be a desktop record, could be a server record.  

Old range: 160000 - 200000
New range: 159000 - 190000

Overlap : 159000 - 190000 (~31,000 records overlap)

Condition 2:   You reconfigure the existing connection alias rather than create a new connection  and associate it with SG-SCCM.   This has the effect of telling SG-SCCM the "old" system and "new" system are identical.

If these two conditions are met,  SG-SCCM will over-write all of the Source Key matched data from the new SCCM into the existing ServiceNow record.   So a computer that might have been a Desktop could be overwritten with Server data.  The recovery is very difficult because all of the IRE attributes (serial, name, mac) are all overwritten with the values from SCCM for the record.   

When migrating It is critical to create a new connection ID vs. reconfigure an existing one for the new SCCM system and update SG to use it to avoid this issue.