Identification - Diff Serial Numbers, same CI name, 1 CI record

[tenagra]

Recently found out that the VM Team, in their awesomeness, have been reusing computer names in different domains.   My expectation is that as long as the Serial Numbers were different, then we should be seeing multiple CI's with the same name, in a different domain, with a different serial number.   Specifically, 3 different servers, same name, 3 different domains, 3 different serial numbers.

This isn't happening.   Rather, we have a single CI that, per the audit logs, keeps having it's information updated back and forth between the different servers, as those servers are discovered by multiple schedules.   So, it will switch the serial number, ip address, and domain attributes (and others) during schedule 1, change again on schedule 2, then back to the values found last on schedule 3.

When reviewing discovery logs, we see the following:

So, we can see that it is using the name, rather than the Serial Number from the logs.  

The first rule for SCCM ID & class name is ignored, as expected.

The second Identifier Rule "Serial Number Table & Class" has multiple records in the Serial Number table (cmdb_serial_number).   There are multiple records for the same SN# with different types and different SN# for the same CI.   Unsure how this happened, but it is there.   I understand the message here, and while I'd like to understand more about how stuff gets in this table and such, at least the message makes sense.

The third identifier Rule "Serial Number and Class Name" is based solely on the cmdb_hardware table.   Doing a search on the serial numbers, I find a single record for 1 serial number and no matching records for the other 2 records.  

It then uses the 4th Identifier rule of name, to get the match.  

Why doesn't it create a new CI when there isn't a match on the CI for rule 3?  

Thanks,

Nathan

[Saketh]

Hi Nathan,

In App Nav, Configuration -> Identification/Reconciliation -> CI Identifiers -> Hardware Rule

In Hardware Rule, under Idenitifier Entries, you will find all the identifiers for identifying a device.

If one of the identifiers fails to identify the device, the next identifier will try to identify the device.

The identifiers are triggered based on value of 'order' column.

In your case, you can mark the 'Name, Classname' identifier as 'false' in the Hardware Rule.

I hope the above answer helps.

Thank you,

Saketh

[tenagra]

Interesting.   Not sure how this would work for items like workstations, which are based upon DHCP, rather than just a static IP like a server.   I'll have to try it out in the lower environment.

Thanks,

Nathan

[Chris M3]

As it goes through the rules, there are three possible outcomes at each rule.

Match Exactly 1 record - CI has been identified and its done

Match 0 records - Moves to the next Identifier rule.

Match > 1 records - Possible duplication, CI Identification fails.

So, since the serial number does not match any records, it will move on to the name match.

In addition to just disabling that rule, you can alternatively modify that rule to match on name & serial number, or name & domain.   Some other unique set of attributes.

[tenagra]

Chris,

That makes sense.   Thank you.

Regarding modifying the rule or adding a new one, I can see a few options.   My larger concern is that we have just over 1.5M CI's in the system, and I don't relish the idea of making a mistake and adding more to.

With that stated, here are some of my thoughts and questions:

1) Update the rule to be based upon Name & Serial Number.   I like the idea up front, but there are some scenarios were the serial number isn't available.   How would that work?   Is there where the "allow null attribute" flag comes into play?

2) Name & Location.   Similar questions to the above.

3) Move name further down the list and let the IP/MAC Address rules come into play.   Not sure if that's a good idea for workstations on DHCP however?  

4) Use FQDN, rather than name.   However, this isn't getting populated consistently in our environment for some reason.   Surprised this isn't an OOB population.   Thoughts on going this route?

Thank you very much.

Sincerely,

Nathan