Vmware discovery

[nikhil73]

Hi Everyone,

We have vmware esx servers in our envionrment that we are trying to discover through vcenter and vmware esx host probes, discovery works fine and brings back all the meta data for each esx server that reports to the vcenter, one of the field it bring backs for esx host is service tag as serial number, wondering is there a way to bring back Product Serial Number Tag (PSNT) as serial number instead of service tag?

Thanks in Advance,

Nikhil.

[Mannapuram]

Hello,

There are two parts to this. Is the PSNT is sent from esx server --> vCenter --> Mid server/Servicenow? If yes, then mapping in Servicenow need to be checked on. If no, then it has to be extracted from the esx Server using a custom Pattern and update the CI class.

If it's already sent using Probe and Sensors, then the Script include called in Sensor need to be checked. 

[AJ-TechTrek]

Hi @nikhil73 ,

Why you see Service Tag as serial_number as per my understanding :-

When ServiceNow discovers ESXi hosts through vCenter, the discovery uses vCenter’s VMware API (vim.HostSystem.summary.hardware.otherIdentifyingInfo) to pull metadata.
vCenter usually exposes:
* service tag as serial number
* Sometimes PSNT is in another field, but vCenter doesn’t always map it to the main serial number property.
By default, the VMware ESX Host pattern in ServiceNow maps the service tag to the serial_number field in the cmdb_ci_esx_server table.

Solution: How to bring Product Serial Number Tag (PSNT) instead:

Option 1: Extend/Customize the Discovery Pattern
1. Go to Discovery Patterns > VMware ESX Host.
2. Debug the pattern:
* See all attributes collected from the vCenter API.
* You might see the PSNT value under otherIdentifyingInfo or uuid or another attribute.
3. Modify the pattern:
* Instead of mapping the service tag to serial_number, map the PSNT attribute.
4. Save and test:
* Run discovery for a small set of ESXi hosts.
* Confirm the serial_number field now gets the PSNT.

Option 2: Use an Identification Rule override
If you prefer not to change the pattern:
* Keep the PSNT value in a custom field (e.g., u_psnt) via the pattern.
* Update the Identification Rule for ESX hosts:
* Change the rule to use PSNT as the identifier instead of service tag.
Note: Only do this if PSNT is guaranteed to be unique & populated, and you don’t break existing reconciliations.

Option 3: Discover directly with credentials
If you can get SSH or CIM credentials directly to ESXi hosts:
* Direct discovery can pull more accurate hardware info from dmidecode / CIM.
* Usually gets the true BIOS serial or PSNT rather than the vCenter service tag.

Important considerations:
* vCenter may not always expose PSNT via API — depends on VMware version & hardware vendor integration.
* Changing patterns or ID rules should be tested carefully in non-prod.
* Document the change to help future admins.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025