Event details
274 Comments
We started a while before the playbook came out – using previous instructions on how to update the db and verify the 2023 certificate in the EFI file.
Only recently noticed that this does not update KEK automatically.
Could we in confidence, target out confirmed db\efi file updated devices with the script to update the AvailableUpdates key and the Scheduled Task to complete the update?
On the handful of devices I tried this on, the UEFICA2023Status value changed to Updated after a few moments.
We are not able to enable the share diagnostic data with Microsoft settings to allow MicrosoftUpdateManagedOptin, so we’ll be managing this ourselves.
If you used older AvailableUpdate flags, it may not have included KEK updates, yes.
I would just re-run with the current flags to get the KEK updated as well, as well as any other things not updated yet. The system will automatically skip flags that have already been applied, and they will get set back to zero (except the 0x4000 flag), so that you will end up with 0x4000 or 0x0 at the end.
Or set it to 0x4004 to only update the KEK, if you prefer going that route.
Are these updates Bitlocker aware? Do we need to suspend bitlocker for 2-3 reboots during this process?
We've ran into Bitlocker boot loops on a small percentage of Surface Laptop 7 devices. How do we prevent that using registry deployment (AvailableUpdates 0x5944)?- Pearl-Angeles
Community Manager
In addition to the response below, your question was answered during the live AMA at 17:12.
rparmar50Microsoft
Yes, these are BitLocker aware, no need to suspend BitLocker.
What is the proper to detect if a device's secureboot certs updated correctly?
Some devices show different responses across all 3 detection methods that was recommended:
UEFICA2023Status = Enabled
EventViewer Event 1808 = Updated
Intune SecureBoot Report = Successful
Sometimes the 3 above conflict with each other on some devices. A device may have UEFICA2023Status = Enabled but no 1808 event in EventViewer
Is there a risk we trigger BitLocker recovery for users if we update the secure boot cert? Not seen any cases yet but there does seem to be fear around this aspect. Perhaps we need to be careful in some scenarios only? thanks
We're still seeing error 65000 for the Intune settings on every computer we have deployed the policy to so far. We are on Win 11 25H2. Any advise?
- Pearl-Angeles
Welcome to the March edition of Secure Boot AMA! Let's get started-- our experts are ready to support you, so post your questions here in the comments below.
Question regarding the Platform Key (PK) certificate on some servers in our environment. When running the command to see if the Platform Key (PK) is good, some servers report the following,
PS C:\> certutil -dump PK.der
00 .
CertUtil: -dump command completed successfully.
PS C:\>$bytes.Length
45Does this certificate also need to be installed or corrected for updates to occur in the database for the 2023CA and KEK certificates? If so, the current fix is very manual w/ requiring us to attach a drive (using VMWare) to the server, placing the PK onto the drive, shutting it down, booting to BIOS, installing the PK certificate, then removing the drive and booting the server back up.
Again, more manual steps and more downtime for our servers.
We haven't deployed the Intune Secure Boot settings yet across our estate (see my previous post below) permitting devices to install the new certs. However, in the last two weeks, some of our Microsoft Surface Laptop 5s are unexpectedly displaying this message:
And their device record in Intune is now broken:The Serial Number is not 123123123, DeviceModel would normally be "Microsoft Surface Laptop 5" and Device Manufacturer would normally be "Microsoft".
So I am just curious if this is an error we would see if something goes wrong with installing the new SB certs, or something else entirely?
Thank you 🙏DFCI should be its own animal, and I don't believe it's directly related to the Secure Boot Certs https://learn.microsoft.com/en-us/autopilot/dfci-management Maybe someone enabled this in the environment or for Surface devices, if not check to ensure the user is not connecting external encrypted disks at boot.
Hello,
I have machines that will not be receiving BIOS updates from the OEM (Dell).
They successfully installed the new certs, but did not apply them - throwing 1803/1801 errors. Will the 1803 error (PK-signed KEK not found) possibly be resolved thru Windows Update, or will machines affected by this simply be unable to apply/utilize the 2023 certs?
If Dell won't provide a signed KEK update to Microsoft for those devices (probably because they cannot), Windows will not be able to update the KEK.
In my experience, Dell devices often have an option in their firmware setup to enroll a DB or KEK certificate from an USB key manually. You can try by putting
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/KEK/Certificates/microsoft%20corporation%20kek%202k%20ca%202023.der on a FAT32 formatted USB key and trying to import it as KEK. This should make the secure boot update continue and complete successfully.
Still, from an economic standpoint, you have to decide whether spending a few minutes on each device manually is worth the effort or whether you would be better off replacing the devices.
Thank you for the response and giving me something to try. I have about a dozen machines that will probably need this workaround (hope it works). So, not hundreds or thousands. But unlike a general user's 4-core Optiplex from 10+ years ago, these are workstations that have 12 or 14 cores. Are they as powerful as an equivalent new machine? No, but they still do what we need them to do, and do it pretty well. So, a few minutes, assuming the fix works, is well worth my time. Thanks again. I'll report back when I've had a chance to try.
Jason_Sandys could you answer this question?
- Arden_White
DJ8014A I can see that's a Dell device. It's difficult to determine which one it is. Would you be willing to share the model name/number of the device?
Hi Guys 👋,
Hope this finds you all well. We're still seeing error 65000 for the Intune settings on every computer we have deployed the policy to so far. I've heard it's not just us either.
We tried the PowerShell fix (to remove/renew the licence subscription) but after multiple Intune/device syncs and reboots over a period of days, Intune still reports 100% failure for all devices. We can also still see repeated error 827 in Event Logs advising "policy rejected by licensing":
When will this be resolved please? The June deadline is looming...
- Jason_Sandys
Are these down-level OSes? Win 11 23H2 (or below)?
Please open a support case as some deeper investigation is needed here.Hi Jason, thank you for your reply. All devices are 10.0.26200.7781. We already have a case (2603110010001114) open but no response from Microsoft yet.
