Event details
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
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.