Discovery overwriting Linux Servers with same Serial Number

Adrian V_
Tera Expert

Good morning,

 

In Utah release, we have several Linux Servers that because of infrasctructure reasons have the same Serial Number. Modifying these Serial Numbers is not an option right now because it would be too impacting.

When Discovery runs, it is overwriting these servers in the same record. Everytime the discovery is executed, the servers are updated several times, leaving finally the name (and other fields) of the last server it discovered.

Let's say we have:

 

NameSerial number
example111sn123
example222sn123
example333sn123

 

I put a screenshot to show an example of the overwrite:

AdrianV__0-1708076915879.png

We have gone through other community articles such as Discover multiple CIs with the same serial number - Part I but we don't get the clue here. We have tried:

- Modifying identifiers: Inside the hardware identifier, we created a new Identifier entry on the Linux Server table with order 50 that should match with these servers using the Name as criteria and with the condition that 'name starts with example'. In the rest of the ootb we added the condition that the 'name does not contain example'.

AdrianV__0-1708078465861.png

 

- Creating a new identifier on the Linux Server table, with two entries, one with name as criteria and condition 'name starts by example' and another with serial number as criteria and condition 'name does not contain example'. 

- Creating manually the host example222 and a record on serial number table relating ns123 with the CI, but discovery continue working in the same way, not considering it.

 

Maybe we are missing something or not taking the proper perspective. Can you please give us a hand on this?

Thank you in advance!

#Discovery #CMDB

1 ACCEPTED SOLUTION

Adrian V_
Tera Expert

Hi,

The issue was that the property 'glide.identification_engine.enable_identifier_optional_condition' didn't exist in our instances. We created it with the value 'true' and then the conditions in the Identifier entries started to work . We needed to delete the involved servers to get the them created.

 

Reference: Create or edit a CI identification rule (Advanced Options section)

https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-manag...

View solution in original post

1 REPLY 1

Adrian V_
Tera Expert

Hi,

The issue was that the property 'glide.identification_engine.enable_identifier_optional_condition' didn't exist in our instances. We created it with the value 'true' and then the conditions in the Identifier entries started to work . We needed to delete the involved servers to get the them created.

 

Reference: Create or edit a CI identification rule (Advanced Options section)

https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-manag...