You can enable secure boot with cctk --secureboot=enabled. But you cannot disable it.
Secure boot prevents the upgrade from Windows 1809 to 1909.
And now? Manual disable secure boot on thousand of devices?
@remie2 If an application running within Windows could disable Secure Boot, that would rather defeat the point of Secure Boot, since that would mean malware that had admin access or could obtain it through a privilege escalation vulnerability could disable Secure Boot in order to infect the bootloader files with a rootkit.
But more to the point, Secure Boot absolutely does NOT prevent upgrading to a new Windows 10 release. Microsoft has supported Secure Boot since Windows 8, and any upgrade from Windows 8 to any newer Windows 10 release can proceed just fine while Secure Boot remains enabled -- assuming you're not using install media that has modified bootloader files, of course, but in that case you'd have to keep Secure Boot off permanently, not just have it disabled for the upgrade. I explained this a bit more in this post in another thread where you also made this claim, but due to the way Secure Boot works, there is absolutely no scenario where you'd have to temporarily disable it just for an upgrade. If you'll be able to boot the new OS with Secure Boot enabled, then you don't have to disable it temporarily during the upgrade process. And if you will NOT be able to boot the new OS with Secure Boot enabled, then you'd have to KEEP Secure Boot disabled permanently, not just during the upgrade. (Ok, I guess one weird use case would be a scenario where your enterprise upgrade process involved booting into some environment that itself did not support Secure Boot. In that case, then yes you'd have to disable Secure Boot for the purposes of booting into that custom upgrade install environment. But in that case, that's something particular to your environment, and it's also a bad and outdated design. Build your custom environments using WinPE 4 or newer and boot into them in UEFI mode, and they will support Secure Boot.)
I have to disable secure boot or the upgrade from 1809 to 1909 does not work.
The question is why do I have to disable it. It's an SCCM OSD deployment. After that SCCM does an upgrade to 1909 with feature update (not a tasksequence but a windows update). In the logging I find the following "upgrade installation result indicates that commit cannot be done". The update does not work on none of the devices, till I disable secure boot.
I know secure boot should not prevent an update. But it does. It this case.
@remie2 Then there's something wrong with your SCCM deployment. I work in an environment that uses SCCM to manage over 100K client systems and nearly as many servers. We've been deploying Windows upgrades through SCCM to clients for a while now and have never needed to disable Secure Boot on any of them during that process. And while we don't officially support in-place upgrades to Windows Server, we have successfully done that using SCCM in test environments without disabling Secure Boot. As I said above, make sure your OSD environment is built using at least WinPE 4 (WinPE 3.1 does not support Secure Boot) and also make sure that your environment and your systems are set up to support booting into that environment in UEFI mode. If you're using PXE boot, then PXE booting in UEFI mode might require enabling "UEFI Network Stack" in the BIOS, otherwise any PXE booting would occur in Legacy BIOS mode -- and it is not possible to use Secure Boot if you need to boot in Legacy BIOS mode. But if that's what is happening in your environment, then you're going to be forced to fix that soon anyway because Intel will be dropping Legacy BIOS boot support from their CPUs soon, at which point you'll have to make sure you can boot everything in UEFI mode, including your OSD environment.
But again, there is nothing in Windows in general that requires disabling Secure Boot to install a new feature release. Whatever is causing that to be necessary in your environment is something wrong with your environment, and I would encourage you to figure it out and fix it rather than looking for workarounds. I suspect the inability to disable Secure Boot from within Windows is explicitly by design, not an oversight, for the reason I already gave.