Unable to apply policy to device that has been imaged

So we've just deployed 2017 U3 so we've started to look at deploying FDE to our laptop fleet.

As a test we freshly imaged a laptop, applied a FDE policy and all worked fine. We then reimage the device and then the policy comes up as status of "No policy enforced"

I then tried a clearing zis data and reimaging with the same result, also did a DD over the MBR as I wasn't sure where the encryption key is kept with FDE, no go either. We also tried unassigning and reassign the FDE policy and trying a different FDE policy but the same issue occurs.

This is the fde.log from the machine https://drive.google.com/file/d/1ppwZ5CxlSIZ1tWIHh1sS-YVXPKQ9gQwr/view?usp=sharing

Main lines that stands out to me are
14:11:55, 12.10.2018 ERROR N32FDE: Stored KEK is wrong ! 00 00 00 00
14:11:55, 12.10.2018 ERROR N32FDE: FDE32: EncryptDEK() failed!

On the other laptops that we've applied FDE to and it is working on there is no c:\fde.log, assuming it's only created on errors. We tried reimaging another laptop and ended up in the same situation with it.

Any suggestions? We're using "Microsoft Windows 10 Enterprise LTSB x64 Version 1607 Build 14393"
  • Make sure "Secure Boot Manager" is first in your UEFI Boot Order.
    I've seen similar errors when it is not...
    Failure of "Secure Boot Manager" to be 1st is often related to some type of "Lock" setting in the UEFI.

    https://support.microfocus.com/kb/doc.php?id=7022842
    https://support.microfocus.com/kb/doc.php?id=7022836

    I realize this does not explain the "Imaging" angle, but that is the only hit I received for that error...........


    mmoshcs;2488769 wrote:
    So we've just deployed 2017 U3 so we've started to look at deploying FDE to our laptop fleet.

    As a test we freshly imaged a laptop, applied a FDE policy and all worked fine. We then reimage the device and then the policy comes up as status of "No policy enforced"

    I then tried a clearing zis data and reimaging with the same result, also did a DD over the MBR as I wasn't sure where the encryption key is kept with FDE, no go either. We also tried unassigning and reassign the FDE policy and trying a different FDE policy but the same issue occurs.

    This is the fde.log from the machine https://drive.google.com/file/d/1ppwZ5CxlSIZ1tWIHh1sS-YVXPKQ9gQwr/view?usp=sharing

    Main lines that stands out to me are
    14:11:55, 12.10.2018 ERROR N32FDE: Stored KEK is wrong ! 00 00 00 00
    14:11:55, 12.10.2018 ERROR N32FDE: FDE32: EncryptDEK() failed!

    On the other laptops that we've applied FDE to and it is working on there is no c:\fde.log, assuming it's only created on errors. We tried reimaging another laptop and ended up in the same situation with it.

    Any suggestions? We're using "Microsoft Windows 10 Enterprise LTSB x64 Version 1607 Build 14393"
  • Thanks Craig,

    You were correct, what made it non obvious is at least with our laptops after imaging we see 2 secure boot managers, one at the top of the order which didn't work and one at the bottom. Restoring defaults in bios removed the non functional secure boot manager entry. Checking the laptops we haven't reimaged there is only 1 secure boot manager which is at the top of the order.

    Wondering if it might just be a quirk with the Lenovo units we've tested on. We do use ENGL in case that has any relevence.. Now we know we'll just check the boot order post imaging.

    Thanks
  • If Possible....
    I would open an SR to help investigate further....

    I've never seen a double listing....
    Maybe there is a bug in code someplace, where it gets added again wrong instead of re-ordered....


    mmoshcs;2488938 wrote:
    Thanks Craig,

    You were correct, what made it non obvious is at least with our laptops after imaging we see 2 secure boot managers, one at the top of the order which didn't work and one at the bottom. Restoring defaults in bios removed the non functional secure boot manager entry. Checking the laptops we haven't reimaged there is only 1 secure boot manager which is at the top of the order.

    Wondering if it might just be a quirk with the Lenovo units we've tested on. We do use ENGL in case that has any relevence.. Now we know we'll just check the boot order post imaging.

    Thanks