Is Discovery Tool supposed to create hardware models or "product models"?

[bjmcdonald]

Is Discovery Tool supposed to create hardware models or "product models" when it discovers a new item that is not set up as a hardware model?

Seems that both our bulk load processes and discovery processes create "product models" - and do not associate the model category and such when it runs and doesn't find a match.   Can someone explain how this SHOULD work - and maybe point me to some recommended governance on models / model management, please?

[Zoro]

Sorry to revive an old thread but I have run into the same issue and have a case open with ServcieNow.  They are saying that ServcieNow out of the box discovery doesn't create models.  However I am seeing that the Discovery ID is actively creating Models.  It creates duplicates. One with the Class of Product Model and the exact came one but with a Class of Hardware Model.  So when Users are creating Hardware asset records they see these same model names on the model menu twice.  

This thread and other suggest that ServcieNow Discovery creates CIs and when it does, if there is no existing model in the menu then it creates the entry but ServcieNow and I can't find any documentation as to how this works.  Do you know what the design is here?  Is our system customized to do this or is it out of the box?

Thank you

[cyked]

Discovery absolutely creates models out of the box.  To address this, you can set up normalization rules. Say for example You have modules like XYZ, XYZ1, XYZ2.  You can normalize around the common part (and possibly manufacturer, I forget), XYZ, so that when a model that matches during discovery gets normalized to a single model you want/expect.  In my experience manufacturers are terrible at this.  You'll see things like IBM, IBM Inc., IBM something else, HP, H.P., Hewitt-Packard, Hewitt Packard.  And that's just the company name differing across hardware.

Some detail here - https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/field-administration/concept/c_FieldNormalization.html

There's also the option to customize some of the code on the platform (for things like script includes do an insert and stay, inactive the out of the box so you can get updates during platform upgrades/patching). As an example, in the transform maps for the SCCM integration (for us just workstations like laptops/desktops) we disabled the function around make/model.  All of our physical assets come in via the asset process.  The records are loaded to the ALM tables and integrations or discovery will update them with "findable" attributes. That way when the SCCM integration executes we don't overwrite our model/manufacturer data we purposefully loaded with undesirable information from SCCM.

[Zoro]

Thank you!

[robin850]

BJ,

I agree it is a bit strange.

Perhaps our illustrious forum folks have an opinion as to WHY the Discovery product sometimes creates a Hardware Model and sometimes creates a Product Model?

Regards,

Shaun

aleck.lin, doug.schulze

[jake_mckenna]

It actually has to do with the default probe and sensors difference between SNMP and other devices classifiers. SNMP uses a different method to build the models as generic product models once they are created where Windows servers/ Linux servers, for example, use the script includes MakeAndModelJS that has a parameter to set them as a hardware model. The function used by SNMP is SncMakeAndModel.

I hope that helps shed some light on that.