VMWare and XenServer based PVS Targets using Secure Boot Become Unbootable After Applying Windows Updates to the vDisk

Description

After applying Windows Updates to a PVS vdisk using a master target, and then later booting it on production PVS targets, a boot time error "LoadImage error: Access Denied" is displayed.

Only the master target, which was used when applying the windows update continues to boot.

The vDisk has been updated, so that the Windows Boot Loader is signed by a new certificate.

As documented by Microsoft (see additional information), the current certificates used for validating binaries when using Secure Boot are expiring in 2026 and have been replaced by new CA certificates which will be used in the future to validate that binaries are properly signed. When applying Windows Updates, if the new Windows certificate is detected in the master VM, it will install a version of the Boot Loader that is signed by the new certificate. Later on, if you have target VMs that do not include the new certificate, the resulting vDIsk will not be bootable as it cannot validate the signature of the Boot Loader.

When you upgrade your hypervisor to a version that embeds the new certificates, existing VMs are not updated to include this new certificate by default which is why subsequent boot of the vDisk fails with the above error.

NOTE: the expiration of the existing certificates does not matter and existing vDisks will continue to boot after expiration. The only failure occurs when a new Windows Boot Loader is installed in the vDisk that is signed by the new certificate.

Environment

"Citrix is not responsible for and does not endorse or accept any responsibility for the contents or your use of these third party Web sites. Citrix is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement by Citrix of the linked Web site. It is your responsibility to take precautions to ensure that whatever Web site you use is free of viruses or other harmful items."

Cause

This behavior would follow a pattern like below:

The master target device has the new Windows Secure Boot certificates:
- Windows update may apply new certificate to the master target device UEFI firmware.
- Alternatively if the hypervisor was upgraded to a version that has the the new Windows Secure Boot certificates, and a new master target device is created, then it be created with the new certificate.
When applying Windows Updates, if the new Windows certificate is detected in the master VM, it will install a version of the Boot Loader that is signed by the new certificate.
Subsequently, if target device VMs which do have the new certificate boot the vdisk, it will not be bootable on these target devices, as the signature of the new Boot Loader cannot be validated.

Resolution

The following steps should be followed for VMWare and XenServer deployments:

Upgrade your hypervisor hosts to a version that embeds the new certificates:
- For VMWare that means ESXi 8.0 Update 3j (Patch Release P09) or ESXi 9.x.
- For XenServer you must be running 8.4, November 2025 update or newer.
Upgrade all PVS components to PVS with updated certificates (at time of article it is PVS 2402 CU4 and PVS 2603 with updated certificates)
- The signed PVS bootstrap from PVS 2603/2402 CU4 or superseding product update is required.
- Cumulative updates containing updated signed PVS bootstraps will be released for other maintained PVS versions (but 2603 and 2402 CU4 are the available releases with updated signed bootstrap at time of article edit)
Update or reprovision ALL PVS target VMs that were created before the hypervisor host was upgraded:
- On hypervisor versions which support updating the local VM secure boot database, administrators can use windows to update each target device's local VM firmware
  - Boot an older vdisk or vdisk version without the latest bootloader
    - Alternatively boot target devices with the newest vdisk or vdisk version with the new bootloader, but with secure boot disabled temporarily
  - Using elevated PowerShell, run the commands below to trigger windows to update the local VMs firmware with the new certificate
    - Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944
    - Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
  - Then perform a clean reboot of the VM, allowing windows to cleanly shutdown.
- For VMWare versions running patch level equal to or greater than ESXi 8.0 Update 3j (Patch Release P09) or ESXi 9.x.
  - Administrators can use the above steps to have windows update the local VM firmware.
  - Administrators can refer to VMware documentation regarding use of uefi.secureBoot.db.resetOnce Setting a custom Secure Boot configuration on an existing Virtual Machine
- For XenServer target devices see documentation "Manage UEFI Secure Boot certificate remediation"
If you are currently using BDM partition or BDM ISO to boot your target devices, update those BDM files. If you are using PXE, no action is needed (as the pvsnbpx64.efi file as updated as part of the PVS server upgrade).

Important Notes

Any VM that is also using a TPM may need to be reprovisioned - it may not be possible to update the certificates in all cases as the measurements created by the TPM during boot include the certificates.
Microsoft have documented a manual procedure for revoking the old certificate - this MUST NOT BE DONE as doing so will prevent the PVS boot program from running. A later PVS release will address this.

Issue/Introduction

This article shows how to address the issue for VMWare and XenServer based setups, where PVS Targets using Secure Boot Become Unbootable After Applying Windows Updates to the vDisk