Could you confirm that the Secure-Boot-Update scheduled task expects Microsoft's Owner GUID on Microsoft's signatures in Secure Boot? We customize the Secure Boot content and it seems that a different GUID causes the task to break the behavior of GetFirmwareEnvironmentVariableA() (used by BitLocker in other things).

Could you also confirm that updating the firmware SVN (4th step of the revocations) only consists in adding SVNs to the DBX? And that for testing purposes, resetting the DBX is enough to cancel the rollback prevention?