SCCM inconsistancy issues. Serial numbers gets flipped when a new Asset is installed in CMDB

[Neha56]

Hello,

Serial numbers flip when a new Asset is installed. Name may stay the same when a new asset is added, causing the serial number to be overwritten but different serial number type.

Configuration item initially populates the serial number with value 1: CND1223X1Q  but when SCCM ran than instantly changes it to value 2: 5CG038B350, also there is change in serial number type.

Unable to analyze what is making the serial number to change the value again. Please find attachment.

Kindly suggest due to what reason this value is getting changed.

Thank You!!

[David104]

What do the Identification rules look like for that class? Are they OOTB (on Hardware) or have you modified them? Generally, the OOTB rules will try to match on Serial Number AND Serial Number Type from the Serial Number table, then if there is no match, it will try for a match on Serial Number on the Hardware table. Given that the serial numbers are very different, I assume those two are failing. On my demo instances, the 3rd Identification rule on the hardware table is 'Name'. I'm going to assume that is where your CI's with different serial numbers is being matched, but hard to know without seeing what your Identification rules are for that class.

So it sounds like SCCM is one of the data sources (is it the Service Graph connector) and then what is the original source? Is that coming from an asset upload, or discovery, etc? 

Do you know whuch of the serial numbers is the correct one?

[Jim Silvius]

I assume you figured this out by now. I recently ran into a similar issue with the SG-SCCM. What did you do to solve this issue?

[CMDB Whisperer]

I ran into this several years ago and I tracked it down to a root cause.  For me, anyway, the issue occurred on a Windows Server, and when I traced it I found that SCCM and Discovery were looking at the serial numbers slightly differently, and for some unknown reason this specific server was also reporting the serial numbers in different order.  If you look at the patterns for Windows Servers, you will find that the logic assumes a specific order in which the list of serial numbers are reported, and always takes the first one in the array as the primary serial number (i.e. the one that it uses to populate the serial number attribute).  In most cases, this will match the method that SCCM is using to obtain the serial number (BIOS serial number if I recall correctly), but in some cases the order of the serial numbers is different in Discovery and it causes the baseboard serial number to be used instead of the BIOS serial number (or something to that effect).  This also may have been exacerbated by inconsistency in whether the Baseboard and BIOS serial numbers were the same, which may be differences in what information is written to the flash memory on the device.

Unfortunately I do not recall whether we actually resolved the issue or what we did, if anything, to resolve it.  I think maybe we did a workaround in the Windows pattern?  But I do have a strong memory of the root cause analysis I performed, as it took quite some troubleshooting to track it down to the line in the pattern that blindly selected the first reported serial number, rather than ensuring it was the right serial number type.

[catia_alves]

Omg...thank you, I suffered a lot to get to this post...Finally someone can explain this. I think I will create an identification rule on the child class just to uniquely identify the serial number and not the serial vs type as in the hardware parent rule fails...