CI Identifiers - Hardware rule match on Serial Numbers

[cyked]

I noticed two "issues" in our dev instance the other day with the updated identification rules.

Rule 1 is correlation ID

Rule 2 is Serial Number and Serial Number Type

Rule 3 is Serial Number

I swapped priority on Rules 2 and 3.   Here's the issue I ran into.   While we do not expect server names to be reused, they are not unique and are not a key to match on, at least not at a higher priority.   And we have ran into an issue with VMs being built with previously used names.

Situation:   Server engineer is building new VMs, so we are not starting with Asset Management in this example.   Server engineer has reused some previously used names from some retired physical servers.   On discovery of the new VMs all the higher priority rules failed, those serial numbers didn't exist on any Server CI records nor the serial numbers table, but instead of creating a new CI as we would want the existing Server CI records were updated because they Identified on name. This changed the serial numbers on the CI records from a physical to a VMware one, updated every of discovered server detail (like OS version, memory, etc) and updated the asset records which changed the model information (no bueno).

The "fix" would seem to be inactivate the Name rule for Hardware, leaving only correlation ID, SN, SN/SN Type as the actives.   However, we have a few classes/types of devices like SilverPeak WAN Acc devices for example which through SNMP report a non-delimited MAC address as the serial number, which is not the serial number we receive from a seller through asset purchases, so they match on Name when serial numbers fail.   I imagine then I would need to create "sub-hardware" rules for say cmdb_ci_wan_accel_network that would also go through correlation ID, SN, SN/SN Type + Name to ID, yes?

The second "issue" has to do with the Serial Number rule.   Previously, Identification would do the following: source

• If there is no match to an existing configuration item (CI), Discovery creates a new CI.
• If there is match to an existing configuration item (CI), Discovery updates that CI.
• If multiple matches exist based on a complete match, Discovery stops for that IP address and logs the event.

What I see now is that when two servers exist (names can be the same or not) with the same serial number one of the records is "just updated" out of the pair.   I'm not seeing a clear pattern to it.   Are there still scripts behind these new Identification rules or something else going on in the background doing more than just matching on Serial Number?

[cyked]

Right, I understand not separating servers, save by class (OS). Windows VM and Physical VM are still just Windows Servers.   But I'm not sure the inclusion and order of the Identifiers will make a difference in the example I gave, in two different examples of having a Name Identifier rule as inactive or active.

The condition of an existing retired/decommed CI being updated on discovery because of a name match is specific here.   Unless i'm not understanding your rules you've mentioned, you would still end up updating an existing decommed/retired CI on discovery with the Name identifier active, regardless of serial number rules or order.   If Name is not an active Identifier then I see the only outcome being a new CI would be created, regardless of how specific you look at rules around serial number.   Example below.

If you leave Name as an active Identifier.   Build a physical server named server1 with SN 1234.   Run discovery for a month recurring and then decomm it, retire the CI in CMDB THEN later build a new server (physical or VM) and name it server1.   Regardless of the physical/virtual state of either server in this example, they will have different Serial Numbers (excluding examples of manufacturers duplicating a physical serial number).   When you discover this new serer, the original server CI will be updated and anything from discover (short description, OS detail, mem/CPU/Disk, etc.) will all be overwritten on that record.

If Name as an Identifier is inactive and you perform the same scenario above, the original CI will be left alone, and a New record will be created as expected.

Additionally, the rules don't appear on the surface to impact the other issue I'm seeing where if you have two records with the same serial number, the Serial Number rule for cmdb_ci_hardware will match and update one of the records.   The previous functionality (CI Identification > Identifiers - Serial Number & Class Name rule for example) in the event you had two records with the same serial number and there are no more identifier identifiers being executed, the Serial Number & Class Name rule will halt discovery (multiple matches found, not updating).

[robertgeen]

Hello Drew,

Identification rules can sometimes be a pain because the out of the box setup doesn't take into account all situations out there (for example if IBM HMC is used and they don't give a unique serial number then it can cause a lot issues). You will most likely have to take a look at the unique combinations you have in your environment and turn on/off quite a few of the rules. Typically I usually end up using Name/Serial number as one and use the MAC Address/IP one and turn off the rest. However before you do something like this identifying all the unique components for each type of CI you will be discovering. It may also makes sense for you to do a rule more deep (for example if you find that the out of the box works for all types other then 1 then just create a rule for that 1 specific type and leave the rest at the hardware level; e.g. There was an issue for one client where Netscaler specifically had an issue so we created a rule just to look at name specifically for that table).

Let me know if you have any questions. The other suggestion I will say is that there was an issue with using conditional filtering on them so it may actually be better to take the approach of making sub rules at deeper levels (e.g. one Specifically for Netscaler at the Netscaler table level and then rules for everything else at the hardware level).

[cyked · Accepted solution]

The identifier sys_properties were the answer.   We've been upgrading since Berlin and these were missed when we went to Helsinki (were skipping every other release typically).

Neither of the outlined sys_properties had been added.  

Discovery identifiers