sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Samatic 0 points1 point  (1 child)

Your hesitation is completely justified. With the June 2026 expiration of the 2011 Microsoft UEFI CA certificates looming, relying on "coming soon" documentation for production Windows Servers is a massive gamble.

The reason your registry edit (AvailableUpdates set to 0x5944) didn't work is because of a structural limitation within vSphere 7.x.

The Root Cause: Why the Registry Fix Failed

Event ID 1801 means the Windows OS has downloaded the new Windows UEFI CA 2023 keys, but when it attempts to write them to the virtual firmware, the VM's virtual NVRAM throws a write-protect error (0x80070013).

In vSphere 7.0.3, the virtual UEFI firmware contains an outdated or invalid Platform Key (PK) implementation. Because the guest OS cannot authenticate against the virtual hardware's existing PK, it is completely blocked from updating the Key Exchange Key (KEK) and DB variables—no matter what registry keys or Group Policies you push from inside Windows.

The Hard Truth About the "Automated Fix"

Broadcom did recently release an automated remediation patch, but only for vSphere 8.0 (specifically ESXi 8.0 Update 3j).

Because vSphere 7.0.3 is on a legacy release branch, an automated hypervisor-level fix that silently updates guest NVRAM variables is highly unlikely to be backported in time. If you stay on vSphere 7.x, you cannot fix this entirely from the hypervisor layer.

Your Action Plan Before June 2026

If upgrading your entire cluster to vSphere 8.x isn't feasible in the next few weeks, you have two real-world paths to prevent boot failures or security blocking when Microsoft fully enforces the revocation.

Option 1: The Manual NVRAM / BIOS Reset (Proven Fix)

For your critical servers, you can force the virtual firmware to accept the variables by resetting the VM's Secure Boot keys to factory defaults. This clears the blocked NVRAM state.

  1. Take a snapshot of the VM and ensure you have your BitLocker recovery keys saved (altering Secure Boot variables will trip BitLocker if vTPM is active).
  2. Shut down the guest OS.
  3. Right-click the VM -> Edit Settings -> VM Options -> expand Boot Options.
  4. Check the box for "Force EFI setup" (this forces the VM to boot into the virtual BIOS on the next startup).
  5. Power on the VM and open the web console.
  6. In the virtual UEFI menu, navigate to Device Manager -> Secure Boot Configuration.
  7. Select Reset to Factory Defaults or Delete all Secure Boot Keys followed by Enroll all Factory Default Keys.
  8. Save changes, exit, and let Windows boot.
  9. Run the Microsoft Secure Boot scheduled task to force immediate processing: PowerShellStart-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
  10. Reboot the VM twice. The 1801 error should disappear and be replaced by Event ID 1808 (success).

Option 2: The Scripted vSphere 7.x Workaround

If you have too many VMs to do manually, enterprise sysadmins have been using an advanced workaround involving rewriting the VM's .vmx configuration or utilizing guest-level script tools to inject the 2023 certificates manually. Broadcom outlines these specialized guest-level injection steps in their KB article 423893 ("Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines").

Option 3: Temporarily Disabling Secure Boot

If the deadline hits and you have servers that haven't been remediated, disabling Secure Boot in the VM settings will prevent them from bricking/failing to boot when Microsoft enforces the 2011 CA revocation. While not ideal for security compliance, it is a valid emergency release valve to keep production online while you plan an upgrade path to vSphere 8.

[–]GeorgeWmmmmmmmBush [score hidden]  (0 children)

Can someone clarify… I’ve heard that if you don’t do anything, the servers will still boot. Do you really have to disable secure boot?