VM encrypted itself, don't know the password (part.2) (after 13.5 update)

[digifox55]

Hello, I read these topics: VM-encrypted-itself-don-t-know-the-password  and VM-asking-for-password but I still need help.

I updated Fusion 13 Pro from v. 13.0.2 to 13.5 a few days ago. I have a M2 MacBook with Sonoma, and run several vms of Win11 ARM.

After updating I noticed that I could only open my default vm file, all the other vms raised a popup saying "The virtual machine "Windows 11 64-bit arm" is encrypted. You must enter its password to continue.". I am sure I had never enabled encryption before. In fact I could close and reopen my default vm with no password prompt.

After noticing that my def-vm wasn't properly scaling the resolution anymore (no way to stretch it to fit it to the window), I decided to downgrade to 13.0.2. As soon as I went back to 13.0.2 not only my other-vms kept asking me the password, but also my def-vm has become encrypted with the same prompt. I went back to 13.5 again and def-vm is still encrypted.

Any ideas to recover my instances? Could a full macos time-machine backup lead me to a point where the vms aren't encrypted?

Thank you so much in advance!

[ColoradoMarmot]

You had to enter a password to create a Windows 11 ARM VM, and optionally saved it to the keychain.    You can check keychain access to see if you saved it there.

Time machine is unreliable to restore virtual machines, but there may be other workarounds if you can't find the password.

[bluesky2000]

I have the same problem...

[VMware Community Member]

Same problem, started to create an ARM 64 version of Windows 11 on my new Mac M3 when none of my old x86 machines that I moved over would work.... dumb me... and now I can't get back into the "new" ARM machine without a password that I didn't create in the first place?  Is there a cookbook version for this solution for a machine "rookie".  Your exchange is at the upper end of my expertise.... sorry to say.  It's clear to me that Apple didn't give cx&p about people using their machines for critical apps that run in production under a VM setup???

[Technogeezer]

When creating a virtual machine for Windows 11 ARM using the Fusion wizards, you had to select what style of encryption to use for the VM. It also asked you to either provide an encryption password or to auto-generate one. If you auto-generated one, the password is displayed. for you.

It also provided a box to save the password in the Mac's keychain. I believe that this is set by default. If you unchecked  this box, a warning was blasted out that if you don't remember the password, your data will be lost. 

I hope you did not simply "click through" these things without understanding what you were doing. 

If you left this box checked, your VM's password is saved in the Keychain.  If that occurred, use  the Mac's Keychain Access utility to open the keychain, and search for "VMware Fusion Encryption" entries. If you highlight it, the "Where" field in the entry will point to the VM it's holding the key for. You can display the password from there.

My "cookbook" solution to the problem is for you to remember the password for the VM in the password management system of your choice after either typing it in yourself or auto-generating it (remember, it will be displayed for you to remember should you auto-generate it). Don't rely on the Keychain  - you always need a backup for anything you do on a computer to cover the "just in case" scenarios. 

You might want to take a look at the available Fusion and macOS documentation to move yourself from being a "rookie" and move the upper end of your expertise.  You'll get more out of Fusion and macOS if you do. 

[CATTS-IT]

Hi Paul, 

I understand all that, the issue I have is that an update of Fusion resulted in an unencryoted VM being encrypted without my knowledge during the update process.  This is certainly an undocumented "feature" which should have been publicised to ensure that users werent caught out, losing access to their VM's which in some cases may have had important configs or data within them.

I investigated this at length and was unable to get access to my original VM resulting in having to build a new replacement VM, which I was asked to provide an encryption key for this time.  The Macs Keychain had nothing relating to this in it.

So to summarise, this is a failing in the Fusion update process, documentation and Read-me info which should have been published and provided this bit of important info. Having started my career in computing back in 1979, I have worked with VM's from Mainframes through to todays versions and so dont believe I am a 'rookie' as such.  No previous Fusion update has automatically encrypted a VM so why would I have expected this particular update to cause to much grief.  The other factor was that even going back to an unencrypted back up resulted in the VM being locked whn I restored it.

[Technogeezer]

My understanding was from my last response was that the poster immediately prior to my response had created a brand new VM in Fusion 13.5. I may have misunderstood that post for which I apologize. 

I will agree with you that there is a failure in VMware’s upgrading to the new encryption that bricks a working VM. It’s compounded by VMware’s broken experimental vTPM in Fusion 12 and then encouraging people to use it. That alone was guaranteed to cause problems in the future for anyone that used it.

