Event details
80 Comments
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
So far all the AMAs i have watched are mostly focused on endpoints. Can we have a session solely for servers/VMs? It seems that this category is being left out.
An AMA tends to focus on the questions being asked. More questions got asked about endpoints, so they get handled in the AMA. (Your message also did not ask any questions about servers :D)
That being said, there is
http://aka.ms/SecureBootForServer
with resources for servers.
Agreed. I forget where/when it was said, but I think in a previous AMA one of the group said they're not doing any CFR or High Confidence Buckets for servers.
I don't think most IT Pros are super aware of that and the implications.
- Arden_White
Microsoft
CFR (Controlled Feature Rollout) only targets client devices and doesn't help with gaining confidence on servers. Servers often send little or no diagnostic data to know if the updates are proceeding as expected and that limits Microsoft's ability to add servers to the High Confidence data. That means servers should be monitored and certificates should be deployed as part of managing them.
One exception is with virtualized environments where both clients and servers are running on virtualization (VMware, Hyper-V, Azure, etc.). As of the June release, there were a significant number of virtualization solutions added to the High Confidence database and in these cases, the updates may automatically apply to High Confidence VMs.
Are there any Updates regarding my Question: "Will Microsoft and/or Broadcom provide a solution to automatically update ESXi VMs with missing KEK/PK?"
The last Answer from PrabhakarMSFT was: "...we are coordinating with Broadcom to bring support in Windows to update KEK on the ESXI VMs. If new VMs are created on latest versions on ESXI, VMs get created with new certificates. For pre-existing VMs, Microsoft is coordinating with Broadcom and will be enabled in the future update."I posted a question about this as well before seeing this. Definitely interested in everyone's stance on this. Time is running out and I don't want to have to import PK/KEK certificates manually into thousands of VMware VMs.
I'm also very interested in the answer for this question.
We absolutely need to know when the solution created by Microsoft & Broadcom will be released? Time is running... And if it maybe will require a newer ESXi release (newer than 8.0 U3j (P09)) to be installed beforehand, we'll for sure not be able to do the work before June 24th when the Microsoft Corporation KEK CA 2011 certificate expires.
Broadcom documents that for Windows VMs with vTPM it's recommended to wait for an automated solution to become available in a future release. But how long do we need to wait...?
https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html
We use SCCM in our environment for client deployment. A few months ago, we updated the boot image with the latest compatible Windows ADK, but when I checked the bootloader certificates, they appeared to still be the old ones. What does the update process look like in this case? I know that a new feature for certificate updates was added in SCCM 25.09. Is this sufficient to update an existing image and continue using PxE boot for all clients? Or does the boot image actually need to be completely rebuilt?
Hi JonasKrueger
Maybe I can help you on this point.
The new option "Use Windows Boot Loader signed with Windows UEFI CA 2023" is only for PXE Responder without Windows Deployment Service. If you don't configure the PXE with "Eanble a PXE responder wihtout Windows Deployment Service" the UEFI CA 2023 option has no effect.If you still want to rely on PXE with WDS you need to copy wdsmgfw.efi and bootmgfw.efi from %windir%\System32\RemInst\boot_EX\x64 from your up to date server to %RemoteInstallFolder%\SMSBoot\x64. Then remove the "_EX" suffix from the files.
I hope this information helps.
Kind regards,
MatiasThank you, I will try this out. I have been mounting and patching winpe.wim trying to get a 2023 signed copy of bootmgfw.efi to copy out to ADK as bootx64.efi as I'm sure I had done about a year and a half ago, and I just keep getting 2011 signed .efi files except for bootmgfw_EX.efi. I kept the files to manually swap out, but trying to avoid that if possible. I don't recall simply renaming and overwriting, but maybe that's what I had done.
Then the next step was to try to address for WDS and I haven't been able to get any AMA replies about this, or even on my opened MS case via 3rd party. If struggling with WDS, next step to try moving away from it working with the NET team on iphelpers and DHCP options.
Can we get in plain english how everything is going to be affected? It is near impossible to get a clear picture on how, when, and what is happening and going to happen. Seems like we are spending a lot of time chasing our tails on this, and we have little to no control over what and when we can do anything about this.
We tested mitigating BlackLotus (Windows UEFI 2011 -> DBX). 0x80 applied to test devices, then a pilot devices. No problems.
It was decided to not mitigate BlackLotus. Is there a way to remove the Windows UEFI 2011 from the DBX, outside of booting into BIOS and reseting Secure Boot keys to factory defaults?There is no way to undo DBX revocations from inside the operating system. (Think about it, otherwise Black Lotus could do that as well). So you will have to do that from within the firmware setup somehow - if there is no separate option to undo DBX updates (which I've seen only very rarely), you'd have to restore the keys to factory defaults, properly taking care of BitLocker and/or SecureBootRecovery in that process, if applicable.
