The AvailableUpdates registry key and the scheduled task should work the same way as on client machines.

On 2012R2 you will need ESU updates since the July 2025 update is required (and the November 2025 update is recommended to avoid compatibliity issues) and 2012R2 won't receive those without ESU. All the other mentioned server OSes should still be in support so you can have them fully updated without requiring ESU.

What happens when you try to use the AvailableUpdates registry key? Will it jump back to zero or 0x4000, and are there any events logged in system event log?

You should not confuse the Controlled Feature Rollout (CFR) process with the High Confidence rollout via latest cumulative update (LCU) process. The CFR process generally only targets devices that show no signs of being managed (e.g. not joined to a Windows domain) and that have telemetry setting sufficiently high, and that can actually communicate with Microsoft servers.

The CFR process will pick random members of each Bucket, and try to install the update on them even if they are not High Confidence yet, in the expectation that if anything goes horribly wrong™, they will quickly notice via telemetry. If first signs look good, they will push it to a larger group (some percent) of that Bucket, and if the telemetry is positive, it will be (a) pushed to all devices of that Bucket via CFR and (b) included into next monthly update. (How exactly the CFR process picks the initial candidates is not published as far as I know, but I assume there will be some more factors, like whether the user is enrolled to Windows Insider program and/or how often the machine is used, to keep the disruption to normal customers low and the telemetry quality high).

Therefore, CFR process will reach devices faster than LCU process, at the expense that you act as Guinea Pigs for Microsoft.

By default, only non-managed devices take part in CFR process; by setting this registry key, you can basically offer your machines to be Guinea Pigs for Microsoft even if they are managed.

Not using Autopatch myself, but I do not think Autopatch will push Secure Boot updates to devices that are not yet marked High Confidence in any way, so if you want the rate to go up, you'd manually need to trigger the updates (or opt into CFR process via Microsoft Managed Opt In) via one of the supported methods (Intune, WinCS, Group Policy, Registry).

1. Regardless which way you are choosing (Intune, Group Policy, manual), each way will ultimately result in setting the same registry key. So there should not be any "Best way" for triggering the job. Probably the "Best way" is to actually monitor the reasons why adoption rate is not going up (e.g. errors in event log, if any) to determine whether the devices do not get compliant due to  hardware incompatibilities or due to a missing restart)
2. The May Patch Tuesday will obviously provide one more chance for a restart, but I doubt it will guarantee resolution of anything. In case the devices have a known hardware issue (also present in the latest firmware version) preventing the update running automatically, this will not "magically" make the updates work. But there should be a sufficient amount of error information in the event log to diagnose this and to decide whether any actions other than waiting are needed.

As a very general summary, this is roughly correct.

• This does not only refer to the KEK update, but updates of all the Secure Boot keys. For KEK, there also needs to be a signature by the vendor of your firmware (its Platform Key) submitted to Microsoft so that the KEK can be updated.
• Whether a device is considered managed or not depends not only on whether WSUS is used, but also whether the device is domain-joined and whether telemetry is enabled and actually usable, and maybe other factors
• All the mentioned registry options (both for opting in via Available updates and for opting out) are available on all devices, managed or not
• The main difference between managed and unmanaged devices is that unmanaged devices can also receive their update via Controlled Feature Rollout (if they are lucky/unlucky and telemetry suggests that it should be tried), resulting in potentially being updated before the LCU that sets them to high confidence reaches them. However, there is no way to enforce or trigger whether you will be Chosen a Guinea Pig for Microsoft or not (if you are an unmanaged device)
• In case Microsoft considers your device managed, but you have telemetry enabled and explicitly want your device to be used as a Guinea Pig, you can set MicrosoftUpdateManagedOptIn registry key. This only has an effect if your device is considered managed.

Your question boils down to whether a VM snapshot will include a copy of the UEFI variables and/or UEFI NVRAM. I cannot answer this question for all available virtualization solutions, but for those I have been using (Hyper-V, Virt-ualBox, and QEMU/KVM based ones like Proxmox) I can confirm that at least in their latest version, the VM snapshot includes all of this, so it is sufficient to create a VM snapshot to protect against incorrect Secure Boot configuration changes.

That being said, I don't know of any likely scenario where a Secure Boot certificate update can screw your VM so badly that you need to revert to a previous snapshot. In case you use BitLocker in the VM, make sure to have your Recovery Key handy just in case.

(There used to be an older version of Vir-tualBox where not all UEFI variables - like dual-boot configurations - were part of the snapshot, which could cause confusion when restoring snapshots after an OS install - not only related to Secure Boot settings. But I believe this was before Vir-tualBox supported Secure Boot for VMs).

[Ouch, naming of competitor products is not allowed in this community?]

I assume all those machines have Secure Boot enabled? If not, there is no option nor need to update the secure boot certs.

If Secure Boot is enabled, not updating them (on both) will have the same effect as on any other (physical or virtual) machine: The bootloader will remain stuck on the June 2026 version and Secure boot blacklist will not get updated. So an attacker who gets admin access on either the host or the guests could install a bootkit on the (host or guest) machine they had access to once there is any public exploit for that bootloader or any other blacklisted bootloader. In any case the system will continue working and will still receive security updates for all other Windows components.

Let me guess, the device came with all the 2023 certificates from the factory already (Or it has been updated before the OS got reinstalled)? In that case it can happen that the key has not been created at all. I cannot tell what exactly causes the key not being created, but everything is fine if the certificates are there.