Event details
219 Comments
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
Community Manager
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
Microsoft
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.
Questions for Tomorrow’s Live Event / Or Anytime:
We’re testing the certificate updates on our servers within our vSphere environment. We seem to have a functioning certificate update process? However, we are not clear on some things and have some questions – especially when it comes to Broadcom/VMware.
For reference, we’re on vSphere 8 U3 with virtual hardware level at 21 (the current release). Our VMTools versions are also fully up to date (if that matters). We’re running Server 2019, Server 2022, and Server 2025. Here is the process we are testing right now:
1 - We rename the VM’s NVRAM file in vSphere. (Note that we have some important vSphere questions about this below).
2 - After that, we configure the AvailableUpdates = 0x5944 key, per the various forms of Microsoft documentation.
3 -We then manually run the Secure Boot Update scheduled task to start the update process using this command:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
We then wait about 30 seconds and reboot.
4 - After the reboot, we manually run the above-mentioned scheduled task again.
5 - We wait a few minutes, and then when looking in the Secure Boot registry keys, we most often see the UEFICA2023Status return as “Updated” and WindowsUEFICA2023Capable returns 2.
HOWEVER - on the Server 2019 OS, while UEFICA2023Status shows “Updated”, the WindowsUEFICA2023Capable value comes back as 0. Despite that, when we run the verification command - ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match "Windows UEFI CA 2023" - it still returns “True”.
Should we be concerned about the WindowsUEFICA2023Capable = 0 result on server 2019 if the above-mentioned database check command allegedly confirms that the device is currently using the 2023 Secure Boot certificate?
Also, VMware has not yet released an updated virtual hardware/BIOS package for this issue (only manual steps). We are not sure it matters. Do we need to worry about the virtual hardware/Bios update offered by VMware if we’re already seeing the “Updated”/WindowsUEFICA2023Capable =2 results we’re getting now within the registry? From a compliance perspective, does this mean we’re covered? For that matter, do we even need to rename the NVRAM File?
Finally, we’ve noticed that on some of our Server 2025 systems, even when the certificates updates itself successfully, the Secure Boot scheduled task fails with a “file not found” error. Is there a way to correct this? It appears to be a built‑in, “solid‑state” task. We are not sure how to address this.
Thanks
Prabhakar_MSFTHello CTKMN , If devices are showing UEFICA2023Status as “Updated”, it means device have all required certificates and also booting with updated new windows boot manager. We are investigating the issue related to WindowsUEFICA2023Capable not being updated to 2.
Thanks! Do you have any thoughts on my other questions?
I am seeing similar behavior with some of my HyperV Virtual Machines. Updated Capable =2 for some, both Server 2022 and Server 2019 though, and another Server 2019 patched with the same March 10th updates, it shows capable=0 instead of 2. So not sure what the difference is, but that capable=0 is on one of my Server 2019 VMs. I have only tested so far on one server 2022 VM.
Hi Arden_White
today i updated an tested Hyper-V VM (Version 9) Server 2022 DC. 0x5944->0x4004
i checked "C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab" and then the Microsoft.json which lists my VMs BucketHash in the Section:
"Under Observation - More Data Needed": [
Any Info Regarding Servers, would like to hear more about it (tomorrow) last month it was said it should be fixed in March.- Arden_White
Hi PeDe83 the March updates need to be applied to both the host and the guest.
- Host changes are to allow KEK updates to the NVRAM
- Guest changes are to include a Hyper-V PK signed KEK that the guest can apply to the firmware.
If I'm remembering correctly, if you look at the SYSTEM log at the TPM-WMI source, you'll see a 1795 event if the host is not updated and the guest is. Otherwise, you'll see an 1803 event if the host is updated and the guest is not.
Arden_White are there details available in a KB on these changes available in this month's updates, or more information about applying the updates for Hyper-V hosts/guests?
Microsoft has provided very little information with regarding the Secure Boot cert expirations on Hyper-V. Some really useful information would be version numbers of installed QFEs with the necessary certs/fixes, and details like you just provided (the fact that both the host OS and the guest OS have to be patched, and the 1795/1803 event IDs).
Also, information what order the patches should be applied (host, then guest?), and how I can streamline patching, cert updates, and reboots this across dozens of hosts would be really useful... especially since Microsoft has only given us 3 months until the CA expiration and enterprises have limited change windows available.
Just updated my HyperV host, only seeing preview updates available for Windows 11 24H2, I updated to 25H2, and do not see any updates from March showing up yet, checking in my SCCM Lab environment and still only see February updates so far... forcing a synch to see what else shows up.
- In a situation where the KEK certificate does expire can we get a clearer idea as to the actual impact? It’s stated that new binaries will not be accepted into the authorized signature database however older previously signed binaries will still be trusted. This confuses me, because the wording of the boot process in regards to secure boot certificates implies that the signatures of trusted binaries is checked every single time.
- Products that use kernel level drivers rely on WHQL microsoft signed drivers that appear to be reliant on the secure boot certificate chain. What is the impact to these tools if the primary KEK certificate is expired?
- What is the status from Microsofts perspective on ongoing efforts with OEMs (i.e. VMWare) to figure out automation of PK certificate rollouts?
- Arden_White
- The KEK certificate/keys signs updates to the DB and DBX. The DB updates to apply the new certificates are signed with the Microsoft Corporation KEK CA 2011 which the device trusts. Moving to the new certificates, even after the 2011 KEK expires should still work. New security updates to the DBX will be signed with the Microsoft Corporation KEK 2K CA 2023. If the firmware does not trust the 2023 KEK, the new DBX updates will fail to apply. During boot, the KEK is not used for validating binaries - only the contents of the DBX and DB are used.
- The KEK is not used to validate WHQL signed drivers. It is only used to validate updates to the DB and DBX. The firmware does not care that the certificates have expired. The issue is the need for key rotation as a good security practice and because Microsoft cannot sign with expired keys.
- I am aware of Microsoft and Broadcom-VMware working together, but I don't know the details.
