Our Scale Computing HE550 cluster runs Windows Server 2022 Datacenter VMs with UEFI and virtual TPM enabled. Backups are handled through Acronis Cyber Protect Cloud, stored on a local Synology system, and then replicated to the cloud.
When we restore existing production VMs, they fail to boot with an Access Denied error under Secure Boot. The VM only starts if Secure Boot is disabled, or if the Secure Boot keys are reset. Support from both the platform and backup vendors has been investigating for nearly a month without finding a clear cause.
I created several new test VMs with different configurations, including domain joining and endpoint protection, but their restores worked normally. Restores also work for VMs created with UEFI alone. The problem seems to appear when virtual TPM is enabled, although I have not confirmed that it is the actual cause.
Could this be related to older UEFI Secure Boot certificates in the backup or VM firmware? The cluster may need an upgrade before restored VMs can receive the newer 2023 certificate authority keys. I'm looking for ideas on how to confirm the cause and restore these VMs without disabling Secure Boot or manually resetting the keys.
1 Answer
This sounds more like a mismatch between the Secure Boot certificates in the older VM or backup and the newer virtual firmware presented during the restore. The 2023 UEFI certificate updates changed which bootloaders firmware will trust. Resetting the keys works because it replaces the VM’s key database with the current set.
That would also explain why newly created test VMs restore correctly: they were created after the newer certificates were available, so their firmware and backups already contain the expected trust information. Older production backups may contain an older boot environment that the updated firmware rejects.
I compared the certificates in a production VM and a restored VM after temporarily disabling Secure Boot. They appear identical, but the restored VM still seems to lack the newer certificates. I’m not sure whether this is a missing certificate issue or an expired/invalid certificate being rejected during boot.
That would fit what we’re seeing. The new test VMs restore normally, while older production VMs do not. I’m planning to upgrade the cluster so the virtual machines can receive the newer certificate set, then I’ll test another restore.