Event details
202 Comments
In a vmware 8.x environment we can see null PKs and empty DBX from guest VMs with secure boot enabled. KEK and DB contain 2011 MS CA certificates.
What should I expect in this scenario?
Is the empty DBX correct?
Will this VMs automatically update the certificates?
With a null PK, the certificates cannot be automatically updated by the guest OS. If TPM is used, the certificates cannot be automatically updated by the firmware / virtualization solution.
For the empty DBX, you can push the DBX update via AvailableUpdates 0x0002 and check event log if it sticks.
In general, ask VmWare not Microsoft :)
When does Windows Boot Manager get swapped from 2011‑signed to 2023‑signed
On machines that have either Secure Boot disabled or already have 2023 certs, it got swapped when they installed Febuary 2026 LCU.
In other cases when the certs get applied by High Confidence or registry settings after that, the boot manager will get swapped after the next reboot after successful installation of the certificates.
We have very large Windows server environment and most of them are VM's running on vmWare platform. does this applicable to vm's also?
If the VMs are using Secure Boot, yes.
Are there any updates regarding ESXi VMs failing to install the KEK certificate? From research Broadcom and Microsoft were looking into this
Would there be any changes required in the WDAC policies since we have policy updated with anything to be allowed signed by the cert Microsoft Windows Production PCA 2011. So when this is going to be replaced with new PCA 2023 cert, should we update our WDAC policy with the new cert?
Answered at 54:45
If the devices don't have updated certificates after June 2026, will there be need to disable secure boot, so they to be able to boot?
Our devices are shipped with OEM Windows Pro and are later upgraded to Windows Enterprise via Intune policy. On a large subset of these devices, the Intune configuration profile used to opt devices into Microsoft‑managed Secure Boot certificate updates is failing with Intune error 65000, and corresponding event logs indicate the policy is being rejected by licensing rather than by Secure Boot or firmware state.
My question is:
- Is this a known and acknowledged issue when Secure Boot certificate updates are applied to devices that have undergone OEM Pro → Enterprise conversion via Intune? and what what is the workaround?
Do you use Hotpatching? We still get error 65000 on those Intune policy settings too. Rumours are it's because of Hotpatch. We've resorted to using Group policy instead.
I am currently experiencing this issue as well and working with Microsoft through an open support case.
To kick off Secure Boot cert updates, do we have to set the registry value (or Intune policy that sets it)?
If the Boot Cert is not updated, and an attempt to install a CU that contains updates to the Secure Boot - will the entire CU KB fail to install?
No.
- Updates to DBX will be applied after the reboot by the scheduled task anyway.
- CUs will continue to ship two boot managers, one for 2011 cert and one for 2023 cert. The update will install the 2011 boot manager (without the new fixes) if the 2023 cert is not present.
Simonb1Microsoft
Any particular attention point or difference on the process for Azure Confidential Compute virtual machines?
Answered at 31:15
