The out-of-box "Hardware Rule" CMDB Identifier makes some general assumptions, and specific peculiarities of certain makes and models of devices won't work well. e.g. Name, IP or MAC address is not always unique. Even Serial Number may be shared between servers in the same chassis, or virtual environments.
This is the procedure of copying the Hardware Rule for a specific CI Class, which can then be modified to cope with those strange devices that don't fit the assumptions.
Once that has been done, the new Identifier will be used for that specific class of CI only, instead of the Hardware Rule.
You may have a lot of similar devices/models that return the same default "Name" via SNMP. e.g. APC PDUs (name=RACKPDU), and Ricoh Afficio network printers (name=<model number> e.g. "MP 2550")
If 2 of those devices exist on the network, this is how the default "Hardware Rule" breaks.
If you are doing something similar to the above Printer example, where the Name rule is deactivated for Printers, then you would expect a lot of printer CIs to be created on the next discovery run, because there will be no match made with existing data. Then on the subsequent discovery run each of the individual CIs will be identified by serial number and updated correctly, because you still have the other entries in your new identifier. Non-Printers will not be affected by your change, and the Hardware Rule will continue to be used for those.
The reason that the Related Entries are also copied is that some Discovery Patterns are written to use the Hardware Rule, and e.g. if a new custom Identifier for Server is created, then the Linux Server pattern won't work properly without those Related Entries it expects.
You can basically do the same as above, but this time creating an independent identifier for AIX Server [cmdb_ci_aix_server]. The Serial number field, and Serial Number table entries would need disabling to avoid matching only on serial number. A new entry for Name and Serial Number can be added to serial number is still used, but only if there is a matching name too.
What makes this tricky is that the Identification engine Errors if you don't have a rule for serial number. The rules for serial number are what is causing the mis-identification in this case, but if you deactivate those you would see errors in the Pattern log like this and the pattern would fail to update anything:
Identification CI Errors:
Identity Rule for table [cmdb_ci_aix_server] missing Lookup Rule for class [cmdb_serial_number],Abandoned due to too many errors...
The trick to avoid that error is to keep those entries active, but add a filter condition that can never happen, so that the rule can never make a match using that entry. It's now effectively disabled, but still officially active.
e.g. Serial Number IS NeverGoingToMatchOnThis
Some screenshots of the AIX example, which is also attached as an update set for reference. This was done on a Paris Patch 4 instance.
Open the records directly. This bit can't easily be done from the CI Class Manager.
When copying the Entries, the Hardware Table ones need doing in 2 steps (Edit, Insert, Edit more, Update). The other Identifier Entries and Related Entries can be done in 1 step (Edit the identifier and Insert).
Adding a new Entry for Name + Serial Number:
Editing the Serial number entries to add an impossible condition:
Leaves the new Identifier as:
Creating new Identifiers can have side effects. A lot of features use this for matching imported or discovered data with the existing CMDB records. Thorough testing of any discovery sources or imports is advisable on a sub-production instance after making any changes.
If entries are added or changed on the out-of-box identifiers after you copied them, those changes will need manually doing . It is worth keeping an eye on identifier changes done as part of upgrades so that you can maintain your own identifiers to match.
Discovery Patterns and other features will assume they will be using the out-of-box identifiers when putting IRE payloads together. If those payloads cause errors in the identification engine during insert/update, then the customised identifiers are likely to be missing entries, or need updating to match the out-of-box ones they used to inherit.