Discovery creating duplicate Hardware Models instead of matching existing

[scotts3003]

We are encountering an issue with Discovery where it is creating a brand-new Hardware Model (cmdb_hardware_product_model) record for almost every newly discovered CI, rather than linking the CI to our existing Hardware Model record.

This behavior is occurring primarily with storage and infrastructure CIs, specifically Hitachi and NetApp items/BMCs.

Expected Behavior:

During the Discovery payload processing and Identification and Reconciliation Engine (IRE) execution, the system should match the discovered Model Name and Manufacturer against existing records in cmdb_hardware_product_model and populate the model_id reference on the CI with the existing model.

Actual Behavior:

Instead of referencing the pre-existing Hardware Model, Discovery inserts a new model record into the Hardware Model table for each CI run, leading to significant model duplication across our CMDB.

Environment Details:

• Primary Affected CIs: Hitachi & NetApp storage devices / BMCs / Controllers

• Target Table: Hardware Model (cmdb_hardware_product_model)

• Normalization is running

Questions for the Community:

1. Has anyone seen this specific model-duplication behavior with Hitachi or NetApp Discovery patterns/probes?

2. Are there known issues with how the Model Name string is normalized or extracted from these specific storage patterns that bypasses standard Model Normalization / IRE matching?

3. What is the recommended approach to troubleshoot where the payload is failing to match—checking the Model Normalization rules, pattern script outputs, or pre-bind scripts?

Any guidance, PRBs, or troubleshooting steps you could share would be greatly appreciated!

Thanks in advance for your help!

[ayushraj7012933]

Hi @scotts3003 

I would first check the Discovery data and the values being passed to IRE before changing any OOB rules.

For one of the affected Hitachi or NetApp CIs, I would compare the existing Hardware Model with the newly created one. Pay particular attention to the Manufacturer and Model Name values. Sometimes a small difference in the model string, such as an extra space, suffix, different formatting, or controller information, can cause Discovery to create a new Hardware Model instead of using the existing one.

I would also check the Pattern Log for the affected CI to see what model and manufacturer values are actually being returned by the Discovery pattern. Then check how those values look after Model Normalization.

The next step would be to look at the IRE processing/debug information for the same discovery run. This should help confirm whether IRE is unable to find the existing Hardware Model or whether the Discovery payload itself is providing a different value.

For storage devices, I would also check the pattern steps that populate the model information, especially for controllers and BMCs. It is possible that the model value being discovered is slightly different from the value already maintained in cmdb_hardware_product_model.

I would troubleshoot one CI end-to-end first:

Device → Discovery Pattern → Pattern Output → Model Normalization → IRE → Hardware Model

If the Manufacturer and Model Name are exactly the same after normalization, but Discovery is still creating a new Hardware Model, then I would look further into the IRE/model matching behavior.

I would avoid modifying the OOB identification or normalization rules until the actual difference is identified. In many cases, comparing the existing model, newly created model, and the values in the Discovery payload will quickly show where the mismatch is happening.