Content Library Template Renamed but Datastore Folder Not! How to keep these names in sync?

[GeoPerkins]

We use Content Library for version control and multiple vCenter synchronization of template images.

Process is to create a new Template using the Content Library version control procedures. This creates a Guest VM for customization using the normal "Create VM from this Template" wizard. The first form in the wizard prompts for a Guest VM name. Any random name will do. A folder is created on the Datastore with that random name. After customization, the Guest VM is shutdown/powered off. The Guest VM is then converted back to a Template by the Content Library wizard. The Template listed in the GUI is renamed with a parenthesis and number, for example, "(5)" as the fifth version/generation of the non-randomly named Template series, for example "Windows Server 2022 Standard Template (5)". But the Datastore file associated with the Template is not renamed and remains named some random (sysadmin-provided) value. The Datastore then contains with duplicate folder names which vCenter avoids conflict by appending an underscore number, for example, "_2" which further increases the confusion.

Apparently, there is no automated relationship between the "(5)" and "_2" or between the original Template name and the sysadmin-provided "random" Guest VM name!

Other than training all sysadmins to be very careful, keep their names strictly in adherence to an arbitrary standard, I don't see a fix for this. Am I missing something obvious?!?

In the screenshots below, the only matching Template object and Datastore folder match because the sysadmin took extreme care to assign a Guest VM with the anticipated Content Library object name and versioning value!

[Brisk]

This is the same behavior you get when you rename a VM in your regular inventory. When you rename a regular VM, the folder name will only change after a storage vMotion.

If you want to have it renamed here you probably need to remove the item from the CL and add it back again.

[lamw]

You won't be able to keep these in sync as the underlying files are NOT renamed due to filelocks and this behavior is simliar to a non-Content Library VM where you rename using UI/API, but the underlying files are NOT unless you Storage vMotion. Since you're using the CheckIn/CheckOut feature, you definitely don't want to manually change files (as suggested in previous reply) as this will cause Content Library to lose track of these files (which I'm assuming you don't want). 

Hopefully admins aren't manually deleting files directly in vSphere Datastore, but if that's a concern or if you want to know the list of files and folders that's used by these CheckIn/CheckOut images, you can always use the vSphere API to query for the files simply by providing the name of the VM Template. 

For example, I've got Dummy (4) and Dummy (5), here's simple PowerCLI snippet that'll provide you all the files used:

# (Get-Template "Dummy (4)").ExtensionData.LayoutEx.File

Key             : 0
Name            : [sm-vsanDatastore] 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa/D2.vmtx
Type            : config
Size            : 0
UniqueSize      : 0
BackingObjectId : 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa
Accessible      : True

Key             : 1
Name            : [sm-vsanDatastore] 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa/D2.vmsd
Type            : snapshotList
Size            : 0
UniqueSize      : 0
BackingObjectId :
Accessible      : True

Key             : 3
Name            : [sm-vsanDatastore] 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa/D2.vmdk
Type            : diskDescriptor
Size            : 0
UniqueSize      : 0
BackingObjectId : 9fe1cc64-c65a-4b95-4d34-ac1f6b1a4efa
Accessible      : True

Key             : 2
Name            : [sm-vsanDatastore] 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa/D2-000001.vmdk
Type            : diskDescriptor
Size            : 0
UniqueSize      : 0
BackingObjectId : a0e1cc64-2db3-41c3-21e7-ac1f6b1a4efa
Accessible      : True

Key             : 4
Name            : [sm-vsanDatastore] 98e1cc64-ca82-2ba3-b353-ac1f6b1a4efa/D2-Snapshot1.vmsn
Type            : snapshotData
Size            : 10608
UniqueSize      : 10608
BackingObjectId :
Accessible      : True

As you can see from the output, there's a number of interesting/useful fields but Name property will give you full path to datastore files