After changing password on my PC i suddenly get the message : This virtual machine is encrypted, and i must enter password.
I have never activated encryption on my Win 11 virtual machine so i don't have any password. It can be mentioned that something seems to have gone wrong when changing password on my PC as my windows user seems to have been reset. Everything works fine now except this win11 VM. I have another win 10 VM that still works fine.
Is there any way to open and run this VM ?
The configuration file (.vmx), can be opened without problems.
Thanks for any suggestions.
Hi,
First make a copy of your vmdk file.
Then create a new VM as follows:
- Create new VM
- Choose Custom
- "I will install operating system later"
- Microsoft Windows "Windows 11"
- Next, Next
- Encryption type: Only the .vmx --> generate the password (Copy the password and save it somewhere else)
- Next, next, next until you get to "Select a disk type"
- Choose "use an existing virtual disk"
- Browse to the vmdk
That "should" be it.
I just ran that same thing down here a minute ago, but unfortunately did not have enough free disk space on my experiment machine to complete the copy of the vmdk file and thus validate those steps.
But the above should be the easiest way to get back up & running.
The alternative involves hand editing files.
Which reminds that it is probably good to do this without having any other VM's running as they don't tend to appreciate running out of free disk space.
edit: Regardless of the error on my test VM down here. The test DID succeed, the error was bogus.
A few additional notes.
I had invalidated the encrypted password on the original VM, so as to replicate your scenario.
The new VM booted just fine.
The disk it is using is NOT within the VM's folder as it did not copy the vmdk (one of the reasons I ran this experiment), instead it is still at the old location.
So please check in the VM's settings where the vmdk is located. If it is still at the old location then you cannot delete the old VM ... as that is where the data lives! You can move the vmdk file(s) and update the reference in the .vmx file to get them local to the vm folder again.
Alternatively you can point to the copy of the vmdk file during creation, but the vmdk files still won't be local to the VM.
--
Wil
What version of Workstation do you have? What version was this Win11 VM built with?
It was built with version 17, not 100% sure which exact version. Now running in version 17.0.2
OK, just wanted to make sure whether you were using version 16's experimental TPM module, or version 17's better version. I can't answer personally as I'm staying away from Win 11 and Wks 17 myself.
Just a thought or two.
If you created the Windows 11 VM under Workstation 17, you probably have a virtual TPM device created by default. In order to support the virtual TPM device, the VM must be encrypted by Workstation. The recommended encryption setting is "only those files needed to support a TPM device".
You also have the option to have the VM's encryption key remembered. On Windows, that puts the key in the Credential Manager. It's a good idea to create the key yourself and stash it away - or record the encryption key auto-generated by Workstation if you decided to do that. If the key is remembered, the startup of the VM will access Credential Manager for the encryption key so you don't have to type it in again.
You stated that the password change "reset the user". Perhaps the reset of the user also reset the Credential Manager for the user. Which would mean that if you opted to let Windows remember the VM's encryption password, the password was "forgotten" if the Credential Manager was reset. In that case Workstation has to ask you for the password because it couldn't find it in the Credential Manager.
That sounds like a plausible theory. You are correct that credential manager was also empty after my password was changed and user was "reset".
I guess this means it's no way to access the VM again ?
I think it may be possible, but it's going to take a bit of work.
You may be able to create a new virtual machine and then "stitch" in the individual slices of the original VMDK file since they are unencrypted - only the virtual disk header files are encrypted when you use partial encryption..
If you can post the .vmx file of the broken VM along with a file listing of all the files in the VM's folder, we might be able to give you some guidance on how to fix things up.
Hi,
First make a copy of your vmdk file.
Then create a new VM as follows:
- Create new VM
- Choose Custom
- "I will install operating system later"
- Microsoft Windows "Windows 11"
- Next, Next
- Encryption type: Only the .vmx --> generate the password (Copy the password and save it somewhere else)
- Next, next, next until you get to "Select a disk type"
- Choose "use an existing virtual disk"
- Browse to the vmdk
That "should" be it.
I just ran that same thing down here a minute ago, but unfortunately did not have enough free disk space on my experiment machine to complete the copy of the vmdk file and thus validate those steps.
But the above should be the easiest way to get back up & running.
The alternative involves hand editing files.
Which reminds that it is probably good to do this without having any other VM's running as they don't tend to appreciate running out of free disk space.
edit: Regardless of the error on my test VM down here. The test DID succeed, the error was bogus.
A few additional notes.
I had invalidated the encrypted password on the original VM, so as to replicate your scenario.
The new VM booted just fine.
The disk it is using is NOT within the VM's folder as it did not copy the vmdk (one of the reasons I ran this experiment), instead it is still at the old location.
So please check in the VM's settings where the vmdk is located. If it is still at the old location then you cannot delete the old VM ... as that is where the data lives! You can move the vmdk file(s) and update the reference in the .vmx file to get them local to the vm folder again.
Alternatively you can point to the copy of the vmdk file during creation, but the vmdk files still won't be local to the VM.
--
Wil
Thanks !
After following your instructions the machine is up and running and everything works fine. I have copied the virtual disk into the new vm folder and edited the configuration file accordingly.
Very happy that the vm now works again!