IRE: What is the best way to resolve issues with CIs flipping attributes due to non-unique names?

[Bobby Campbell]

10 discoverable PDUs all have the name 'rackpdu'. Though they have different serial numbers and IP addresses, IRE rolled them into a single CI on which the serial numbers and IP addresses flip with every discovery.

KB0789220 suggests adding a serial number identifier on the PDU table. Testing this approach in dev was successful. Will this movement away from OOB create unintended consequences for future discoveries?

Additionally, I haven't been able to grasp why the IRE's OOB configuration does this. If Serial Number doesn't match and IP Address doesn't match, shouldn't it be obvious that we're dealing with a new device? Why would Name be the definitive attribute? In this case, wouldn't it make more sense to create a new CI, rather than assume the Serial Number and IP Address are both wrong?  If I'm correctly describing the 'how' it works, then can someone please explain the 'why' it works this way?

Has anyone else seen this behavior and how did you address it?

[Dinesh Reddy By]

I encountered this issue with Network Gear CIs due to duplicate names. To resolve it, I updated the IRE rule to prioritize the serial number over the name, which successfully addressed the problem. Modifying IRE rules to enforce uniqueness does not deviate from the out-of-the-box (OOTB) process.

Thanks,

Dinesh

[SK Chand Basha]

Hi @Bobby Campbell 

I would suggest use the identification simulation to understand how ire working in background. 

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

Mark it helpful and accept solution!! If this helps you to understand.

[doug_schulze · Accepted solution]

In what you posted you are dealing with the general 'hardware' rule where everything is different yet the name is the same so it matches. So you have two choices and you already tested one.  You could choose to remove/deactiviate the name value of the hardware rule where it would create/update a unique ci but you might impact many other classes. Or, you could do as you did, create a specific rule on that class that does not evaluate 'name' but the more specific definitive values that makes these devices unique.  Or theres the 3rd option and talk to the network folks and sternly teach them that its not a good idea to name devices the exact same 🙂 .  Wise crackin aside, yes the option you chose is the best method when you have specific situations like this and I wouldn't make it independent, if possible let the hardware rule be your catch all for anything that may not be identified by your custom rule.