Event details
327 Comments
What is the expected downtime, how many reboot requires during the Secure Boot certificate renewal process, and how can we effectively manage this within the controlled patching window? Additionally, if we perform one reboot as part of the current monthly patching cycle and defer the second reboot to the next month’s patch schedule, would this cause any performance issues or operational risks on the affected servers?
We have several physical Hyper‑V host servers where Secure Boot is currently disabled at the Windows hypervisor level, while the guest virtual machines have Secure Boot enabled. Please confirm whether it is still necessary to update the compatible firmware on these Hyper‑V host servers.
Can we proceed with the firmware upgrades on the physical Hyper‑V servers with OEM Support before Microsoft releases the fix of event ID 1795 (write protected) on March 10th?
- Pearl-Angeles
Community Manager
Thanks for your participation in this AMA! Panelists covered this topic at 23:48.
I have seen a few devices where everything is ticked after updates got applied , in detection script but only red X is the Default UEFI DB has "Microsoft Option ROM UEFI CA 2023" not ticked do I have issue ? Seeing same on VM ESX 8 with nvram renamed. but everything else green on default and KEK got updated correctly as well.
Did the machine have the old 2011 equivalent of the option rom certificate? If not, it won't get the new one.
Also for a VM you won't need the Option ROM CA, and default db is not updated by the updates at all anyway (only by UEFI vendor).
I have noticed a registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ConfidenceLevel
But I can't find any reference to. Is it unrelated, or perhaps a coming feature?Same. I could find no documentation that referenced that key at all.
Hello,
When will Intune Windows configuration policy start working? What will succession look like? Still getting 65000 error.
- Daniele De Angelis
Microsoft
Many Thanks Arden, correct ;)
We need to look in the certificate chain, tnx again
On my test machine, I only see event ID 1801 and not 1808, although I've done all of the steps listed on
https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
It's also showing the 2023 certificate and not the 2011 one. Why would I not be seeing the 1808 event ID? The 1801 one says: "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware." What other steps am I missing?
can you give instruction on the boot medium, that boot with 2011 keys and can upgrade the new boot manager in the case that windows does not start anymore, because the new keys in db are reset to 2011?
2. When the CSP deployed, we see CSP sets policy as
"AvailableUpdatesPolicy=0x00005944(22852)". Will this move 2011 certificate to DBX? and when it will move? Will there be time for enterprise admin to know this and take actions on iPXE and Bootable Media?
3. The "secure boot status" report in Intune has a column "certificate status". What goes behind the scenes to say, "Up to date"? "Up to date" means certificate in UEFI?
Or Certificate in UEFI and booting from the 2023-signed boot manager?
DBX update flag is 0x80, so it is not included in 0x5944. You would need to set to 0x59C4 to push it alongside, or individually set to 0x80 after the other updates have been applied and the value returned to 0x4000/0x0.
