Windows 10 1803 Auto Upgrade with FDE Failing

[Steve_Lander]

Has anyone tried auto upgrading their version of Windows 10 to 1803 with FDE enabled and were successful?  We want to eventually use Shavlik to push out the upgrade, which uses the Windows Update Service, but we are running into the same problems with Shavlik as using the /auto upgrade switch.

I can get this to work manually by following the instructions in this SK article How to upgrade to Windows 10 1607 and above with FDE in-place and going through each of the prompts and turning off everything, but when I run it using the auto upgrade feature | setup.exe /ConfigFile "%SystemDrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini" /auto upgrade /PBRupdate disable | or any of the other switches (which just flat out breaks the .ini file, see Windows 10 Setup Command Line Switches – Home is where I lay my head ) it fails and seems to break the UEFI BIOS somehow and corrupts the upgrade, which it reverts back to 1703.  We then have to reset the BIOS and change it back to UEFI before it can boot again.  

We are using Windows 10 64bit Enterprise 1703 | UEFI BIOS | Fast Boot and Fast Startup turned off | CheckPoint Endpoint with all blades except VPN and capsule docs.

[PhoneBoy]

Did you open a TAC case on this issue?

[Alexandra_Gofma]

Hi Steve, which Endpoint version you have installed?

Only version E80.83 supports Windows 10 1803

Please refer to sk115192

[Steve_Lander]

I was able to upgrade from 1703 to 1803 once I upgraded the Endpoint to E80.83.  Do you know when this is slated to become GA?  

[Kim_Moberg]

Hi Steve

it's in GA today 🙂

Enterprise Endpoint Security E80.83 Windows Clients 

Best regards

Kim

[Sebastien_Rho]

FYI, I had the same issue with a customer of mine, running E80.84 with Windows 10 build 1709, the FDE failed and we to decrypt the drive manually since it was not booting up in Windows (Logged in PreBoot sucessfully though), in the end we ended up opening a case with TAC.

[Soren_Kristense]

Hi

We see the same issue running E80.84, is there a solution?

Best regards

Søren

[Kim_Moberg]

Hi Søren

Did you try e80.86?

BR

Kim

[Felix_Winter]

We have this issue too. Any news about it?

[Steve_Lander]

It seems that this is still an issue for us.  While we tested in the lab and a small sample in production without any issue with upgrading from 1703 to 1803, we decided to upgrade everyone to 1803.  About half the computers we upgraded had an issue.  Some failed the update, and others bluescreened after the update, and the only way to get back to Windows was to reset the BIOS to factory, and if you went back and changed anything in the BIOS (such as turning off fast boot), it would blue screen and you have to reset the BIOS again, and also some are on legacy boot but we cant turn them back to UEFI, but somehow they magically work.

Also the upgrade seems to change things in the BIOS, such as the selection for the M.2 drive.  See screenshot below, it should say "M.2 Check Point Full Disk Encryption Windows Boot Manager".  Our endpoints are on a mix of E80.84 and E80.86, and it happens for both versions. 

Has anyone else had these same issues when upgrading to 1803 with Checkpoint FDE?  I am also opening a case with TAC on this.  

[Steve_Lander]

We have gotten this to work in our environment.  Hopefully in the future updating Windows 10 versions will be more streamlined with the CheckPoint Suite.

We are using E80.84, but this should work for future versions.

First we had to make sure the computers we wanted to upgrade had their boot order set to BCDBOOT by running this .bat file "C:\Program Files (x86)\CheckPoint\Endpoint Security\Full Disk Encryption\fdecontrol.exe" set-uefi-bootmode bcdboot  (see How to upgrade to Windows 10 1607 and above with FDE in-place ).  If BCD is not run, the upgrade will fail after the first reboot.

Then we moved the computer in a policy where the Pre-Boot Environment for FDE was off, so after the upgrade when Windows is applying updates, you didn't have to log in every time through the Pre-Boot.  

We then use WSUS to upgrade 1703 to 1803.  You can probably push it through manually too if you have another method of delivering the update.

Hope this helps!