Asset Creation for CIs with Duplicate Serial Numbers Across Different Classes

[AnushithaS]

Hi Team,

We have a requirement to create assets for Configuration Items (CIs) that have duplicate serial numbers but belong to different CI classes.

For example, the same serial number exists for both an Out-of-Band Device and an ESX Server. Currently, an asset has been created only for the ESX Server CI, while no asset has been created for the Out-of-Band Device CI.

Since these CIs belong to different classes and represent different assets, we require asset records to be created for both CI classes, even when the serial numbers are identical.

Could you please help us understand if this can be enabled and advise on the appropriate approach to create assets for all such CIs?

Thank you for your assistance.

[kmohammed]

Hi @anu**bleep**haS,

This is the out-of-the-box asset creation logic working on serial number alone, not on class. When a CI qualifies for automatic asset creation, the platform first checks whether an asset with that serial_number already exists in alm_asset / alm_hardware. The check is not scoped by CI class, so once the ESX Server got the first asset for that serial, the Out-of-Band Device CI is treated as 'asset already exists' and no second asset is created - even though, as you say, they are different CIs in different classes. There is no system property or class setting that simply switches this to 'one asset per CI'.

First confirm that is what happened in your instance:

1. Query alm_hardware / alm_asset for that serial_number - you should find exactly one asset, with its Configuration item field pointing at the ESX Server CI.

2. Also check the Out-of-Band Device CI's class is actually set up for asset creation (its class must be asset-tracked and have a model category mapping, like the ESX Server class does) - rule this out before customising anything, because a missing class mapping produces the same symptom.

Your options, in order of preference:

Option A - supported, for the affected records: create the second asset manually and link it. Create a new asset record for the Out-of-Band Device (from the CI record or a new alm_hardware record), set its Configuration item field to the Out-of-Band Device CI, give it the same serial_number but a unique Asset tag. Manual creation is not blocked by the serial check that the automatic logic performs, and once the CI is linked to its own asset, normal CI-asset synchronisation keeps that link. Do not change or clear the serial on either CI to work around this - the serial genuinely is the same.

Option B - only if this pattern is frequent and must be automated: you would need to customise the asset creation logic so it checks for an existing asset by Configuration item (the CI's sys_id) instead of, or in addition to, serial_number alone - i.e. create an asset when THIS CI has no linked asset, regardless of another CI sharing the serial. Treat this as a real customisation: it diverges from the synchronisation logic that assumes serial identifies one asset, it will be at risk on upgrades, and it must be tested for the reverse case (one CI being re-discovered must still not create repeated assets for itself).

One data caution before choosing B at scale: a shared serial between a host and its out-of-band management device is common (the management card reports the chassis serial), so for at least some of these pairs the business may actually want one physical asset with the management device tracked as a related CI, not two financial assets. Agree per class pair - ESX Server vs Out-of-Band Device in your case - which pairs genuinely need separate assets, and apply Option A (or B) only to those.