Event details
72 Comments
dupe
When will the majority of compliant mainstream enterprise systems be shifted to “High Confidence”? Is the goal still to move most mainstream computers to HC?
For what it's worth, here are the current statistics updated for today's June update:
June May April March High Confidence 2312699 2005634 1878953 1617397 Under Observation - More Data Needed 184405 395777 466652 597235 Temporarily Paused 16693 52420 53611 0 Not Supported - Known Limitation 33987 32736 33831 0 High Confidence (Percent) 90,8 % 80,7 % 77,2 % 73,0 % Under Observation (Percent) 7,2 % 15,9 % 19,2 % 27,0 % Well done getting the Under Observation and Temporarily Paused counters down.
- Heather_Poulsen
Community Manager
Today's Secure Boot AMA will kick off in less than 10 minutes. We appreciate your early questions - keep them coming and our panel will do their best to help.
I manage a configuration Manager environment with about 50k endpoints. We deploy Windows via PXE boot and a OSD Task Sequence.
We're trying to get the latest certificates onto our computers but there will most likely be some computers that we won't reach to update in time.
1. Will PXE boot still work for both computers we've updated with the new certificates and computers that only have the "Microsoft Windows Production PCA 2011" as long as that certificate is not in DBX. Even after it's expiration date (October 19)?
2. Would you advice NOT to update bootloaders in PXE to use the "Windows UEFI CA 2023" certificate until all computers have the new certificates?Hello there!
What is the supported and scalable way to update Secure Boot keys across hundreds of VMware-based virtual machines?Is there a simple standardized process or tooling from Microsoft?
Prabhakar_MSFTMicrosoft
Hello Jan2 ,
Broadcom is working with Microsoft to bring support to update VM Platform Key via Capsule update mechanism as documented by Broadcom at Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines . This will unlock automated deployment of KEK 2023 certificate.
Pasting the Broadcom documentation below
- Capsule PK update for vTPM-enabled Windows VMs: This method depends on planned Microsoft Windows patches. For supported Windows versions with the required patch installed, the missing Windows OEM Devices PK certificate will be automatically added to the PK database upon a guest reboot following a reboot prompt. This capability will be added to ESXi 8.x and 9.x in future patches. Additionally, a PK update driver is required to trigger the update. This driver will be delivered via Windows Update and also included in a planned VMware Tools release.
VMware VMs can update Windows UEFI CA 2023, Microsoft UEFI CA 2023 (If VM trusts Microsoft Corporation UEFI CA 2011) to DB today by leveraging one of the deployment methods documented at https://aka.ms/getsecureboot
Windows Configuration System (WinCS) APIs for Secure Boot - Microsoft Support
Once you have configured the one of the above policies, device will automatically install required KEK 2023 cert soon deployment is unblocked automatically across all virtual machines.
Thank you for hosting this event, Microsoft. I work for a small company and all our rollouts for the update have gone well for user workstations, however I am having difficulty updating windows server 2016 VM's. They are returning an error:
"The Secure Boot update failed to update a Secure Boot variable with error The parameter is incorrect." Event ID 1796
I have not been able to find a solution for this as it is so vague.The error is deliberately vague. You can check the UEFI specification what conditions can result in this error (scroll down to "Status Codes Returned"):
Most likely it is a faulty or incomplete implementation of the (virtual) UEFI.
- Some 'Orrible xVM virtualization solution (whose name I cannot write as it is banned here, sounds something like a nonreal cube), for example, does not implement individual KEK/DB variables for each VM, so they made any write to these variables fail from within the VM. You'd need to update the certificates from the VM managment console while BitLocker is suspended (if used).
- To properly update KEK on Hyper-V machines, both host and guest need to be at least of March 2026 patchlevel (April 2026 in case of hotpatching enabled).
- On physical machines, most likely have a look for a firmware update
- In case the new keys are already updated inside the Default variables, you can also reset secure boot keys to default, while Bitlocker is suspended
- I've seen cases where NVRAM being full resulted in EFI_INVALID_PARAMETER instead of EFI_OUT_OF_RESOURCES. In that case you will need to experiment whether you can free some NVRAM by resetting secure boot variables or resetting UEFI defaults. In case you have been dual-booting Linux and allowed it to write crash dump information to EFI NVRAM, you can clear these from within Linux.
In any case, stating the make and model of your hardware (in your case the virtual hardware, i.e. the virtualization vendor) might help others help you with your particular (virtual) hardware.
An LCU must be applied to the Dec. 2024 ADK winpe.wim and files copied out to ADK install directories to get 2023 signed .efi files in place, correct? What is the intended/expected outcome of this? I am only finding bootmgfw_EX.efi getting 2023 signed while all others remain 2011.
Thank you for giving us this opportunity today.
We are concerned about the Secure Boot certificate expiration issue. In Japan, we manage approximately 100,000 PCs as well as servers located throughout the country. If a large number of devices were to become unbootable at the same time, it would have a serious impact on our business continuity. Therefore, we would like to take preventive action before any issues occur.
what is Microsoft’s planned schedule and roadmap for future Secure Boot-related Windows updates?We would appreciate any recommendations on how to safely deploy these updates in a large-scale environment while minimizing business risk.
We have several questions
First, is there any risk that devices could become unbootable if they have not been regularly updated with Windows Updates up to no
If you ask that broadly, the answer would be YES, but totally unrelated to Secure Boot. When machines exposed to the Internet are not up to date, they can catch malware. Some poorly written malware can result in the machine getting unbootable as an unintended consequence, and some malware/randomware deliberately prevent your machine from booting.
But none of the Secure Boot expiration times will directly make any machine unbootable.
Distilled from my other post. Once you get 1808 event that it is applied to firmware, when and how it will naturally switch the bootmgr, if it is a High confidence VMware VM with Windows Server 2025, ESXi 8.0 U2+ compatibility?
My understanding is that if you see 1808, it's already installed the new bootmgr.
Secure Boot troubleshooting guide - Microsoft Support
Section "Expected progression (AvailableUpdates)" above.
Have found one VM in our environment with Secure Boot enabled. Used same template to build a test VM to test everything first. It is Windows Server 2025. After doing latest updates registry has all the entries as per documentation. Did the registry change 0x5944 for AvailableUpdates and task scheduler task run, reboot. It said Updated for UEFICA2023Status, AvailableUpdates changed to 0x4000. But low confidence - needed more data. 2023 certs seen in DB dump. But there was event 1801 that it was not applied to firmware.
vCenter is 8.0.3, but for some reason this template is set to legacy compatibility (Vmware 7,1). So i have updated compatibility to 8.0 U2+ for this VM. Had to do 0x5944 registry and all the dance again and now it was 1808 event, firmware updated. But VM is still using old bootmgr. So, i am still not able to fully test the whole scenario of everything updated. And i am not sure whether i should try rebuilding boot entry to force it or should i try to shutdown/reboot it 100 times or just wait for some CU/SSU update someday.
I guess my main problem/question is how to make sense of all the registries, events and figure out what is the rightest approach on a large scale. I am not getting paid enough to deal with this...
- When looking at events, you need to take into account the fourth dimension (time). I would assume the 1801 has been logged before you switched the registry key.
- The bucket confidence data does not reflect your device's point of view. It only reflects what Microsoft has been seeing via telemetry about similar devices out in the field. If the device is exotic enough (or nobody who owns it allows telemetry), the confidence level can be low despite the updates being applied fine (as you observed)
- Once the 0x0100 bit is cleared in AvailableUpdates, the new boot manager is installed. It will need another reboot until the system is actually booted from it (And another run of the update task until the status reflects it). I don't think you need 100 reboots, though.
- I guess you understand that Microsoft does not have any direct or indirect impact on how large your paycheck is
