Hey there ,
The behavior you are seeing is almost certainly caused by orphaned or duplicate Custom Field definitions in the vCenter Database that share the exact same display name but have different internal ID keys.
Because RVTools and PowerCLI query the vSphere inventory differently, PowerCLI consolidates them while RVTools maps out the raw metadata table directly.
Here is the breakdown of why this happens and how to fix it .
The Root Cause: At some point, a custom field was likely deleted and recreated with the exact same name, or a scripting/syncing error generated a duplicate entry directly into the vCenter underlying database.How RVTools reads data: RVTools pulls the raw schema from the API (AvailableField and CustomValue). It loops through every field ID it finds and creates an Excel column for it. Since there are two separate field definitions in the backend with the same name, it generates two columns.
The "inconsistent entries" happen because some VMs are tagged with the old ID, some with the new ID, and some with both.How PowerCLI / vSphere Client reads data: The vCenter UI and high-level PowerCLI cmdlets (like Get-Annotation) map attributes strictly by their friendly string name.
If two fields have the exact same name, PowerCLI typically matches the first one it finds or combines them into a single visual instance, masking the database-level duplication.
How to verify and find the duplicate IDsTo see the hidden IDs causing this mismatch, you need to look at the ExtensionData using PowerCLI
powershell
# Get all defined custom fields and look for duplicate names
(Get-View CustomFieldsManager).Field | Select-Object Key, Name | Group-Object Name | Where-Object {$_.Count -gt 1} | Select-Object -ExpandProperty Group
What this will show you:If this is the issue, the output will display two (or more) rows with the exact same name but different integer keys e.g., Key 101 and Key 204.
How to Fix ItTo fix your inventory before running your PowerCLI update script, you need to consolidate the data into one field and delete the orphaned attribute
Identify the "Good" vs. "Bad" field: Use RVTools or the script above to see which column contains the accurate, up-to-date data. Note the integer Key of the one you want to delete.Migrate the data (if necessary): If the old column has values you need to preserve on older VMs, you can target it specifically via its unique Key using PowerCLI's view object to copy the string data over to the active attribute.Delete the duplicate definition: Once the data is consolidated, safely remove the unwanted attribute using its specific ID key so you don't accidentally drop the good one
$cfm = Get-View CustomFieldsManager
# Replace 101 with the exact ID Key of the duplicate field you want to remove
$cfm.RemoveCustomFieldDef(101)
Once the underlying duplicate definition is removed from the CustomFieldsManager, a fresh RVTools export will instantly clear up and match your PowerCLI environment.
To help you get this cleaned up safely, can you share
What version of vCenter you are currently running?
Roughly how many VMs are showing entries split across both columns?
Thank you