BitLocker Could not be enabled. WIN10Pro Build 1709 SGN8

Hello All!

I'm experiencing a seemingly identical issue. I have a sysprepped, Windows 10 1709, Clonezilla image. I image a machine, and then install Sophos Safeguard. It reboots and I'm prompted to put in a PIN. It reboots again, I see the C/R screen, it then skips the BitLocker screen, and goes to the login screen. I login and this error message is displayed: "BitLocker Could Not Be Enabled. The BitLocker encryption key cannot be obtained from the startup key or recovery password. Verify that you have the correct startup key or recovery password and try again. C: was not encrypted".

I've tried quite a few things so far, including:

Clearing the TPM.

Verifying that the computer is set to UEFI boot.

Verifying that the TPM is set to Discrete TPM vs. Intel PTT.

Manually editing local group policy to what SOPHOS specifies for encryption to work properly.

Followed the instructions of these SOPHOS KB articles: https://community.sophos.com/kb/en-us/124400 and https://community.sophos.com/kb/en-us/120416 .

Built the image on a different computer. 

Reinstalled TPM drivers.

If I manually turn on BitLocker, encrypt the machine, and THEN install SOPHOS Safeguard, it works properly. This is far from ideal though. This issue seems to be related to 1709 and/or Sysprep. The 1703 image I had for months worked flawlessly.

Any ideas of potentially fixes or things to try would be greatly appreciated!

Derek

Morning Derek - If you manually enabled BitLocker and it worked then I would point the finger of blame at C/R I think.

I had lots of issues with C/R - similar to what you described and sadly the list of true hardware that's listed/recognised as compatible with Sophos SafeGuard C/R is small.

If you want to continue using C/R make sure it fits these requirements. For me it was easier to disable the function.

https://community.sophos.com/kb/en-us/120433 Note here that ALL HP's (which we have a  lot of) are listed as NOT compatible! 

I would recommend that you try this same procedure but without C/R (either by switch for the MSI or manually installing the client and disabling the C/R in the BitLocker section)

Hey Michael!

Thank you so much for the quick response. You're absolutely right. After uninstalling the client, and reinstalling it without C/R, everything kicks off/functions perfectly. Thank you for pointing me in the right direction!

At least from what I'm seeing, this appears to be specific to 1709 AND SysPrep AND C/R. It doesn't seem to be hardware specific. I've been able to clean build 1709 Dells and Lenovos, with C/R enabled (but not SysPrep'd), and everything works fine. Also, before 1709, I was using a SysPrep'd 1703 image, installing C/R (on the exact same models of Dells and Lenovos), and it also worked without issue.

I don't expect you to have an answer for that. More just mentioning how oddly specific this issue appears to be. It's working without C/R though, and that's good enough for me. Thank you again!

Derek

Hi Derek,

We are having the SAME EXACT issue here where I work. We're actually considering removing C/R from our build process all together. However, we are somewhat nervous about the potential decrease in overall security that this move may introduce. I'm very curious to hear yours and Michael's take on this?

Thank you,

Dave

That's good news Derek ,thanks for the update! Could you do me a favour and mark it as an answer to help others? It would seem it's Dave's issue too?

All the best

Good morning Dave - Thanks for posting.

I too when I started using Sophos SafeGuard was having these issues. Back then I was using 1511 and although we'd forced C/R with a MSI switch it wasn't always enabling and left many machines unencrypted (but worse - the belief of the owner it WAS encrypted)

I also deal with a lot of different user types here - some absolute experts in their fields and some who will struggle with the real basics. Asking some of these users to read out a rotating code was difficult. Some of my users are abroad too and English is not their native language so using the phonetic alphabet over a bad quality phone line...You can just imagine!

I did seriously consider the security implications but we felt that we had enough mitigations to justify this change. No system will ever be flawless and we mitigated and justified what issues we considered to still be a risk.

It's a small decrease in security in my opinion, but with this change I forced TPM+PIN rather than the previous TPM only. This also helped to reduce the risk.

Support has never been to the level I'd like to be quite frank, but I'm probably being fussy. I did log a few of these issues with Support and when one response was "It won't work with HP" it was the final nail in the coffin for me. We have a lot of HP's here - some had successfully enabled, some had not. Most Toshiba seemed to be fine but I didn't want an estate with a mixed solution - especially for the end-users. "If you have an Dell X1001 you need to do this, but if you have a Dell X1002 you'll need to do something different" type experience would be a real issue for me and would hardly help "promote" encryption across the company.

I don't have self-serve here although I do have it enabled for T2 technical staff, so users need to pass clearance before a recovery key will be issued. I feel this also helps add to security but I appreciate there's an overhead to this. 

I don't miss C/R at all and it's definitely a better experience for my end-users. I have a VERY mixed estate here (Dell, Microsoft, Toshiba, HP, Samsung, ASUS, Lenovo, Acer, Sony and Fujitsu models have all been seen) and I needed a solution that would suit the common choice. 

Thank you for the detailed response. You've certainly provided some perspective on this issue for us. And I think you've helped Derek a great deal as well. 

Thank you for the detailed response. You've certainly provided some perspective on this issue for us. And I think you've helped Derek a great deal as well.