Answered at 14:30 in the video.

Secure Boot process is completely separate between Guest and Host, the order does not matter.

To enable secure boot on the host, the host needs to be powered down. This will obviously prevent the VMs from still running, but it does not matter whether they are shut down or paused.

???

Yes, please assist! 

Answered at 5:30 in the video.

One addition, even if they are added to the ISO, this does not mean they will update any "leftover" devices during the installation phase. It only means that those media can boot from machines that do not trust the old certificates any longer.

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.

You will need an Intune policy do deploy the AvailableUpdates registry key to trigger Secure Boot Update tasks on demand. See details here: Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support.

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.