How to tag CI with one of the Discovery sources

[RahulY00040]

Hello friends,

We have 3 discovery tools discovering same CI, however we want to highlight/tag a CI with specific discovery source to show that it was discovered by that source. 3 of the sources have same priority. So , can i have it done without creating custom fields.

Thanks,
Rahul

[scottl]

To my understanding the limitation of Discovery is that it will update that field (Discovery source) every time it's discovered regardless if there was a field update. Rather than creating a custom field and polluting the table with METADATA of an integration, extend the CMDB and create a table with METADATA associated to that record. Note: There is no licence limitation on creating extended CMDB tables (to my understanding).

There is also the "cmdb_key_value" table which could be used too.  However, I had a hard time trying to use that table with IntegrationHub ETL.  

But there is a valid reason to create that custom field on the CMDB table, if you can categorise it correctly, as it is something that is generally overlooked, and should exist to help with grouping of records, esp for reporting.  For example if you wanted to update attributes like warranty data but the main record exists in a master system (InTune) you would want to have a consistant field stating it comes from InTune. For example, "Master/Primary Discovery Source". BUT if you're going to then reference and store a heap of METADATA for that integration I suggest looking at my suggestion above and using/extending a table.

[RahulY00040]

Thanks for your response. You mean whenever CMDB IREs are called, Discovery Source field gets updated. Is this right? I am going to check on this.

Also, I thought of creating the custom field such as Primary Discovery Source on CI table and having higher precedence configured for this field for the particular Source system, it should work. I feel creating the cmdb extended table is overhead.  please provide your thoughts.

Thanks,
Rahul

[scottl]

Yes, if found, regardless of an update that field is updated. That's annoying if you then have another lower level Discovery mechanism, which retrieves other lower level data, like I suggested with warranty data. It means the discovery source for the record then becomes that lower level discovery, and not the master discovery.  Precedence won't help if the lower discovery always runs.

"Primary Discovery Source" would do.  

The other table is not overhead if you are also retrieving other data from that Discovery source, like, a "Check In Datetime", just for that CI.  For example, the Computer table CI's from different data sources JAMF (Apple) vs INTUNE (Windows) have different META DATA types. which you would want to keep but also other computer/devices doesn't use those fields, thus polluting the Computer table with fields from Intune, when an Apple or other device doesn't use those fields. 

I've seem too many messes, of people polluting tables with custom fields and then using multiple policies to hide those fields because they don't apply to that record as it's not related to that data in anyway.  It's much better to use a METADATA table, and link to those records through the related list. Way cleaner. 

The term that will help explain this is database Normalisation, which is the proper approach to DB design/architecture 👍🏻

Update: Design the METADATA table like a key value pair, linking through a Document ID field. Define the keys like CONSTANTS, then you can use it everywhere. You'll be surprised how offen you might/will use it to store related data.