SCCM discovery matching of existing CIs

[treidfrb]

SCCM discovery matching of existing CIs

For those running SCCM Discovery for workstations, I am trying to determine the match scheme being used.  The only attribute in the mapping with coalesce enabled is on sys_id.  That makes no sense as there are no SNOW sys_ids in the source data.  It should be matching against 1) correlation_id (resource ID in SCCM) and then 2) serial number if correlation_id is empty or non existent.  In Computer Identity "runIt()" function, the last call is to setCorrelationID(), which is a hard set of the attribute, and therefore is not conditional.  From the other posts, I looked into Identifiers for SCCM Discovery and did not find an entry for cmdb_ci_computer, which is the target table of the integration.

If anybody can offer some insight I would appreciate it.

Tim

[DaveHertel]

Hi --  If ResourceID is a unique identifier in SCCM, then I'd strongly consider importing that field into the correlation_id field, then expand the CI identifier defined on hardware class (or computer if you prefer).  The ServiceNow correlation_id field is available for use for just this scenario... i.e. defining a well-defined, unique ID for a given object.   To summarize:

1. Import data unique data (resource id) into the correlation_id field on the appropriate CMDB table
2. Expand CI identifier for same table to use the correlation_id field  

I did exactly this recently to merge data from an outside source.  That data source had unique identifiers.... i followed this approach and each time the data feed comes into the cmdb from this external source it matches (using the expanded CI ID entry) and the updates the CI (rather than erroneously creating dups). 
  Example - the OOB identifier for hardware has 4 entries.  I added a 5th to handle matching on external data via the correlation ID field.

Does this help?  Hope so...

[treidfrb · Accepted solution]

Hi Dave thanks!

Correlation_id is used OOB with the SCCM integration, but I have seen it be violated.  I believe I found the reason why, as one of the integration scripts had been modified and had an error in a variable format.  I just need to get a check on install_status in the identifiers and I should be good to go. 

Thank you for the prompt reply!

Tim

[treidfrb]

Update on this issue, apologies for the long delay.  We had found our problem with resource IDs from SCCM, it was caused by an SCCM upgrade which reset the number pattern down to a number lower than the latest resource ID.  Then it started incrementing the resource ID, which started colliding with resource IDs of previously created workstation CIs.  The fix was quite a challenge, and I will make a callout to my friend Kulbir Dhindhwal who did a brilliant job of fixing the issues.  We were having multiple CIs/Assets flip flopping every time the SCCM integration ran, between the new SCCM and old SCCM resource ID.  We had to gather a lot of information about the behavior to get the proper CI updated based on the create date of the CI being after the SCCM upgrade.

Closing this post.

Thanks

Tim

[psyherin]

Hi @treidfrb ,

We are sort off having the same issue. How did you go about fixing the issue? 

Thanks