How to copy the Hardware Rule CMDB Identifier for specific Sub-Classes, to identify Unusual Hardware correctly, or where different devices are known to share name/serialDescriptionThe 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.CauseAn Example - Many Printers have the same Name 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. Discovery will see the 1st device, see that SNMP is open, and run the Classify and Identity probes.The data will include the Name and Serial number, plus network adapter information including IP Address and MAC Address of that 1st device.The Identification and Reconciliation Engine (IRE) will not be able to match any existing CI so will create a new CIDiscovery now sees the 2nd device. This has the same Name (e.g. "RACKPDU"), but all the other identification data will be different.The Identification and Reconciliation Engine will run through each of the Hardware Rule's rules to compare what has been seen with what is already in the CMDB, in order: Search Serial Number table [cmdb_serial_number] for a matching serial_number,serial_number_type - No Match.Search the Serial Number field of the main Hardware [cmdb_ci_hardware] records - No Match.Search the Name field of the main Hardware [cmdb_ci_hardware] records - Match with 1st CI, not good! A match was made with the 1st device's CI, and that is then wrongly updated with the 2nd device's attributes.Every time either of those devices are re-discovered, the same CI will be updated and duplicate cmdb_ci_serial_number, cmdb_ci_network_adapter and cmdb_ci_ip_address records will be created each time, and be linked to that single main CI.If you have hundreds of similar devices, you end up with a real mess in those related tables. The only CI in the CMDB will randomly represent one of the devices and will regularly change attributes to match whatever was the last scanned, and no CIs will exist for all the others.ResolutionThe above Printer example, where multiple printers are known to have the same name: Open the CI Class Manager: Configuration - CI Class ManagerOn the left, in the Class Hierarchy list, select the CI Class that needs a custom identifier. e.g. Hardware>PrinterIn the right column, select CI Identifiers. You will see the Hardware Rule listed in the "Identification" list.Click New in the header of that Identification list.Name your new Identifier. e.g. "Custom - Printer", and Submit.Back in the navigation, Open the list of Identifiers: Configuration - CI IdentifiersOpen the "Hardware Rule"For each of the Active records in the 'Identifier Entries' related list: Open the recordChange 'Identifier' to your table name. e.g. cmdb_ci_printerIf the 'Search on table' is Hardware: Note which fields are listed in 'Criterion attributes', as you're going to have to put those back in a moment. e.g. 'IP Address, MAC Address' or 'Serial number'change Search on table to your table. e.g. Printer.Add the fields you noted above back into the 'Criterion attributes' Right click the header, and 'Insert' to make a copy if that entry for your own identifier. (Don't save or submit or you will be modifying the Hardware Rule!) For each of the Active records in the 'Related Entries' related list: Open the recordChange 'Identifier' to your table name. e.g. cmdb_ci_printerRight click the header, and 'Insert' to make a copy if that entry for your own identifier. (Don't save or submit or you will be modifying the Hardware Rule!) Open your new identifier. You will see your newly copied Identifier entries listed. At this point it is a straight copy of the Hardware Rule, and so functionally identical.De-activate the troublesome entries. e.g. Untick Active for the entry where the criterion is 'Name', if you've got CIs you know share the same name.You could also add new entries with other criteria needed to workaround the quirks of your specific device models. 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. A trickier Example - AIX Servers share the same Serial Number 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). First change the Identifier, and do the Insert & Stay.Then change the 'Search on table', which clears the Criterion attributes so re-enter those, then Update Adding a new Entry for Name + Serial Number: Editing the Serial number entries to add an impossible condition: Leaves the new Identifier as: Additional InformationCreating 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.Specifically, defining custom identification rules for a specific CMDB class will break the inheritance of any and all identification rules for that class from the parent class. This includes Related Entry rules. Therefore, if a new identification rule is introduced for a class, all related entry rules that are still applicable to the class will need to be recreated and monitored/maintained in an ongoing fashion. For example, new application installs can introduce app-specific related entry rules, and those will also need to be replicated if appropriate.Note also that introducing custom identification rules for a specific CMDB Class can also have a side effect of risking creation of duplicate CIs that exist at different points in a class hierarchy. This is because the default IRE behavior for an identification rule is to only search in that specific CMDB class for matches using that identification rule. Therefore, if there is an existing CI that exists in the parent class of that class, it will not be found by IRE. And instead, a new CI might be inserted in the specific class, resulting in a duplicate.For example, suppose that a custom identification rule is defined for cmdb_ci_server, defining identification by matching on Name and Serial Number. If there is a CI that exists in cmdb_ci_computer (parent of cmdb_ci_server) and has the same Name and Serial Number, it will not be found or matched by IRE with this cmdb_ci_server rule. Instead, another CI will be inserted into cmdb_ci_server with the same Name and Serial Number. And since cmdb_ci_server is a child of cmdb_ci_computer, in the cmdb_ci_computer table there will be 2 distinct CIs with the same Name and Serial Number. 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.