I’m still curious about the cases where Fusion 13 and later has “automatically encrypted”  a Windows 11 VM without the user’s knowledge. A new Windows 11 VM in Fusion 13+ will have encryption applied (because the TPM is automatically included for windows 11) but the user should be prompted for the type of encryption and the key. An unencrypted VM should not be subjected to the new encryption conversion since it was never encrypted in the first place unless there something else amiss that isn’t obvious.

Does anyone have a “before” .vmx file from a backup of a VM taken before an upgrade, and then an “after” .vmx file where the VM has “encrypted” itself? Or has a problem with the encryption? 

 

[CATTS-IT]

I have the same issue, previoulsy used my VM prior to Somona and the VMFusion update OK, never set a password on VM creation way back when.  I have checked my Keychain and only have an entry for VMWare Fusion Encryption Key...

How can this be applied without some warning or prompt? And more importantly how do I get access to my VM back without having to spend hours re-creating it...  I have tried restoring a backup of my VM file, but it has the same problem when I try to access it.

I also tried the editing of the process suggested here - https://communities.vmware.com/t5/VMware-Fusion-Discussions/VM-encrypted-itself-don-t-know-the-password/td-p/2874949 even though it dates back to 2021 and my issue started earlier this week.

[Technogeezer]

VMs do NOT encrypt themselves.  Encryption being enabled is either a choice that you made, or was made for you when you created a Windows 11 guest operating system with Fusion 13. In either case, you're prompted for a password (or offered to auto-generate one) and offered to save it in the Keychain.  You get a very stern warning if you do not offer to save the key in the keychain.

Take a look at that entry of "VMware Fusion Encryption Key" in the Keychain. You'll find that the "Where" field points to the .vmx configuration file of the VM, and if you double click  the item and click on the "show password" buttion, you'll see the password. 

The old full VM encryption feature also asked you for an encryption key when you turned on the encryption.

The only time that Fusion encrypted a VM "by itself" with a key that you didn't specify is if you made the unfortunate choice (or mistake) of enabling the experimental partial encryption feature of Fusion 12 or Workstation 16. Even then, it didn't do things by itself - you  had to go out of your way and manually edit the .vmx file in order to enable that feature. The feature wan't ready for prime time and was a one-way street to problems. 

Fusion 13.5 does not upgrade the encryption scheme to the new XTS encryption unless you tell it to. It will not apply that to an unencrypted VM. 

If you've partially encrypted the VM "Only encrypt the files necessary to support a TPM" - then the VMDK files of the VM are not encrypted. A new VM can be created and the virtual disks "transplanted" from the old VM into the new one. If you've fully encrypted the VM and forgot/don't have access to the password - you've hit a brick wall. 

[VMware Community Member]

I have had the same issue with an update to 13.5.1, which has encrypted my VM for some reason. I have been using this VM for a year or so and it's never asked for a password before this morning when I got to site.

[Technogeezer]

 can you provide more details? What OS is running in the guest VM? Can you post the .vmx file of the VM and how the virtual hard drive is configured (single file or split into multiple pieces)?

[CATTS-IT]

Thanks, however I did not make a choice nor was there an issue with the VM prior to this week following the update.

The VM was originally created in 2021 (in whatever version was available for MAC at that point) and I have been using it since then with no issue, there was no stern warning about a password when it was originally created.  It was only since the update to VMware Fusion Pro 13.5.0 that I have been prompted by this mesage to enter a password that I did not set.  

The keychain info looks like this, see attached screenshots

  - no password ...

[Technogeezer]

That's indeed very strange.

You wouldn't happen to have a copy of that VM and its .vmx file available from before the 13.5 update, would you? Just would like to take a look at it.

[CATTS-IT]

Hers the VMX file, its from my last backup from 27 September which was before the latest VMware update (which I installed yesterday). 

Attachment(s)

WIN11-UEFI.vmx.zip   5 KB 1 version

[Technogeezer]

Well I understand what's going on now...

The VM was encrypted with the experimental vTPM implementation of Fusion 12.2. That's evident by the presence of the following line in the .vmx file

managedVM.autoAddVTPM = "software"

The system did auto-generated the encryption key for you without your input. It didn't automatically encrypt the VM though. The vmx file had to be hand edited in order for the encryption to be enabled. The experimental vTPM did not have a GUI setting to enable it. 

