Preparing VMware VMs for the 2026 Microsoft Secure Boot Certificate Expiration

This is a continuation of January’s post about the upcoming secure boot certificate expiration. I’ve put together a script assisted strategy for patching our fleet of VMware vSphere machines by clearing out the NVRAM files in mass.

The first pass on the script has been uploaded to my GitHub as VMW_MSUEFICA2023Patch.ps1 and has so far been successful in test and pre-production scenarios to work through and patch a batch of VMs.

To reiterate on the issue at hand. In June of this year, the Microsoft signing certificates that are part of the secure boot process that have been in place since 2011 are expiring. Replacement of those certificates in the virtual environment cannot be handled from within the operating system because of an invalid platform key in the VMware vSphere virtual BIOS. So far, Broadcom has published two potential solutions. Either, (1) deleting the NVRAM file and allowing the UEFI variables to reset to new defaults on boot or, (2) fixing the invalid platform key through some very manual console work. I’ve opted to implement the first option.

Continue reading

Enterprise Preparation for the 2026 Microsoft Secure Boot Certificate Expiration

Back in 2023 with the release of CVE-2023-24932 (BlackLotus), the conversation around replacing Secure Boot certificates came to light. In the context of the CVE, it was to prevent use of signed and completely valid boot manager that could be exploited to bypass Secure Boot protections. Even without the CVE, those same certificates expire in mid-2026 – this year.

For the average consumer, Microsoft is managing the installation of replacement certificates. For enterprises with managed updates, we’re left to do it ourself. Neither instance addresses the revocation of the old certificates, which remains a manual step. Virtual machines add an additional complication with the KEK certificate – more on that below. Continue reading

VMware App Volumes Datastore Migration – 2.18

This is a guide for migrating App Volumes app stacks, metadata, and entitlements to a new datastore. I’ll also cover the clean up steps to remove references to the old location(s). What will not be covered are writable volumes.

These instructions are intended for App Volumes 2.18 and may be applicable to other versions in the 2.x branch. The steps for metadata cleanup were obtained through collaboration with VMware Business Critical Support.

Update: These steps continue to work through at least App Volumes 4.9 (2212).

Requirements

  • Administrator role in vSphere vCenter.
  • Administrator role in App Volumes Manager.
  • Administrator privileges to the App Volumes Manager operating system.
  • Access to the App Volumes database server, SQL Server Management Studio, and at least DBO privileges on the App Volumes database.
  • A recent database backup in case a rollback is required.

Summary Steps

  • Use Storage Groups to duplicate existing app stacks and metadata to a new datastore.
  • Remove the Storage Group after duplication has occurred.
  • Remove the old datastore.
  • Metadata cleanup

Continue reading

vCenter Storage Providers appear Offline after Host Certificates are Installed

I ran into an issue where configuring vSphere with an intermediate signing certificate and replacing certificates on all hosts would cause the storage providers to go offline. Refreshing host certificates would also cause the issue.

VMware support determined the cause was the removal of the vCenter SMS certificate in the hosts local trust store. This certificate is not pushed to the hosts when the trust store was refreshed. This behavior occurs at least on vSphere 6.7 and 7.0. To resolve the issue, it is necessary to manually add the SMS certificate to the hosts trust store.

Continue reading