Model ID Field is Populated on a CI via ServiceNow Discovery for SNMP devices - Support and Troubleshooting

Model ID Field is Populated on a CI via ServiceNow Discovery for SNMP devices Issue How does the Model ID field on a CI get its value populated, and what is the back process/ Script Include that helps populate the Model ID?

Release This is a simple and straightforward feature, aimed at ensuring accurate population of key identification fields for network devices during Discovery.

🔧 Where It Lives The logic is implemented in the Pre/Post Processing script: Network Devices - Pre Sensor

🧠 What It Does The script includes a function called: handleModelAndManufacturer()

This function:

Executes after Discovery has run Updates the Model and Manufacturer fields on the CI record Pulls the values from Discovery results, ensuring that these fields reflect the most accurate data Cause There may be a case when you want to populate a Different Model ID but a totally different Model is coming up a Discovery record.

OR

A case where no Model ID is coming up on a Network device as the pattern is bringing the Model ID as NULL.

Resolution 🧠 Understanding Model ID Behavior for Network Devices in Discovery Use Case A Network Switch CI (e.g., IP Switch) is being discovered via SNMP, and has an existing Model ID: Cisco Systems cat36xxstack .

However, when Discovery runs, the pattern retrieves a more accurate model name from the device: WS-C3650-48TD .

The SNMP sysObjectID for this CI is: 1.3.6.1.4.1.9.1.2066

Despite the updated value being present in the Discovery pattern, the Model ID is not updated. Instead, the CI continues to show the model as cat36xxstack .

✅ Root Cause The reason for this behavior lies in the SNMP OID Classification Table ( discovery_snmp_oid ).

Each OID record in this table can optionally define a Model and Manufacturer. When these fields are populated, Discovery treats them as authoritative and uses them to classify the device, overriding any model information returned by the pattern itself.

In this case:

OID 1.3.6.1.4.1.9.1.2066 is associated with Cisco Systems and model cat36xxstack Therefore, even though Discovery returns a more specific model name ( WS-C3650-48TD ), the system prioritizes the value from the OID table

🔁 Expected Behavior During Discovery Discovery runs SNMP commands and gathers raw data, including sysObjectID and model info from the device The system checks the discovery_snmp_oid table for a matching OID If a match is found and it includes a Model/Manufacturer, those values are applied to the CI Any more accurate model name returned by Discovery patterns is ignored due to this override ✅ Recommended Solution To ensure the Model ID returned by Discovery patterns is used, follow this approach:

🔧 Step-by-Step Fix Navigate to the discovery_snmp_oid table Locate the entry for OID: 1.3.6.1.4.1.9.1.2066 Clear the Model field (and optionally the Manufacturer, if applicable) Save the record

✅ What Happens Next? On the next Discovery run, since the Model field on the OID table is now blank, the system will: Use the model information returned by Discovery patterns, such as WS-C3650-48TD Link the CI to the correct cmdb_model record This ensures accurate classification and prevents overriding from generic model entries

⚠️ Important Considerations If Discovery does not return a model name, and the OID table no longer has one either: For new CIs, the Model ID will remain blank For existing CIs, the previously set model (if any) will remain unchanged