That vTPM should never have seen the light of day nor should anyone have used it. As I said, it's a one-way street. One of the huge failures of that implementation was that it autogenerated the encryption key and didn't give you any way to know what it is. The second big failure of the implementation was that the auto-generated encryption key is tied to the system somehow - meaning you can't easily move the VM to another machine.

Those defects were fixed in Fusion 13 and Workstation 17. Since those releases didn't change anything, all worked fine. But it looks like if you try to upgrade to Fusion 13.5 and then try to upgrade the encryption algorithm of a VM using that broken feature, that's where the problems occur. 

Did you notice if Fusion 13.5 asked you to upgrade the encryption the first time you powered on the VM after upgrading the Fusion release?

I'd recommend any user that had the experimental vTPM enabled to back up all the files within the VM before upgrade. Then rebuild the VM under Fusion 13.5 using the partial encryption option. 

You may wish to view a blog post by Wil van Antwerpen https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/ abut the subject and you'll get an idea of just how broken that feature is. He also has some discussion about how to recover from that mess but there is "some assembly required".

 

 

[CATTS-IT]

Hmmm, I wonder if I edit the vmx file and removed those lines before placing it into the Vmware folder and then trying to open it?  Will give that a go and let you know.  I did have a look at the article you mentioned prior to finding this forum.  I tried some of that but it didnt work as the VM file was already in the folder.

Thanks for your insight.

[CATTS-IT]

Nope, that didnt work.  I have now created a new VM and will try moving the disk files from the original into that one.

[CATTS-IT]

So that didnt work either, still got the password message and couldnt open the VM.

I have created a fresh VM and put everything back.  Very dissapointed that this has been forced on people without warning.  

[jhuertaNU1996]

I am having the same issue after upgrading my VMware Fusion Player version to 13.5 on my work Macbook Pro.  Prior to updating, I did not do anything with encrypting the VM, including creating an encryption password.

At Home I have another Macbook Pro that when I opened VMware, it popped up a window stating that there is a new update.  After it downloaded, it asked for me to quit VMware and relaunch.  However I did notice that it mentioned that doing so would auto-generate an encryption password.  But it did not say or show anything about saving the password, simply continue or Quit.

[jhuertaNU1996]

Here is a copy of my .vmx file.  It does not contain the line

managedVM.autoAddVTPM = "software"

But it does have a line "vtmp.present = "TRUE"", as well as "vmx.encryptionType = partial", and "vtmp.ekCSR = "some long data encrypted text", and "encryption.keySafe = "vmware:key/list/(pair/(phrase/some long data encrypted text".

 

 

Attachment(s)

Test Windows 11 64-bit Arm.zip   4 KB 1 version

[Technogeezer]

Prior to updating, I did not do anything with encrypting the VM, including creating an encryption password

.The .vmx file says otherwise. This VM is partially encrypted. It did not get that way automatically.

Can you clarify what VM this is from, and is it before or after the Fusion upgrade and accepting any re-encryption and VM upgrade requests?

If you want to clean things up, you can create a new Windows 11 ARM VM using "Create a Custom Virtual Machine". Answer the operating system type and encryption dialogs.  then when it asks you to select a virtual disk, opt to use an existing virtual disk, locate the vmdk files of your old VM, and elect to copy it into the new VM. You may need to edit the vmx file and change the uuid.bios, uuid.location, and ethernet0.generatedAddress values to match the old VM before you power the new one up. 

[jhuertaNU1996]

This VM is from Fusion Player v13.5.  This encryption came up after the upgrade to 13.5 in which I did not see anything about re-encrypting.

I'll try creating a new ARM VM and use the vmdk files being used by this encrypted version.

 

Thanks for your input.

[Technogeezer]

