Thought I'd share this as well, discovery is supposed to find serial number information from a quite a number of places, rather the system enclosure, baseboard and probably another. The serial numbers are not consistent with regards to where it finds at the first instance. A CI's serial number from a system enclosure is different from the serial number from the baseboard.
Is there a way to get away with this. Though I change the serial number manually (after initial discovery) and keeping in mind that I have CI consolidation(source to target), it is still going to populate the baseboard serial number (second discovery) (if i'm not wrong).
Any views on this?
Is there a way to get away with this. Though I change the serial number manually (after initial discovery) and keeping in mind that I have CI consolidation(source to target), it is still going to populate the baseboard serial number (second discovery) (if i'm not wrong).
Any views on this?
Here's the deal: Discovery will always fill the serial number field with whatever value it finds (assuming, of course, that it finds one at all). So you are correct that if you were to manually enter a serial number, Discovery would overwrite it (on the next discovery) with whatever value it discovered. That is, after all, the entire purpose of Discovery!
However, for any field you have at least a couple of options for modifying this behavior.
The easiest option (and the one I recommend, as it is simple and foolproof) is to create your own serial number field. Let's say you call it "u_serial_number". Discovery will keep right on filling in the standard serial number field, but it won't touch the one you've created. Then you can add a simple business rule to fill in u_serial_number if it is currently empty and the standard serial number field has just been filled in. Presto! You've got the best of all worlds: your manually entered data when necessary, the discovered data for other times, and the exact behavior you'd like to have.
Another option is to write a somewhat fancier "before" business rule that figures out the right thing to do with serial numbers. For instance, you could write a business rule that looked at the make and model of a computer, and decided from that which serial number to use. All of the discovered serial numbers are recorded in the cmdb_serial_number table, which contains a serial_number_type field that tells you where the serial number was found, a serial_number field for the actual serial number, a boolean valid field that is true for any serial number assessed as valid, and a cmdb_ci field that refers to the CI the serial number is for. The logic in this business rule could get somewhat tricky, and would probably need to be updated as your organization added more and newer models. You could even combine this method with the first method described above.
