@Shuttleu Your machine is enrolled correctly. The “failed” message is wrong for your case, and the missing PIN screen is expected.

Why “Automatic Secure Boot enrollment failed” appears. The task writes db, then KEK, then PK. A PK write in Setup Mode takes the machine out of Setup Mode. The task then reads the SetupMode variable to confirm this. On your firmware, that check did not see the change before the reboot. Your evidence shows all three writes landed: the firmware is now in Custom Mode, and the second run found the certificate already in db. The text “still in Setup Mode” in that message is also wrong when the PK write already happened. We will fix the check and the message in FOS.

Why there is no PIN screen. The attended item opens MokManager directly. “Enroll key from disk” enrolls MOK.der at the Yes/No prompt. It does not stage a request, so no PIN screen comes after the reboot. The PIN screen is for a request that the FOS task stages on a machine with a vendor PK. Also, MOK only matters when the client boots through shim. You boot snponly.efi, which is signed with your DB key, so db trust is the trust that counts. You do not need the MOK step on these machines.

One thing to know before you roll this out. The unattended task enrolls this FOG server’s own PK and KEK, with Microsoft’s KEK and db entries kept beside them. Your machine’s platform key is now the FOG server’s key, not a vendor key or one of your own. To change db or KEK later from the OS, you need an update signed by the FOG server’s KEK or PK.

Could you tell us the make, model and firmware version of this machine? That lets us confirm the firmware behavior and test the fix against it.

On #2064: the fix (#2065) is on dev-branch. With it, a FOG-managed DHCP config hands out snponly.efi when the installer rebuilds iPXE with your CA. You already did this by hand, so nothing changes for you.