VMware Communities
jofi75
Contributor
Contributor
Jump to solution

Windows 11 VM encrypted after password change on host

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.

Reply
0 Kudos
1 Solution

Accepted Solutions
wila
Immortal
Immortal
Jump to solution

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

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva

View solution in original post

9 Replies
RDPetruska
Leadership
Leadership
Jump to solution

What version of Workstation do you have?  What version was this Win11 VM built with? 

Reply
0 Kudos
jofi75
Contributor
Contributor
Jump to solution

It was built with version 17, not 100% sure which exact version. Now running in version 17.0.2

Reply
0 Kudos
RDPetruska
Leadership
Leadership
Jump to solution

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.

Reply
0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution

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. 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
jofi75
Contributor
Contributor
Jump to solution

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 ?

Reply
0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution

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.

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
jofi75
Contributor
Contributor
Jump to solution

Thanks for your help.!

That would be great.

I have attached a picture of all files and also the configuration file.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

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

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
jofi75
Contributor
Contributor
Jump to solution

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! 

Reply
0 Kudos