Handling Overloaded Serial Numbers in Discovery and IRE

[Greg Hoschar]

We’re in the early stages of an ITOM Visibility rollout and have run into a question about how Discovery and the Identification & Reconciliation Engine (IRE) handle overloaded serial numbers.

In our environment, there are several Known Overloaded Serial Numbers (KOSNs), such as 0123456789 and 'To be filled by O.E.M.' (Yes, those are actual BIOS serials.)

Our current integrations deal with this by:

• Blanking the serial number on the CI record itself.
• Logging the original serial in the Serial Number [cmdb_serial_number] related list, appending extra identifiers (data source + external correlation ID) so we can report on which devices use those serials without causing incorrect CI merges.

As we move to Discovery and IRE, I have two questions:

1. Does Discovery have any built-in way to recognize overloaded serial numbers, or will we need to customize probes/patterns to handle KOSNs?
2. Does the IRE match on Serial Number rows where 'Valid=false'?
   If the IRE ignores invalid serials, we could simply log the original value without appending extra data.

Has anyone implemented best practices for handling KOSNs in Discovery and IRE? Any tips or lessons learned would be greatly appreciated.

[Matthew_13 · Accepted solution]

@Greg Hoschar - 

You’re on the right track my friend!

In ServiceNow, Discovery doesn’t automatically detect overloaded serial numbers, so teams usually handle KOSNs in patterns or probes. The good news is that IRE ignores serial numbers marked as Valid = false, so they won’t cause bad CI merges.

A common approach is to store the original serial as invalid for reporting and let IRE rely on stronger identifiers instead. That keeps the data without breaking identification.

Thumbs up if this helps you. Thanks!