Hyper-V based PVS Targets using Secure Boot Become Unbootable After Applying Windows Updates to the vDisk

book

Article ID: CTX696473

calendar_today

Updated On:

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.

image.png

 

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."

"Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it."

Cause

This behavior would follow a pattern like below:

  1. 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.
  2. 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.
  3. 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 Hyper-V deployments server 2022 and 2025:

  • Ensure new certificates are deployed:
    • Apply the latest Windows Updates to all Hyper-V hosts server 2022 and 2025.
    • If using Server 2019 as the host, then follow the instructions at the end of this section on every host to ensure the new certificates are deployed.
  • Upgrade all PVS components to 2511 CR or later.
  • Update Target devices booting via BDM
    • Perform a BDM Update operation for any VMs using BDM Disk boot
    • Create a new BDM ISO and update all target VMs using ISO boot to use this new ISO

 

Important Notes

  • Any VM that is also using a TPM must be reprovisioned - it is not possible to update the certificates in this case 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.

 

 

Instructions for deploying the new certificates on Server 2019:

Windows Server 2019 is fully supported for the new 2023 Secure Boot certificates, but because it is an older OS, the update behavior is more conservative compared to Windows 11.
While the certificates are included in the monthly Cumulative Updates for Server 2019 (specifically those released from May 2024 onwards), they are often not applied automatically to avoid potential boot issues on older hardware or virtual environments.

  • The “Support Status” for Server 2019 Physical servers running 2019 is that they can receive the update, provided the server’s BIOS/firmware is modern enough to handle the 2023 CA.
    However, note that unlike Windows 11, which might “auto-update” once Microsoft gains “high confidence” in the hardware, Server 2019 typically requires an administrator-initiated trigger through the registry.

Trigger the update on Server 2019
If you have confirmed your Server 2019 VM is fully patched but the certificates are still the 2011 versions, you can manually trigger the deployment using the following steps:

  1. Set the Trigger Key: Open an elevated Command Prompt or PowerShell and run:
    • reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
    • The value 0x5944 tells Windows to deploy all new 2023 CAs and the new signed Boot Manager.
    • Caution! Refer to the Disclaimer at the end of this article before using the Registry Editor.
  2. Run the Scheduled Task: Windows uses a specific background task to process these certificate changes. You can start it immediately:
    • Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
  3. Reboot: A restart is usually required for the Windows Boot Manager to switch to the version signed by the “Windows UEFI CA 2023.”
  4. Verification: After the reboot, run this PowerShell command to see if the 2023 CA is now in the allowed database (db):
    • [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
    • Returns True: You are protected and ready for the 2026 deadline.
    • Returns False: The update failed. This is common in Hyper-V if the VM’s “Secure Boot Template” is set incorrectly.

Issue/Introduction

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

Additional Information

Windows Secure Boot certificate expiration and CA updates 

  • https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e

 

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

  • https://support.citrix.com/external/article/CTX696455