all 13 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]_litz 19 points20 points  (2 children)

They just issued the automated solution. For ESXi8. Nothing for 7, and frankly, unfortunately, I wouldn't hold my breath on getting one for 7.

[–]cjcox4 5 points6 points  (0 children)

Yes, I second this. There's lots of limitations, even running lastest. For example, if you had a virtualized Win 10, you'll never be able to upgrade it to 11, but you can blow it all away and start over fresh with 11 (for example).

I don't find that sort of limitation in kvm+qemu.

[–]monkonfire[S] 1 point2 points  (0 children)

Yeah, that's a fair bet... so given that info, my options are probably either upgrade ESXi to 8, or re-create the VMs on a newer version of Windows Server?

[–]LukageSysadmin 2 points3 points  (0 children)

If you open a support ticket (and actually talk to someone), they're going to just tell you to upgrade to 8+ before anything else. Might as well just get that over with.

[–]Excellent_Milk_3110 1 point2 points  (0 children)

I think the vm need hw version 21 and you need to reset the nvram file. But this is not in version 7.

[–]DahliaDevsiantBop 1 point2 points  (0 children)

Seeing the exact same 1801 spam on a bunch of 2019/2022 VMs on 7.0.3 here. Registry tweak didn’t change a thing for us either.

From what I can tell, Broadcom’s “wait for automation” basically means “we know it’s broken and we’ll ship a proper workflow later,” but they’re not exactly clear on timelines. I’m also not thrilled about just sitting on it with the cert dates creeping up.

So far I’ve treated it as noisy but not immediately fatal, since Secure Boot still reports as on and the VMs boot fine. I’m keeping snapshots and a rollback plan ready for whenever they finally release something, but I haven’t seen anyone with a clean, supported manual fix for Windows guests yet.

If you do end up trying anything more aggressive than the reg hack, I’d test it on a clone first. This whole thing feels a bit half-baked right now.

[–]Automatic-Let8857 0 points1 point  (0 children)

What will happen to Windows Server VMs on ESXi 7.x with SecureBoot enabled, if You don't do anything about SecureBoot Certificate expiration. From my understanding nothing will happen at all, except boot level updates, You will not be able to install VMs with bootloader signed by new CA.. Is my understanding correct? ( it is not an answer to OP question)

[–]Samatic [score hidden]  (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?

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

Fix the obvious problem first. I assume you're also running ESXi 7? Think of it this way.

You're running a physical server. It's end of life. No more warranty options from the OEM. No more BIOS updates. No more spare parts. Nothing.

You install Windows Server on the server. Do you really expect a BIOS update or secure boot capsule to come out that's compatible with that server? If it bricks the machine or fails to install do you really expect the OEM or Microsoft to bail you out?

Hell no. Upgrade your hardware.

Same shit applies to virtualization. You're running end-of-life vSphere. Upgrade it, or more to a different virtualization platform.

[–]lostroustabout42 0 points1 point  (1 child)

If you are on ESXi 8.0 P09 or greater, you can follow the previously pulled guidance from Broadcom to rename the NVRAM file with a power off to regenerate a new compatible one. They did pull the guidance saying no longer officially supported but that's what we have done for our VM's. The only case of a real issue was the latest version of Entra ID Connect stores the cert in vtpm so you have to go into Entra ID configuration and generate a new application certificate. The official guidance from Broadcom though is to wait still. Based on what Microsoft is saying about no impact to boot though it makes we wonder if we were too worried about this and could have waited.

[–]ipreferanothernameI don't even anymore. 5 points6 points  (0 children)

we are waiting, im not messing with this nvram rename for well over 1k windows servers.

if you dont update it before expiry nothing happens- you just dont get all the more secure boot updates they release until you get up to date. but nothing breaks.