FW13 AMD here, still no success with Bitlocker reporting in InTune. Thankfully this is for my own MSP environment, but it does not bode well for using this for business. I have been trying to troubleshoot this for days before looking to see if it was framework specific and it just so happens to be. Appreciate y’alls work and any updates.
I am in the same boat… the compliance reports good now, but the scheduled task is still failing.
I am happy my compliance is at least working.
Lenovo - ThinkPad P14s Gen 4 with AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics.
I spent 12 more hours on this case without a final solution, but at least got some interesting new info. The issue seems to be that the TPM Attestation is broken if I run Windows from a storage module on the FW 16. I ran tests on a 13" AMD Framework Laptop and on a 16" AMD Framework Laptop.
- WinToGo Module initially booted on 16" FW: no attestation (the original problem)
- WinToGo Module initially booted on 13" FW: attestation ready (what I was used to)
- WinToGo Module swapped from 16" to 13": still no attestation (windows seems to remember something)
- WinToGo Module swapped from 13" to 16": no attestation anymore (the problem seems to be tied to the 16" device)
- WinToGo Module swapped from 13" to 16" to 13": attestation not returning (the 16" device is definitely and permanently breaking something)
- Windows installed to internal SSD of 13" FW: attestation ready (as expected)
- Windows installed to internal SSD of 16" FW: attestation ready (at least that, so it’s not the device itself!)
- WinToGo Module initially booted on 16" FW with Windows present on internal SSD: no attestation (the presence of an internal Windows disk seems to have no positive effect)
- Windows VHD booted via Ventoy on 13" FW: attestation ready (cool, didn’t really know what to expect)
- Windows VHD booted via Ventoy on 16" FW: attestation ready (I certainly didn’t expect THIS)
Things I accounted for:
- I always used the same official Windows 11 23H2 image for OS installation
- I tried different 1 TB storage modules to make sure it’s not a hardware defect
- I installed Windows to the modules via Rufus 4.5 and even manually with DISM. It made no difference though.
- I ran the test with USB4 boot measurement (16" FW) enabled and disabled
- It seems to have no impact whether there is an internet connection or not
- I never installed the driver bundle or waited for any windows updates this time because the whole ordeal would have taken even longer. As it all works on he 13" FW anyway, these steps probably have no impact on the result.
- The used expansion port of the laptop made no difference (as I suspected in my last post). The device doesn’t fully turn off when using the upper two ports, though.
Other things I noticed:
- On a “working” system, the attestation field shows “loading” if Windows was freshly booted and takes a few seconds to show “ready”. When the attestation isn’t working, it never shows “not ready” or “error” or something. It’s stuck at “loading” and it seems that this process just never finishes under those circumstances.
- When the TPM is cleared, it has the state “unowned”. Normally Windows automatically owns the TPM when starting up. When booting WinToGo on the 16" FW, this does not happen.
- When booting the WinToGo module the first time, Windows performs a reboot during the first setup. When I then opened the boot menu, there was a “Windows Boot Manager” option on the 13" FW but on the 16" FW it only showed “EFI USB Device”. It stayed this way after several reboots. When I swapped the cards, both only showed up as “EFI SB Device”. After another reboot, the 13" FW listed the storage module again as “Windows Boot Manager”, the 16" FW did not.
I had a breakthrough today!
A couple months ago when I only had the 13" AMD model to play around (way before I got my 16" Framework) I had made a bootable Ventoy USB drive to experiment with booting Windows VHDX images. I had no spare SSD modules then. That USB drive still exists and today I cloned it to a Framework SSD expansion because I wanted to try and setup my productive system in a VHDX environment. That was my only hope regarding the results from yesterday. I then decided to try the native boot from there as well and didn’t expect much but guess what? The TPM attestation worked!
But WHY? What was the difference between the native Windows partition on the VHDX-Drive and the native Windows partition on the regular storage modules? All of them were created by Rufus on the same Lenovo machine from the same Windows image.
It’s the drive type when creating the WinToGo with Rufus! You have to enable “show all devices” to be able to write the Windows to go to the expansion card, but thumbdrives are listed immediately. So there seems to be a subtle difference in how Rufus handles the installation process on these device types. The 13" AMD Framework seems to have no problem with that, but on the 16" model it causes the TPM attestation to fail.
So for anyone who might have the same issue as me, you should try the following solution:
- Use Rufus to install WindowsToGo to a thumbdrive
- Clone the thumbdrive to an empty SSD expansion card. I recommend MiniTool Partition Wizard for this as it allows you to manually adjust the partition sizes on the new disk. You can find a bootable version in the Medicat USB kit.
- Boot the expansion card and happily use BitLocker. I’m very confident that this will also fix most if not all Intune compliance issues.
This leaves only one question for me, that I’m too exhausted to research further: Why does the device type at creation time of the WinToGo drive impact the TPM attestation when booting the OS in the target machine? And why does it only affect the FW16? There might be something to fix on the BIOS/UEFI side, so someone with more knowledge should have a closer look at this.
The local TPM parts seem to be working just fine on my 13" AMD Framework (the output of tpmtool getdeviceinformation all looks good, attestation ready, PCR7 bound, etc.), but TPM-HasCertRetr is still getting back 400 errors from has.spserv.microsoft.com, presumably due to an intermediate certificate error at Microsoft’s end. If the Framework guys could specifically point their Microsoft contacts at that as the issue, then we might get this resolved.
Being able to manually attest that a device is OK is unlikely to fix various other checks, systems and reports, which will look at the actual health check status.
This machine is currently reporting in Intune that it is Not evaluated - all of Bitlocker, Code Integrity and Secure Boot are in State “Error” with message: 2016345708(Syncml(404): The requested target was not found.)
The event logs on the client with source TPM-WMI say: The Device Health Certificate could not be provisioned from has.spserv.microsoft.com. HTTP status code 400: <?xml version="1.0" encoding="utf-8"?><HealthCertificateResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ErrorCode="1" ErrorMessage="There was an error processing this request." ProtocolVersion="1" xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/response/v3" />
OK, done some more digging, via the tpmdiagnostics tool and 2016345708 | 404 | Device Health Attestation Certificate
The cert chain is:
Element 0
Issuer Name:'<redacted by me>'
Subject Name:'<redacted by me>'
AKI: '<redacted by me>'
Element 1
Issuer Name:'Pluton Factory DEVICE EK ICA DFID00A70F00'
Subject Name:'<redacted by me>'
AKI: '<redacted by me>'
Element 2
Issuer Name:'Microsoft Pluton Policy CA A'
Subject Name:'Pluton Factory DEVICE EK ICA'
AKI: '<redacted by me>'
Element 3
Issuer Name:'Microsoft Pluton Root CA 2021'
Subject Name:'Microsoft Pluton Policy CA A'
AKI: '<redacted by me>'
Element 4
Issuer Name:'Microsoft Pluton Root CA 2021'
Subject Name:'Microsoft Pluton Root CA 2021'
All of the issuers in the chain from Element 1 onwards are in the latest TrustedTpm.cab file from Microsoft.
If I install those root and intermediate certs locally then I can get the chain to validate.
The AIK certs also seem to check out, FWIW. I get an issuer chain from that of:
CN = EUS-MSFT-KEYID-EEF8218C2041947588930B6845839C85CDE73857
CN = Microsoft TPM Root Certificate Authority 2014
So either Microsoft’s cert store on their has.spserv.microsoft.com endpoint is not up to date with these intermediate certs, or something else strange is going on.
“There was an error processing this request” isn’t a very helpful error response for debugging this. :-/
1 Like
Thanks to everyone who has helped to gather information, especially @Alastair_Maw .
@Kieran_Levin this seems like something that Framework + AMD + Microsoft should be able to sort out now that there are a lot of breadcrumbs. It would be really nice to be able to actually use this machine (he says, written on a Framework 13 with 12th Gen Intel).
Any news about this topic. Other hardware vendors maybe affected too.
So, I don’t know if it’s August updates, Intune changes, or just freak coincidence but I booted up this morning, installed updates and my device is showing as compliant.
It’s only been 4 hours so there’s always still the possibility that it’s a temporary fluke and something will go wrong but for today I’m enjoying it.
1 Like
can confirm that i looks good 
1 Like
can i just not update the bios or have a special method to update the bios? i’ve heard other OEMs allow you to shut off PLUTON. For an end user friendly laptop not being able to shut off pluton is a pretty big red flag. i know you guys trying to expand your firmware team but, seems like you still may not have enough heads on the team or enough resources.
EDIT: still digging on pluton. we are considering intune for laptop mdm.
https://mjg59.dreamwidth.org/58879.html
Intune compliance seems to be magically fixed now too for my Framework 13 Ryzen.
Is anyone here still experiencing issues with this? Can probably close this now if not.
Mine isn’t experiencing compliance issues but I’ve now twice had the “TPM Malfunction”. I’m going to wipe it and just use it as a personal machine. It’s too much of a sh*t show for work use. I’ll take something with less flexibility and upgradeability if it’s stable.
Just spun up 2x13" and 1x16" with Ryzen chips and all three reporting these errors. We are using Intune for MDM.
Still no joy with a Framework 16 laptop, just ran through the whole windows install from fresh and exactly the same issues as last time.
I am getting the Warning “The Device Health Certificate could not be provisioned from has.spserv.microsot.com” in the System event log when I boot up. Do we know if this is the root cause of the problem?
tpmtool is reporting everything ok.
Is this being actively investigated? I have an expensive paperweight at the moment if I can’t access any company resources from this laptop.
I have a few clients who have bought a load of new AMD devices - having the same Intune bitlocker issues as everyone else. Its crazy that there isn’t a fix for this?!