After further debugging with both AMD and Microsoft, Microsoft has confirmed the issue is on the Windows end and they have escalated it internally to the relevant team. This means we don’t currently expect that any BIOS update will be needed to resolve Intune support. We don’t yet have feedback from Microsoft on the schedule on their end.
2 Likes
Is there any news on this? As we have already commented on this thread this issue makes the AMD version of the Framework 13 (and the 16?) unusable in a business environment. At the very least it needs to be made very clear on the “Framework for Business” website that the AMD variant will not be functional if the customer employs Intune Compliance Policies for Encryption
4 Likes
Another user strobert linked me to this thread as we’re having similar issues with our own new AMD units:
AMD 13 & 16 - SecureBoot, CodeIntegrity & BitLocker erroneous reporting - Community Support - Framework Community
I’ve kicked off cases with our own MS contacts - will post to here if I unearth anything of substance.
We are still working with MSFT to get this resolved, but we do not have a resolution yet.
One thing that would be helpful for us at this point is to consolidate the different Microsoft case numbers.
If you are willing to do so, it would be helpful for us to get the case numbers through support. And mention in your subject:
Intune autopilot issue: Casenumber.
And mention to escalate this to Kieran.
Thanks!
3 Likes
Done!
Just noting two items here from trying to debug this:
Windows has an optional feature that you can install called tpmdiagnostics.exe
Which has some commands for attestation debug.
There is also a more advanced utility as part of the HLK, tpmutil.exe which has some more options, but some options look unsafe to use with attestation, (it looks like you can clear/reset/load attestation).
Switching from the Pluton TPM to the PSP firmware TPM is not something we want to enable at the moment, as it cannot be done seamlessly during the BIOS update process. We are going to track this with Microsoft.
is tpmutil.exe in reference to that earlier, if yes where do I find it, if not, how is that coming along so far? (I’d really prefer not using pluton)
@Kieran_Levin - cross posting from my other thread for visibility. I’ll message separately with case ref.
After some back and forth with our MS contacts and some support/diagnostic sessions - current opinion is that InTune IS in fact reading in the device status correctly, the fault is within InTune’s own reporting functions.
Latest I have right now is, and I quote:
“This is a Reporting issue from InTune end, this should be fixed by next InTune release.”
What I don’t have yet (I’m pressing for it) is a confirmation of that from the InTune engineering team, or visbility of it in the InTune development board.
Will update again as and when I get more.
Has anyone heard of a status update on this?
Only thing I’ve got at the moment is MS being adamant that the change in attestation reporting that’s coming in InTune 2405 will resolve the issue.
I’ve nothing of substance beyond that, and was holding off posting until I had some proof one way or the other.
Doesn’t look like it solves the issue (?) on 2405 
. Did a PC reset, reinstalled the driver pack, waited for Bitlocker to finish, etc.
Can confirm - we got it earlier this week, all AMD units still reporting failures.
I don’t actually have a Framework Laptop (I like the concept though and will be looking very closely next time I’m in need). However I am experiencing the same issue as reported here and this seems like a productive thread that I want to follow for the eventual fix (hopefully).
Getting this issue on a new Framework 16 which is a blocker for using this as a work machine so following this thread
I have this issue as well. My situation is as follows:
We have three Framework 13 (1x Intel, 2x AMD) and one Framework 16 (AMD) at work.
The Intel and one AMD device (13") currently run Windows 11 from an internal SSD and are domain-joined with Bitlocker and everything working as intended.
The second 13" AMD device (AMD Ryzen 7 7840U) is currently used as a test and utility device. The internal SSD has no OS on it. I did a Windows-To-Go installation on a 1TB storage module and got it domain-joined with working Bitlocker as well. No problems so far.
Recently I received the new 16" Model (AMD Ryzen 9 7940HS). I put Windows 11 (23H2) on another 1TB storage module and tried to set it up just like the 13" model. I got it AD-joined, but Windows didn’t enable Bitlocker by itself or asked to set a PIN. When trying to manually enable Bitlocker, I was always asked for a password because Windows apparently didn’t want to use the TPM. That’s where this whole thing began.
I did some research and spent a lot of time for trial and error with this, but haven’t gotten any further for now. I want to share my observations with you so that we maybe can fix this together. When I refer to the ‘13" device’, I mean the 13" AMD device with Win11 on a storage module and Bitlocker working. With ‘13" module’ I mean the module that is “natively” working in there and coupled to the TPM. So this is the current status:
- I check the TPM info in the Windows security center under “device security”
- The 13" device has a Microsoft Pluton TPM and the reported firmware and manufacturer versions are 6.3.1.610 (BIOS v3.0.3)
- The 16" device has a Microsoft Pluton TPM and the reported firmware and manufacturer versions are 6.3.1.615 (BIOS v3.0.3)
- The 13" BIOS v3.0.3 and the 16" BIOS v3.0.3 don’t seem to be the same. For example on the 13" device the BIOS password length is restricted to 10 characters (WTF?!) and on the 16" device I can use up to 32 (or 64?) characters.
- A BIOS downgrade to 3.0.2 of the 16" device made the TPM report a firmware and manufacturer version of 6.3.1.610 (like the 13" model)
- The core issue seems to be that on the 16" device the TPM attestation is not working. Status for “Nachweis” (attestation) is “Wird geladen …” in German which would translate to “loading …”, but I don’t know if that would be the actual text displayed. The status for “Speicher” (storage) is “Bereit” (ready).
- The 13" device reports readiness in both fields.
- The WinToGo setup is done with Rufus 5.4 and an official Windows 11 23H2 image.
- When the freshly written 16" module is initially booted on the 16" device, the problem described above occurs.
- When the freshly written 16" module is initially booted on the 13" device, the TPM attestation and storage fields both report “ready” immediately.
- From this we can deduct that the WinToGo creation process is not the problem and that we don’t need to start any AD join or whatever to check if the TPM would work correctly.
- When the 16" module was initially booted on the 16" device (not working) and then booted on the 13" device, the problem still occurs. The 13" module still works fine on the 13" device after this.
- When the 16" module was initially booted on the 13" device (working) and then booted on the 16" device, the problem then occurs. I did not try switching back to the 13" device though.
- I haven’t tried the storage module in every single port yet, but I doubt that this would make a difference.
- I haven’t tried to boot the 13" module in the 16" device because I use that in production didn’t want to break it.
- I have a spare 1TB module and will try to clone it for testing purposes. I will have to strictly isolate the device from the internet though, because I don’t want to risk messing up my AD.
- I tried to skip the Rufus settings like “disable need for Microsoft account” without any effect.
- I tried to set the TrEE protocol from 1.1 to 1.0 without any effect.
- I tried to reset the TPM multiple times without any effect.
- I tried to install the driver bundle without any effect. At least on the 13" device the TPM works without installing the driver bundle.
- I tried everything described in the excellent blog post from call4cloud.nl but without success. When running the PS script, the TPM actually reports “ready” for attestation, but Bitlocker still won’t work and after a reboot we’re back to the previous state.
So yeah, I already spent a lot of time on this and my current conclusion is, that either Microsoft or Framework (or both) should get this fixed soon. I wonder why people have problems with the 13" AMD Laptop though. That one is working like a charm for me.
I’m having a similar issue on framework 16. However the Bitlocker IS working, it just cannot report to Intune that bitlocker is working. The TPM reports that attestation is working and all other items are setup fine, but since the 16 cannot report to intune that bitlocker is installed I cannot use our Company portal or get new installations.
Adding another vote to this topic for framework 16.
Bitlocker is properly encrypting. However the DHA certificate is not getting pulled to the device.
Issue seems very similar to what is reported here: Health Attestation Certificate | Bitlocker | Secure Boot (call4cloud.nl)
1 Like
@Polle_Vanhoof
This sounds like the most likely cause to me.
I.e. Certificate chain is broken
So, someone needs to find our which Intermediate Certificate is missing and ask for that to get fixed. If this is the case, its not caused by a bug in software, but just a missing or invalid certificate in a certificate store somewhere.
Also noted in that blog, is that during the process one needs internet access working.
Also, Framework not wishing to move to using the PSP firmware TPM is a good thing.
The PSP firmware TPM impacts performance of the whole machine so is generally avoided on Linux. I expect it has similar problems with Windows.
So, getting Pluton TPM eventually working is probably the best option.
We are still debugging this with Microsoft. However I just retested, and I see that the device is reporting itself as compliant now:
I see that there is a new attestation preview feature that was recently rolled out in the July update, however I do not see this in our tenant yet:
However there is a new report: Windows hardware attestation report
And this shows that we are now compliant.
Oddly, the TPM-HasCertRetr task still fails.
I am not 100% convinced that this is properly fixed, or if the Intune server is just ignoring the heath report now.
2 Likes