Solved Hyper-V TPM issue with Windows 11 on new device

I transferred by Windows 11 Hyper-V vm configuration files to a new device as I have done a number of times with Windows 10, but I cannot get it to work properly with Windows 11.
The vms work fine if the TPM is switched off, but if on it fails to open them coming up with an error as below:



I have tried all sorts e.g. turning off tpm on original device and exporting vm and reimporting etc.

I cannot find the log and lookimg on web does not help (over my head - all sysadmin stuff).

Any help appreciated.

FreeBooter said:

Error when migrating Hyper-V VM LAB to different host: The key protector could not be unwrapped.

Posting this for posterity. I found much of this posted on an MS tech community blog. However, some of it was missing code last time i…

nathanblasac.com

Click to expand...

I tried this - did not work but thanks anyway

@FreeBooter, @Brink, @Kari, @Bree (and other regulars)

I solved the problem. It was fairly easy.

It was a little unclear from the text if I did these command on the Host, or on the Guest, so I tried it on Host, and it worked first time.

Fortunately, I still had my original device cloned in a native boot vhd.


I am not certain if it will work for all my vms - so far I have only tested ones cloned from the host.

Edit: I just quickly fired up each of my vms and they started ok.

So, you only seem to need to export the 2 certificates on the original device, then import them on new device.

I found this guide easier to follow than others.

So here is how it is done.

On device 1:

Step 1 - get Certificate IDs

You get lines like this for certificate 0 and certificate 1

Certificate 0 has a line:- Serial Number: 700d6aee61be9fa141c382ee51a93f47
Certificate 1 has a line:- Serial Number: 1f7c5b3e7055f4b8459939d3a7349bac

Step 2 - Export Certificates
Create a temporary folder on original device

(say) C:\Temp

Now export certificates (remember password SuperDuperPassword!

Export Certificate 0 replace serial number with above

Certificate 1 replace serial number with above

You now have a folder c:\temp on original device with 2 files: ShieldedVMEncryption.pfx & ShieldedVMSigning.pfx

Step 3 - Import certificates

Copy the C temp folder to new device/

Export Certificate 0

You need to enter password here.

Export Certificate 1

You need to enter password here.

Step 4 - Start up VMs
Startup VMs with TPM Enabled, and they now work fine (did for me).

@Brink - maybe a future tutorial?

cereberus said:

I am not certain if it will work for all my vms - so far I have only tested ones cloned from the host.

Click to expand...

It should do. I first ran into that problem a couple of years ago when migrating my VMs from my old host machine to it's Windows 11 replacement. One W11 VM had the issue, all the rest migrated OK.

Bree said:

It should do. I first ran into that problem a couple of years ago when migrating my VMs from my old host machine to it's Windows 11 replacement. One W11 VM had the issue, all the rest migrated OK.

Inadvertently created a Hyper-V Shielded VM - Windows 10 Help Forums

Well here's an interesting twist. I appear to have inadvertantly created a Hyper-V Shielded VM, one that cannot be imported and run on any Host except the one it was created on. Microsoft said: To help protect against compromised virtualization fabric, Wi

www.tenforums.com

Click to expand...

Crossed in the post - worked fine.

Bree said:

It should do. I first ran into that problem a couple of years ago when migrating my VMs from my old host machine to it's Windows 11 replacement. One W11 VM had the issue, all the rest migrated OK.

Inadvertently created a Hyper-V Shielded VM - Windows 10 Help Forums

Well here's an interesting twist. I appear to have inadvertantly created a Hyper-V Shielded VM, one that cannot be imported and run on any Host except the one it was created on. Microsoft said: To help protect against compromised virtualization fabric, Wi

www.tenforums.com

Click to expand...

I read that old post, and I have done a bit more testing.

On other vm software, when you create a vm, you can select if it has a tpm or not.

With Hyper-V on Windows 11, it always assumes tpm is there as you create a vm, but you can turn it off after the vm is created. However even if you turn it off once vm is created, it seems you still need the certificates if you move vm to a new device.

I booted into Windows 10 and created a vm (in a different location) and installed Window 10. It's default on creation was NO TPM.

I booted into Windows 11, and imported the vm, and now the TPM was on. It started fine with no need to use certificates.

I then went back to Hyper-V in Windows 10, and installed Windows 11 - I had to turn on TPM to do this.

As I expected it, when I imported into Hyper-V on Windows 11, with TPM on, it complained (unwrapping error needing certificates).

Now this is where it gets interesting - I went back to Windows 10, turned off tpm for the windows 11 vm.
I then imported it to W11, and rather to my surprise, it installed fine and started ok!

So it seems Hyper-V in Windows 10 works differently to Windows 11

W10 - TPM off by default
W11 - TPM on by default.

W10 - vms created on W10 (regardless of version) need certificates when exported depending on if vm was saved with No TPM or with a TPM.
W11 - vms created on W11 (regardless of version) always need certificates when exported regardless if vm was saved with No TPM or with a TPM. Note: VMs will run if TPM is switched off

I guess this was to enhance security but it is blinking obscure to say the least. Of course, it could be a bug?

My basic conclusion is if you create vms on W11 and export to another W11 device, you will need to certificates unless you turn off vpm.
As we know, build upgrades to W11 require the TPM to be on by WU, unless you do a manual upgrade with an iso.

Here is the most crucial point if moving vms to a new device - make sure you have exported the (host) certificates before getting rid of old device (always a good plan to have an image backup or vhdx of old device).

On my Windows 10 Pro desktop I upgraded the CPU, RAM, and GPU. I had several Hyper-V VMs including Windows 11. None of them would work anymore. If I had exported the (host) certificates before I did the upgrade and then import them after I upgraded the hardware allow the original VMs to work? Was my problem essentially the same as the OPs one?

MisterEd said:

On my Windows 10 Pro desktop I upgraded the CPU, RAM, and GPU. I had several Hyper-V VMs including Windows 11. None of them would work anymore. If I had exported the (host) certificates before I did the upgrade and then import them after I upgraded the hardware allow the original VMs to work? Was my problem essentially the same as the OPs one?

Click to expand...

There are several steps you need to do (before upgrade). I learnt all this by trial and error LOL:

1) export all vms to a different folder to get a copy of them

