Windows 11 VM on Parallels has broken virtual TPM.

AlfonsoN said:
In my case, the virtual machine was added/managed via Intune tenant, so removing the chipset is not an option because BitLocker management is out of my control. I can confirm that the removal of the KB made the TPM work again, but the patch will definitely be applied again, so the issue will probably come back. Anyways, I upgraded the virtual machine RAM size before the TPM issue; that could be also an actor on this tragedy. Is anyone from Parallels working on this issue, or even aware of it?
Click to expand...

Changing the RAM allocation is not relevant to this issue. We know what the problem is, the Jul update is trying to enforce AIKv2 on Parallels VMs, and the vTPM isn't compatible. You can use vivetool to restore the previous behaviour (AIKv1), install the Jul update, and get on with your life. It's not clear why Microsoft haven't backed out the change with Controlled Feature Rollout, as they have on the physical laptops in my organisation, or when Parallels will fix the vTPM, but I'm not holding my breath. The lack of comms from both Microsoft and Parallels truly is breathtaking!
 
My VM just said that an emergency fix was being applied and to reboot...and guess what.... IT WORKS NOW!!! I'm guessing they disabled the 62861611 via a GP update or implemented the mimicked the vivetool functionality via some other mechanism. it was *not* a parallels update so that's my guess...
 
Use the vibe tool command in the post I shared (and that another user shared above) that worked for me, it just disables that one feature of the update that broke it until Parallels updates the software
 
I got an update this morning at work ... KB5007651 (Version 10.0.29628.1000)
After this I was able to set the PIN ... it took a couple of times ... but in the end I did succeed.
 
but in the end I did succeed. .... nope it is not really working .... still seeing TPM errors in the Event Viewer Logs.
 
I can confirm that on my Parallels VM, installing KB5101684 Preview, which is meant to fix the underlying Windows issue, wasn't enough. However, I had previously disabled Vive:62861611 and my 're-broken vTPM' was only after setting 62861611 to manually enabled with Vivetool, after installation of the KB Preview.

It implies that the 62861611 feature still isn't compatible with the current Parallels implementation of vTPM, but I have no concrete way of knowing if MS intends for 62861611 feature to be enabled right now (although I think they probably do intend to switch it back on in due course: it's why KB5101684 Preview was issued).
For the time being, I've left KB5101684 Preview applied, and left feature 62861611 disabled via Vivetool. In this configuration, right now, things are working.

It's definitely going to need some work by Parallels to get things working properly long-term.
 
The latest update from Rudy is out, but quite technical. He does say MS did not use CFR to rollback the move to AIKv2, despite what he was originally told. They have made changes to Intune server side, to help avoid tpm attestation problems during pre-prov, so that is why my older workstations are working again.

Here's the situation as I understand it now. The client side "fix" from Microsoft is KB5101684 which keeps feature 62861611 enabled and adds two inner safeguards instead of reverting the design -- 61744298 (lets CertEnroll fall back to _Old EK‑API implementations for compatibility) and 63184087 (on a v1→v2 upgrade that returns HTTP 404, keep the existing working AIK v1 cert rather than discarding it).

The 404 safeguard only rescues a device that already holds a working AIK v1 cert and hits a 404 on upgrade -- it does nothing for a Parallels vTPM that can't attest at all, and it doesn't catch HTTP 429 throttling. So KB5101684 may not fix your Parallels VMs; those may still need the vivetool /disable /id:62861611 override (or a Parallels‑side vTPM fix). Heres the original article o_O https://patchmypc.com/blog/why-intune-devices-became-noncompliant-after-the-july-windows-update/
 
Great research and explanations of what's happening and why. Now if the issue could be solved correctly, rather than using a 3rd party tool. I'm only a matter of time before work steamrolls my pause windows updates setting again.
 
Looks like Microsoft's "July Preview" update KB5101684 fixed this on the Windows side for me. I did nothing to my VM other than roll it back to snapshot (I always snap before windows update!) so that I could continue to work unpatched until today.
 
JethroR said:
Looks like Microsoft's "July Preview" update KB5101684 fixed this on the Windows side for me. I did nothing to my VM other than roll it back to snapshot (I always snap before windows update!) so that I could continue to work unpatched until today.
Click to expand...
Actually... it jut fixed attestation for intune, get-tpm still reports as broken).
 
I'm just wondering if there was time to test the KB updates, so Parallels could have caught it early and flagged it to Microsoft?
From my understanding there is a 2 week window - but perhaps some other arrangement buy's more time.
 
Hi everyone,

I think I have an additional data point that may help narrow this issue down.

Environment:

  • Parallels Desktop 26.4.0 (57513)
  • macOS 26.6
  • Apple Silicon (M5)
  • Windows 11 ARM
Symptoms:

  • Get-Tpm returns:
    TPM 2.0: Structure is wrong size (0x80280095)
  • tpmtool getdeviceinformation fails with the same error.
  • BitLocker can no longer communicate with the TPM.
At first I thought this was related to VM migration, so I investigated that thoroughly.

I verified that:

  • the Parallels.vTPM Keychain entries exist,
  • the vTPM password on the destination Mac is identical to the one on the source Mac,
  • the VM UUID matches the Keychain entry,
  • the TPM keys are present in both the System and iCloud Keychains.
This seems to rule out the migration/keychain issue described in KB122702.

The most interesting finding is this:

I created a completely new Windows 11 ARM VM from scratch.

No migration.
No copied VM.
No imported TPM.
No restored backup.

The brand new VM immediately shows exactly the same behaviour:

  • Get-Tpm → 0x80280095
  • tpmtool getdeviceinformation → 0x80280095
This suggests that the problem is not related to migrated VMs. It appears to be a system-wide issue with the virtual TPM implementation, since even freshly created VMs are affected.

Has anyone else tried creating a completely new Windows 11 ARM VM and checked whether Get-Tpm already fails before doing anything else?

If someone from Parallels Engineering is following this thread, I'd be happy to provide a Technical Report ID or any additional information that could help reproduce the issue.
 
Can't believe this isn't fixed yet. I've been using Azure Virtual Desktop with my company since this happened and has been working great. Can't rieally see spending the money for Parallels if this the support being given for a pretty critical issue.
 
You must log in or register to reply here.
Back
Top