Do you have a copy of the VM from before you upgraded? (Please say you do... that's always a best practice for any software to make sure you have backups of things before you start and upgrade because you want to make sure something doesnt come around and bite you during the upgrade).

What Fusion version did you upgrade from?

[jhuertaNU1996]

Nope, I did not create a backup of the VM prior to having it password protected.  I ended up having to re-create a totally new VM, where it did have me add an encryption password. I should be good to go, and will also create a backup.

Thanks again for all your input.

[gringley]

I am wondering too.  I have a bunch of VMs that used the 12.2 encryption. In 13.5 they had been prompting to upgrade encryption and I would skip it.  Today being the first time I opened a VM in 2024 it wants the VM encryption key and all of them are broken this way now.  I can see I have in keychain virtual machine passwords and a private key for VMware Fusion Encryption Key - but I take it once these things quit working there is no recovery?

Update:  I realized I had tied the VMs to OneDrive accounts and by creating new ones with the same Microsoft accounts I got all the files back.  The Windows 11 Home did refuse to activate - but when I clicked on the hardware changed option it showed me a list of other VMs and PCs I had activated using the key.  I selected the VM that I was replacing and tada Windows activated.  I did have to reinstall apps but that went OK also - except that the store app prompting me I had it installed on ten instances.  Like the activation I could click though to see a list of the VMs and PCs going back to 2015 and delete all the ones that no longer existed.  I usually do a clean start on these VMs once every few years anyway so not it is done for the 2020s.

[Jacinto Perez Calavera]

I have the same issue. vmware fusion 13.5.1 (23298085) and Windows 11.

I can't believe that upgrading a software product encrypts the hard disk and doesn't provide/save the password. I followed the suggestions of VMWARE to encrypt, and I have been trapped in a nightmare, without any manufacturer solution!!!.

I'm very disappointed with the product and with the support. It's highly below a professional quality standard. 

[Technogeezer]

I’m grasping at straws a bit here.

Was this VM created fresh and installed from ISO, or was it a converted VHDX file (a Windows Insider Preview).

Do you have a copy of the VM from before the upgrade? If so, it would be interesting to examine both the .vmx file and the VMDK fike descriptors to get some kind of indication of why the VM got automatically encrypted.

Did this VM have a TPM device before upgrade?

Did you open a support case with VMware? This isn't an official VMware tech support forum. 

------------------------------
- Paul (technogeezer)
------------------------------

[Fred Macondray]

Greetings,

I'm having a related situation with a client.  Fusion 3.6.5, Win 11 VM.   It started asking to upgrade the encryption from CBC to XTS.  The user had been clicking cancel, but yesterday Fusion will crash upon either choice.  

If we cannot determine why it's crashing.  That would leave removing the TPM and trying to get the system to boot.  

Encryption is only enabled as required by the vTPM.

We have a recent backup via Veeam agent, but it's 5 days old and we're attempting to restore it to Hyper-V.

Ideally, we can get past that crash error and remove the encryption gracefully.

Any ideas are welcome!

Fred

[Fred Macondray]

Greetings,

We're in a situation that seems related to this post.  Fusion 13, Windows 11 VM.   We do have the password, however the message alerting the user to the need to upgrade the encryption from CBC to XTS both now produce a predictable crash of Fusion.

The VM is confiugred only for TPM related use, drives are not encrypted.

If we cannot get past the error, we may need to try removing the TPM and Encryption.  I'm not sure this is safe.

We are now restoring the system to Hyper-V as a quick user access solution, but I would really like to know how to make that upgrade dialog work.

Any ideas?

Thanks in Advance,

Fred

[Technogeezer]

@Fred Macondray

"Fusion crashed" is a very vague description. 

More details would help:

• What is the exact version of Fusion you're using?
• What's the macOS version and Mac model that you're using?
• What build of Windows 11 is being used in the VM?
• Can you provide details on how the virtual machine is configured. Attaching the .vmx file for the VM would help (found in the VM's bundle).
• Is the VM partially or fully encrypted?
• I'm assuming that since you say you have the VM's encryption password, you did not create this VM on Fusion 12 and used the "hack" of editing the .vmx file to enable a (broken) "partial encryption" preview feature?
• How is the virtual disk is configured (size and if it's configured to break up the disk into pieces). A file listing (using the ls-alR path-to-vmwarevm-file in a Terminal window, not a screen shot of the Finder window) would be helpful.
• Any snapshots active for the VM?
• Is the VM stored on a folder that's configured for cloud storage sync'ing (e.g. OneDrive, iCloud, Google Drive, Dropbox), or on anything other than a local drive formatted as HFS+ or APFS?
• What are the exact steps that the user is performing?
• What exactly was the crash message.
• Can you provide Fusion logging? (the ~/Library/Logs/VMware Fusion/vmware-vmfusion*.log files and the vmware*.log files found in the VM's bundle)
• Is the encryption crashing Fusion or does the encryption complete and then the VM crashes?
• Is there sufficient disk space to hold a complete copy of the VM during the re-encryption process?

It's generally safe to remove the encryption on a Windows 11 VM. But you need to remove the TPM device first. Then decrypt. Then re-encrypt the VM and add the TPM device back in. (Windows 11 doesn't like to run without a TPM device). This is usually not much of a problem -- except if you have BitLocker enabled in Windows. You'll shouldn't try to remove a TPM device from a VM with BitLocker enabled without making sure you have the BitLocker recovery key (either printed, saved to a thumb drive, or available in the user's Microsoft Account). Removing a TPM device is like swapping motherboards on a PC - the TPM is wiped and you'll need that recovery key to get access to the BitLocker enabled VM once the TPM is added back to the configuration.

------------------------------
- Paul (technogeezer)
------------------------------

[Fred Macondray]

More details would help:

• What is the exact version of Fusion you're using?
  • 13.6.2
• What's the macOS version and Mac model that you're using?
  • 3.7.2
• What build of Windows 11 is being used in the VM?
  • Microsoft Windows 11 Pro 10.0.22621
• Can you provide details on how the virtual machine is configured. Attaching the .vmx file for the VM would help (found in the VM's bundle).
  • vmx attached
• Is the VM partially or fully encrypted?
  • Partially 
• I'm assuming that since you say you have the VM's encryption password, you did not create this VM on Fusion 12 and used the "hack" of editing the .vmx file to enable a (broken) "partial encryption" preview feature?
  • Correct
• How is the virtual disk is configured (size and if it's configured to break up the disk into pieces). A file listing (using the ls-alR path-to-vmwarevm-file in a Terminal window, not a screen shot of the Finder window) would be helpful.
  • Attached
• Any snapshots active for the VM?
  • No, only "current state"
• Is the VM stored on a folder that's configured for cloud storage sync'ing (e.g. OneDrive, iCloud, Google Drive, Dropbox), or on anything other than a local drive formatted as HFS+ or APFS?
  • No, just the local disk
• What are the exact steps that the user is performing?
  • Trying to launch the VM.  Before pressing play, the message to upgrade encryption comes up.  Choosing either button crashes Fusion.
    
• What exactly was the crash message.
  • No message, it just quits.
• Can you provide Fusion logging? (the ~/Library/Logs/VMware Fusion/vmware-vmfusion*.log files and the vmware*.log files found in the VM's bundle)
  • Attached
• Is the encryption crashing Fusion or does the encryption complete and then the VM crashes?
  
  • I think it's a pre-OS issue
• Is there sufficient disk space to hold a complete copy of the VM during the re-encryption process?
  • I believe so, there's 1.3TB free

Note that I did attempt removing the TPM chip but it had no effect on the message last night, but today I'm getting an unable to load error:




I imagine I will need to restore those files that were encrypted using the TPM?  

I have a TAR Export and an OVF export I can use.  Should I replace the TPM and the .nvram, vmss, mvx and vmsn files?

Thanks for your thorough reply!
Fred

Attachment(s)

vmware-vmfusion 2.log   114 KB 1 version

vmware-0.log   39.44 MB 1 version

Windows 11 x64.vmx   6 KB 1 version

vmdir.txt   6.12 MB 1 version

vmware.log   331 KB 1 version

vmware-vmfusion-1 2.log   225 KB 1 version

vmware-vmfusion-2.log   350 KB 1 version

vmware-vmfusion-2 2.log   350 KB 1 version

vmware-vmfusion.log   114 KB 1 version

vmware-vmfusion-0.log   305 KB 1 version

vmware-vmfusion-1.log   225 KB 1 version

vmware-vmfusion-0 2.log   305 KB 1 version

[Technogeezer]

All of the vmware-vmfusion*.log files are from 2022. Can you make sure that you've posted them from the /Home/username/Library/Logs/VMware Fusion folder -- the Library folder of the user that's running Fusion. 

I'd not trust an OVF export of a VM to be able to restore it -- especially if the source VM has a TPM device.

It might be better to re-create this VM. Since the VM is not fully encrypted, the .vmdk files are not encrypted. Create a new Windows 11 VM (Create a custom virtual machine in the "Select an installation source dialog"). Make it a Windows 11 VM so it will ask for encryption (partial encryption should be your choice). But instead of creating a new virtual disk, use an existing virtual disk. Locate the broken VM's virtual disk in the file selection dialog that appears (the dialog will let you drill into an existing VM's bundle file to find the .vmdk file),. Select the broken VM's virtual disk and make sure you elect to elect to make a copy of it for the new VM. That'll leave the original vmdk files intact. 

You may need to validate the user's login upon startup of this new VM since the TPM is reset. You won't be able to restore the old TPM from backup since it's encrypted with the old encryption method and keys.

------------------------------
- Paul (technogeezer)
------------------------------

[Fred Macondray]

We set the encryption password, but it doesn't say if the key is in there.  Would there be a separate entry?

We also have a veeam backup.   I didn't realize the key was not stored with the VM Bundle.
I will give making a new VM a try.  I saw a post about doing that and have been preparing.

I'd still love to know what was causing that dialog to behave that way.   Correct logs uploaded here.

BTW, your presence here makes me hopeful that the new "self support" system might be OK!

Thanks

Fred

Attachment(s)

vmware-vmfusion-2.log   101 KB 1 version

vmware-fusionStartMenu-1.log   11 KB 1 version

vmware-fusionStartMenu-2.log   15 KB 1 version

vmware-vmfusion.log   70 KB 1 version

fusion.log   3 KB 1 version

vmware-fusionStartMenu.log   980 B 1 version

vmware-fusionStartMenu-0.log   980 B 1 version

fusionUploadedData.log   36 KB 1 version

vmware-vmfusion-0.log   79 KB 1 version

vmware-vmfusion-1.log   106 KB 1 version

[Technogeezer]

Yes, encryption keys are not stored in the VM. If you chose to have them remembered, they're kept in the user's login keychain.

You might want to check the user's login keychain to see if there's an entry for "VMware Fusion encryption" is present. The "Where" field of those entries points to the associated VM.

If you're going to restore from a Veeam backup, then restore the VM's entire bundle to another folder and see if it'll power up -- assuming you have the password memorized or you can find the password for the original VM in the user's login keychain. But I wouldn't try stitching together .vmx et. al. files of a VM's bundle from a backup into an existing VM without preserving the original first. And verifying that your backup can power on.

I'm seeing some .vmx corruption in one of the vmware-vmfusion.log files you just posted. Without the .vmx file I can't tell what;s broken or if it can be repaired.  Duh. I just saw the .vmx file. Let me see if I can see what the power on is complaining about...

If the original VM's disks aren't encrypted, it's pretty quick to rebuild the VM with a copy of the original VM's virtual disks. 

I appreciate the positive comments about those of us here in the forum that jump in to help others. I do wish there was more participation by Broadcom folks though. There's only so much us mere mortal users know about the internals of Fusion -- and we do get issues that only that deep internals knowledge can help solve. 

------------------------------
- Paul (technogeezer)
------------------------------

[Technogeezer]

I just took a look at the .vmx file. Line 20 is corrupted. 

it seems to have a funky couple of bytes at the beginning of the line. The line should read:

nvram = "Windows 11 x64.nvram"

It might be a quick experiment to shut down Fusion completely, making a copy of this VM, manually fixing the .vmx file's line 20, then trying to power on the VM once more.

------------------------------
- Paul (technogeezer)
------------------------------

[Fred Macondray]

That got me back, I was wondering why today the vmx was corrupted.  It showed up in Fusion by path and not name.

Now it says encryption is enabled, but there's no TPM chip:

When I look at file dates in the bundle, only two files were changed after I removed the TPM chip.  I've considered replacing those files, but I suspect that might not work due to differences.

I'm working on moving TAR file as the system didn't let me import the drive due to disk space issues. 

[Technogeezer]

There's no TPM device in that VM's configuration file. You can verify this by going back to the VM's Settings and check for the existence of the TPM device. If you removed the TPM device, then yes, there most likely will be files changed in the VM bundle. 

At this point you could try to restore all the non-VMDK files in the VM from a backup. If you do that, you'd probably have to replace all the files not named .vmdk. There are some linkages between the vmx and the other files that I'd suspect might not be correct if you try to piece together individual files.  

You can also add the TPM device back to the VM since it's already encrypted. Go back to the VM's settings and click on the "Add device" button. You should see the TPM device available to add back into the configuration.  Once you power on the VM you have to treat the situation the same as a physical PC that has had its motherboard swapped and the TPM is now wiped. (the major thing to be aware of is if Windows has enabled BitLocker - you'd need the BitLocker recovery key in that case).

------------------------------
- Paul (technogeezer)
------------------------------