2) export the 2 Host certificates and store on a different drive (even external drive) as per this tutorial

3) delete the vms in Hyper-V virtual machines folder (you need to do this so you can import again). If you try and delete after upgrade, it can get tangled up and things go screwy (I have a few T-shirts on this one LOL). Do not delete the virtual machines.

4) upgrade

5) import the 2 certificates

6) import vms from copies in step 1.

7) Sometimes you need to turn vm off an on a couple of times for it to start.

8) Very occasionally, you may need to repair the boot files on vhdx file - I boot from a Macrium Reflect iso in vm and use its repair boot file option. You need to set Hyper-V to boot from the Reflect iso first.

Unfortunately, you have already upgraded, so it is too late unless you have an image backup of old device. Maybe you can fire up imsage of old device in a virtual machine?

Most important thing is having a safe copy of the vm config files and the certificates (I have them on onedrive).

cereberus said:

There are several steps you need to do (before upgrade). I learnt all this by trial and error LOL:

1) export all vms to a different folder to get a copy of them

2) export the 2 Host certificates and store on a different drive (even external drive) as per this tutorial

3) delete the vms in Hyper-V virtual machines folder (you need to do this so you can import again). If you try and delete after upgrade, it can get tangled up and things go screwy (I have a few T-shirts on this one LOL). Do not delete the virtual machines.

4) upgrade

5) import the 2 certificates

6) import vms from copies in step 1.

7) Sometimes you need to turn vm off an on a couple of times for it to start.

8) Very occasionally, you may need to repair the boot files on vhdx file - I boot from a Macrium Reflect iso in vm and use its repair boot file option. You need to set Hyper-V to boot from the Reflect iso first.

Unfortunately, you have already upgraded, so it is too late unless you have an image backup of old device. Maybe you can fire up imsage of old device in a virtual machine?

Most important thing is having a safe copy of the vm config files and the certificates (I have them on onedrive).

Click to expand...

I will a note of this for future reference. I forgot the emphasize that I only updated the CPU, RAM, and GPU. The motherboard stayed the same. I didn't reinstall Windows after the hardware upgrades. Since Windows itself was not changed then maybe there was a change in the hardware signature that caused the problem. Does that make any sense?

MisterEd said:

I will a note of this for future reference. I forgot the emphasize that I only updated the CPU, RAM, and GPU. The motherboard stayed the same. I didn't reinstall Windows after the hardware upgrades. Since Windows itself was not changed then maybe there was a change in the hardware signature that caused the problem. Does that make any sense?

View attachment 59702

Click to expand...

Yeah - all the stuff about copying vms and reimporting was for new devices. I cannot see any obvious reason why your vms did not work after the upgrade.

Maybe all that was needed was to fix the boot entries.

I guess we will never know.