How can we prevent Duplicate CI for Name+Serial Number IRE combination

[Suvetha S]

Hi All,

We have changed the OOB IRE rule for Server table to look for Name + Serial Number combination. So if a server comes in with a matching Serial Number and Name IRE will update the existing records. In certain cases, Discovery couldn't fetch the serial number from the target servers and IRE is creating a duplicate CI. One CI - Name & Empty Serial Number, second CI- Same name with Serial number value. Initially we thought of entering serial number values for cmdb_serial_number manually to avoid the issue, but it didn't work as expected. Whenever Discovery is bringing empty serial number its creating a duplicate in the system. Any suggestions will be helpful. 

[Rahul Priyadars]

Hi Suvetha

Do u have Same IRE rule at Server Class or at Child Classes too (Windows, Server ). 

CMDB_CI_Server Class what is Set there?

CMDB_CI_WIndows/Linux/AIX - Classes what is the IRE Set here?

Do u have any INCLUSION Rule also configured at Class level?

Regards

RP

[Suvetha S]

Hi @Rahul Priyadars , Yes we have same IRE for all the child classes. We are excluding only the Retired Servers. What changes would be needed for these items to be ID’d as duplicates? ANy suggestions

[Rahul Priyadars]

Discovery couldn't fetch the serial number from the target servers and IRE is creating a duplicate CI. One CI - Name & Empty Serial Number, second CI- Same name with Serial number value.---> Did u checked why its not fetching Serial No in first Go. 

Name + Null Serial No- Server1

Name+ Serial No (has Value) - Dup Server1

In My view at Higher Order add 2 more Rules for IRE one with Only Name and Other With Only Serial No Unless you have the reason why First time Serial No is not fetched from Server.

Regards

RP

[Michael de Boer]

Hi @Suvetha S,

Are all hostnames unique? (I hope so)
When that is the case, I suggest to create 2 identification rules to match the following.
1. Name + Serial Number
2. Name

When the serial number is missing it updates the CI with the same name.

[Angelo Cortesi]

When the Discovery feature of ServiceNow scans a new Virtual Machine, it identifies at least 5 or 6 serial numbers for each VM by default. These serial numbers are then stored in the cmdb_serial_number field, associated with their respective serial number types (such as BIOS, chipset, baseboard, etc.). However, only one serial number is recorded in the CMDB serial number field, and typically, the baseboard type is chosen as the unique identifier among them. This choice might be due to its similarity to a MAC address, signifying more hardware information compared to the BIOS (based on my humble speculation).

If the Discovery process finds all serial numbers except for the baseboard type, it's not explicitly mentioned how the system will handle this scenario. It could potentially default to the chipset type or follow a predetermined order of preference, such as selecting the BIOS serial number to add to the CMDB field. The specific behavior should be clarified to ensure accurate handling of serial numbers.

When creating a rule for the combination of Serial Number + Name, potential issues arise if the Name is already duplicated in the CMDB. It's essential to understand how Discovery deals with duplicated records under a coalesce field. Will it update all duplicated records, and how will it handle duplicate serial numbers?

Moreover, considering the 5 or 6 serial numbers found in a VM during Discovery, it's crucial to clarify how the system attempts to match these serial numbers one by one, regardless of their types. Does it prioritize a specific type, and how does it handle situations where multiple matches are possible?

In summary, to effectively work with serial numbers in ServiceNow Discovery, it's important to have clear answers to these questions and to document the expected behavior in various scenarios to ensure accurate and reliable data in the CMDB.