Chassis SN vs System Serial - Which is used

[cyked]

I'm not successfully finding where current.serial_number or serial_number is set on a server CI.   System serial number is being used to populate the serial number field on a server CI rather than Chassis.   Is there a reason discovery prefers system serial number over chassis?   I can think of reasons where you could get in trouble, but know that bios/uuid/chassis/system are all retured from the hardware info probe.  

Where do I need to look to see where serial_number is set on a CI?   Trying to reverse-engineer this to understand the functionality better and determine if we can flip the order (use chassis more prevently) and what sort of issues we'd run into by doing so.

[doug_schulze]

Drew, you have to dig around the identification processing (sensors/Script includes) and I 'think' it happens in some java magic call named SncSerialNumber() .. I started asking around to be sure but in the mean time what I have done in the past is to create an exploration probe that sets serial number after the fact to the value you want.. Or you can probably do a after update BR that sets a different value on the class based on the lookup it would do..

[cyked]

Thanks Doug.   I'm looking at the SerialNumberManager script include, and the WMI Probe for hardware information.  

On the WMI probe, it adds the SN values to an array (ComputerSystemProduct.IdentifyingNumber, UUID, BIOS, baseboard, and SystemEnclosure.SerialNumber, are referenced) which is used by the SerialNumberManager script include.   I found another script include called SerialNumber.   SerialNumberManager seems to me to be more related to the serial number table entry and values, and SerialNumber would actually set the CI.serial_number value.   I'm not a programmer to be sure, and trying to follow through this logically and doing so for me is clumsy at best.  

Ideally the SN on a Server CI would be the chassis number where possible, makes things easier for the infrastructure teams.   Thats the Serial Number on the box from the vendor, on the asset tag sticket on the server, etc.   Changing order here doesnt appear that it would be a huge impact in some cases since ALL serial numbers are returned on at least the WMI probe (all 3 can and are used during identification to find the existing CI, its just a matter of which one is being recorded on the CI.   Linux would be a different story I would think, given its usually a specific SSH command to get SN - ex. :   lsattr -El sys0 -a systemid | awk '{print $2}

[doug_schulze]

Drew,

You make a very good point what would you think if there were a property that allowed you to change which should be chosen first so you and I don't have to try and reverse engineer aleck.lin 's genius (he wrote it )

[cyked]

Sounds good to me.   Always more than one way to skin a cat.   In our dev instance, I moved:

if (JSUtil.notNil(output.Win32_SystemEnclosure.SerialNumber))

                      snm.add('chassis', output.Win32_SystemEnclosure.SerialNumber);

....to the top of the WMI Windows - Identity probe (so its above the system and UUID serial) and ran discovery.   its showing the Chassis serial on the CI now.   on VMs chassis serial is recorded as (none) so its skipped (JSUtil.notNil).   Its still recorded on the serial number table for use if needed, but since chassis is first in the probe list its skipped over until it gets to the VMWare- Serial Number to be recorded on the CI record.

EDIT: I'm noticing on the serial numbers record (on SN table and Server CI) that some of the serial numbers have trailing white space.   like "USE741234           ".   System SN seems to be the   exception.   System SN will be "USE741234" and bios and chassis will be "USE741234           ".   Haven't looked into the code to see why though.