The guest OS (Windows) will never write the disk UUID/Serial to the VMX because the vmx has not been reloaded.
The snapshotting process will see that the parameter is set to true and attempt to quiesce, but it will fail because no parameter exists (due to 1 above).
The correct resolution is to reboot the VM (so the vmx is reloaded) and the guest OS writes the Disk UUID/serial. Then the backup/snapshotting process will read this value and be able to successfully quiesce.
There is a non disruptive workaround, and that is to edit the vmx and set the disk.enableUUID value to false, then vMotion the vm (to any other host), to reload the vmx in host memory. This effectively disables application level quiescing (file system quiescing is still available though). This can be done in bulk via PowerCLI and non-disruptively (while the VMs are powered on).
There is also another method to reload the vmx file with the vm remaining powered on detailed in KB article: Reloading a vmx file without removing the virtual machine from inventory (1026043).
Also, see the “cause” and “resolution” sections of KB article: Taking a snapshot of a virtual machine after a Storage vMotion on an ESX/ESXi 4.1 or 5.0 host fails (2009065).
I have some VMs that I couldn’t never get a VDP backup working on it, until I set this freaking EnableUUID to false… That’s a bug and I’ll have to live with it?
On of the VM’s that I can’t backup is a Windows 2012 and as recently created, and rebooted a lot, so I don’t think that this particular behaviour that you outlined is the one that is happening to me, although the solution was the same.