AAndrejko

We try lock device from Eset Protect connsole with Eset Fulldisk Encryption enable. Block FDE login password.

And now this laptop cannot boot

Hi @FTL
Thank you for sharing this information with everyone. Indeed we are currently experiencing an issue with the Surface Laptop 5 with Secure Core enabled when booting a fully encrypted system on Full Disk Encryption & Endpoint Encryption. The current and only workaround for this is to turn Secure Core off as you've stated above.
We're currently still investigating the issue, but we do actually have a Surface Laptop 5 which we're able to replicate the issue on so I am hopeful we can find a solution to it soon. I can see some investigation work has already been carried out on the matter, however I imagine a fixed version wouldn't be available until after the new year the very least. I'd like to also note other devices with Secure Core enabled don't seem to be affected so it seems targeted towards that BIOS update of the Surface.
I'm sorry for any inconvenience this has caused to yourself or anyone else affected.
I will speak to my team to see if we can publish something in the meantime.
Kind regards,
Ashley

Hi @steve wilson
I believe the Intune wipe/fresh start doesn't do a full wipe of the disk, so the likelihood of encryption data being left behind is quite high and might affect encryption starting again or possibly even lead to the system not being able to boot.
I would highly recommend you backup the data of these devices within Windows, then perform a full wipe of the drive. Using a disk part clean would sufficiently wipe the drive and setup the drive correctly to be encrypted again. Really this is the only way to safely setup a device you've lost access to or not able to manage anymore.
However if these are standalone devices you are able to decrypt the system using the user credentials, you just need to run decryption via the recovery tool - https://support.eset.com/en/kb7894-eset-encryption-recovery-utility-diagnostics Then re-installing EEE and setting up again will be easy.
If these were managed devices, the admin password may be the same as other older devices in your estate, so I would recommend you check these too.
Kind regards,
Ashley

Hi @NobelDwarf
Thank you for your report.
This has already been fixed internally and we'll be releasing a fixed version to combat this issue within the next couple of weeks. 
Kind regards,
Ashley

Hello @eornate
Within a managed environment the encryption keys are shared between teams.
In order for each of those users in your example to have their own encryption key, each user will have to be within their own team with separate encryption keys applied to each of those teams. 
For example there should be two teams, one called for example SaleTeam, the other called Sale1Team, then SaleTeam will have encryption key 1 and Sale1Team will have encryption key 2, then those teams will only have one user each.
Kind regards,
Ashley

Another point that has popped into my mind about this - If you go into the BIOS and go to the security section, then SecureBoot, you may have an option called "Allow Microsoft 3rd party UEFI CA", this option needs to be enabled for our bootloader to function. This is a relatively new thing on certain devices, our bootloader is still signed by Microsoft though. The system may just boot after enabling this if it's disabled. 

Another point that has popped into my mind about this - If you go into the BIOS and go to the security section, then SecureBoot, you may have an option called "Allow Microsoft 3rd party UEFI CA", this option needs to be enabled for our bootloader to function. This is a relatively new thing on certain devices, our bootloader is still signed by Microsoft though. The system may just boot after enabling this if it's disabled. 

Hi @tkrombach
Can you try to create the recovery media again via the Encryption Recovery Tool, however this time select EFI 32 & 64 Bit. I would recommend you wipe the USB beforehand, just to make sure it's not trying to boot the Windows recovery media recovery tool still. 
I haven't seen that particular error when booting the recovery tool but with the Windows RE recovery tool USB, we basically take files from the system where the USB is being created to create the media, so if the above doesn't work I'd suggest trying to create the USB on another system and try again.
Kind regards,
Ashley

If the TPM errors are occurring whilst Windows was installing the update then I would suggest updating the TPM firmware if possible or contacting HP before updating any other HP devices using our software. 
It may be possible the Windows update isn't compatible with the systems TPM firmware or 3rd party software has caused this issue resulting in the TPM not behaving as expected. Unfortunately our software cannot control what other software or firmware does with the TPM so in this case another party I believe is the cause.

Microsoft has an article on how to update your TPM firmware: https://support.microsoft.com/en-us/windows/update-your-security-processor-tpm-firmware-94205cbc-a492-8d79-cc55-1ecd6b0a8022 on Win 10.

Hello all,
This issue was caused by the ESET Package Installer, a new installer has since been pushed to the Protect repository so if you do have an installer producing this error code, please re-download the installer from your console. It should pick up the new version.