After updating with the MCS Machine Catalogs with a golden image that has it's bootloader signed by the Windows UEFI CA 2023, VDAs can fail to boot with “No Boot Media”.

Applies to:

• Any hypervisor where VMs were originally created with only the Windows UEFI CA 2011 certificate in the Secure Boot database
• Citrix Virtual Apps and Desktops (CVAD) — all versions, on-premises and Citrix Cloud

Follow your hypervisor below for resolution steps.

XenServer

For existing VMs, update to the latest XenServer and XenCenter versions and follow the workflow described in the documentation.

For environments where VMs are provisioned and started as needed (e.g. Image Preparation), administrators can currently either disable Secure Boot or roll back the image update. Further updates and releases are underway.

VMware

Recommendation:

On VMware versions earlier than ESXi 8.0 U3j (P09) Build #25429389, Windows updates that deploy Secure Boot 2023 certificates may fail. This occurs because ESXi versions prior to 8.0 U3j create VMs with a null Platform Key (PK). Without a valid PK, the KEK 2023 deployment cannot be authorized, which in turn prevents subsequent DB updates.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Resetting the NVRAM (VMware does not recommend)

  • Remove the NVRAM file on each VM to regenerate it on next boot. This resets all Secure Boot keys and may cause BitLocker recovery prompts on VMs with vTPM.

  • To automate this, refer to the example script (Fix Boot Failure - Reset NVRAM)

• Fix Option 4: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

For VMware, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

Step 1: Upgrade the hypervisor.

For ESXi 9.x: Upgrade to ESXi 9.0 or later.

For ESXi 8.0: Upgrade to ESXi 8.0 U3j (P09) Build #25429389.

For both persistent and non-persistent VDAs without vTPM,

Step 2: Deploy the 2023 certificate to the Secure Boot DB.

For ESXi 9.x,

• Perform Steps 2a-1 through 2a-4 from the machine with VMware PowerCLI installed.

Step 2a-1 (ESXi 9.x): Connect to vCenter.

Step 2a-2 (ESXi 9.x): Stop the VM.

Step 2a-3 (ESXi 9.x): Reset the Secure Boot DB by running the PowerShell cmdlets below. On next boot, ESXi regenerates the NVRAM with the 2023 certificate included.

Step 2a-4 (ESXi 9.x): Start the VM. No Windows Update or scheduled task is required.

For non-persistent VDAs, this can be scripted across all provisioned VMs before the next boot.

For details, refer to Secure Boot Custom Certificates (KB 377306).

For ESXi 8.0 U3j (P09),

For non-persistent VDAs, perform Steps 2b-2 through 2b-4 on the master image.

For persistent VDAs, perform Steps 2b-2 through 2b-4 on each VDA.

Step 2b-1 (ESXi 8.0 U3j): Restart VMs (SilentPK). The PK is automatically updated via SilentPK during reboot.

• For details, refer to "SilentPK update for vTPM disabled Virtual Machines" in Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines.

Step 2b-2 (ESXi 8.0 U3j): Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2b-3 (ESXi 8.0 U3j): Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2b-4 (ESXi 8.0 U3j): Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 2b-5 (ESXi 8.0 U3j): Non-persistent VDAs only. Take a snapshot of the master image and update the MCS catalog.

To automate Steps 2b-2 through 2b-4, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

For both persistent and non-persistent VDAs with vTPM,

• VMware recommends waiting for an automated Capsule Update solution in a future release.

References

• Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

• VMware ESXi 8.0 Update 3j Release Notes

• Secure Boot Custom Certificates (KB 377306)

SCVMM / Hyper-V

For SCVMM (Hyper-V), Hyper‑V Generation 2 VMs use Microsoft-managed Secure Boot keys and trust stores, allowing Secure Boot certificate updates to be delivered through Windows Update without requiring hypervisor-level updates.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

OpenShift

OpenShift will not have the Windows UEFI CA 2023 certificate issue. This is because the OpenShift versions 4.18+ that Citrix supports already include 2023 certificate.

Nutanix AHV

For Nutanix AHV, VMs created on AHV 10.3.1.9 (or 11.0.1.2) or later include the new 2023 Secure Boot certificates by default. However, VMs created on earlier AHV versions do not, and upgrading AHV alone does not automatically apply the new certificates to existing VMs.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Upgrade AHV to version 10.3.1.9 (or 11.0.1.2) or later. VMs created on these versions include the 2023 Secure Boot certificates by default.

Step 2: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB on existing VMs. For non-persistent VDAs, perform Steps 2-1 through 2-3 on the master image. For persistent VDAs, perform Steps 2-1 through 2-3 on each VDA.

Step 2-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment

Step 2-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 2-1 through 2-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

• Nutanix Support. How to update Secure Boot certificates for AHV virtual machines.

Azure

For Azure, VMs created after March 2024 include the 2023 Secure Boot certificates by default. VMs created prior to March 2024 do not, and require manual certificate deployment.

For Azure Local, version 2603 or later is required.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1 (Azure Local only): Upgrade Azure Local to version 2603 or later.

Step 2: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 2-1 through 2-3 on the master image.

For persistent VDAs, perform Steps 2-1 through 2-3 on each VDA.

Step 2-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 2-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 2-1 through 2-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

• Azure Local. Manage Secure Boot updates.

GCP

For GCP, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

AWS

For AWS, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

AWS Workspace Core

For AWS Workspace Core, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

Microsoft is transitioning from the Windows UEFI CA 2011 certificate to the Windows UEFI CA 2023 certificate for signing Windows bootloaders. The 2011 certificate expires in June 2026. This does not mean existing VMs will stop booting — Secure Boot does not check certificate expiration. However, recent Windows Updates can install bootloaders signed with the 2023 certificate. If the VM's Secure Boot DB only contains the 2011 certificate, the VM will fail to boot after receiving a 2023-signed bootloader.

• [Microsoft] Windows Secure Boot certificate expiration and CA updates
• [Microsoft] How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• [Microsoft] Sample Secure Boot Inventory Data Collection script
• [Azure Local] Manage Secure Boot updates on Azure Local
• [GCP] feedbackMicrosoft Secure Boot certificates expiration guide
• Github Citrix MCS SDK Samples. Please check the SampleAdminScenarios in each hypervisor folder