Kstainton

Sorry for the late response. I couldn't sent the log files do to the size of one of them. But this solved it on the endpoints that I was getting this error.

Hi Kieran,
That's worked for me on the 2 devices I was stuck on thank you.

Thank you for all the help kieran

Hello,
I succeeded with a command line in PowerShell.
Thanks

Hi @Mromeroq,
The Encryption Key is unique per EFDE Workstation. It is stored in an Encrypted location on the disk and is used to gain access to the workstation by using the users credentials to authenticate against.
Thank you,
Kieran

Hi @NobelDwarf,
Yes it sounds exactly the same in that case, and we are still currently researching this with MS to see what can be done in future. But for now, 'Secured Core' will have to be disabled to function with EFDE / EEE.
Thank you,
Kieran

Yes, seems to only affect what we believe to be Firmware Version 9.101.143.0 at this time for the Surface Laptop 5 specifically and not the former Firmware Version 7.10.143.0. So some people may notice their Surface Laptop 5 machines be fine initially and then once updated to the latest firmware start experiencing the issue and need to disable 'Secured Core' as mentioned previously.

Hi @LeonelVargas96,
Thank you for sharing all the necessary information regarding your issue.
It seems there is a problem with the machines TPM and as it currently stands, cannot be used for FDE with EFDE.
I see the following error in the logs you provided:
[connector] [error] [3888] DLPCOMM_FDE_ConfigureTPM failed with error 3225157640
Which means "A TPM command failed", along with an additional error:
[connector] [critical] [3888] DLPCOMM_FDE_EnhancedCommence returned 3225157649
Which means "The required Persistant Handle is not stored in the TPM".
Are there any BIOS/TPM firmware updates available for this machine?
If not, I can only suggest they attempt encryption without using the TPM in the set policy for this particular machine.
I suspect the machine would encrypt if you do not use the TPM for encryption.
Please do let us know if you have any success with firmware updates or simply encrypting without the TPM being used.
Thank you,
Kieran Stainton

Hi @Andras Kovacs,
Unfortunately, it is not possible to "tune" EEE/EFDE to obtain faster R/W speeds. If optimal disk speeds are required, then it does come down to having to use disks that support OPAL 2.0.
Thank you,
Kieran

Hi @Andras Kovacs,
Unfortunately, it is not possible to "tune" EEE/EFDE to obtain faster R/W speeds. If optimal disk speeds are required, then it does come down to having to use disks that support OPAL 2.0.
Thank you,
Kieran

The problem solved.

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 @OBR CTM,
That was going to be the exact thing I was planning to check within the logs.
Glad you worked it out. Thank you.

I have solved the problem, thank you.

Hello, here again. The client was able to remove the encryption with the pendrive tool after trying several times. Thank you very much for all the help provided!

Hi @OBR CTM,
I think we need to up the logging to debug level and then acquire some logs for me so I can see if the Agent is communicating the 'Activation' task and if it is erroring on the EFDE Client with higher debugging.
To do this access the following path in the Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Full Disk Encryption\CurrentVersion\AIS\Logs\Loggers
Change 'License' from "info" to "debug"
Re-attempt the 'Activation' task and leave it time to process (EP Console should update if you it is sent or failed) and then acquire these logs if you have issues: https://www.eset.com/int/support/log-collector/
Thank you.

Thanks for the quick response, testing the solution. When I have feedback I will share it

Quick update, same situation in terms of EFDE reinstallation using Software install task without assigned offline license. We still have 30 minutes. We will wait for software update.

@mkrupa do you have by any chance a couple years old FDE policy containing proxy password and applying it together with some newly created one? If so could you try to recreate that policy from scratch and see if it helps? We noticed some issue in Agents with latest Configuration module.

solve by creating ticket to local support, and removing secondary ssd make the laptop boot again.
thanks btw

Hi @Andres96,
I would suggest submitting this as a support ticket as this isn't likely a simple issue: https://www.eset.com/int/support/contact/
Does this Windows BSOD occur before or after ESET FDE Pre-boot login?
Whilst you are in the process of doing this, let's try and get a little bit ahead of the curve and see if we can gather more logs.
Is their a computer you are able to replicate this issue on consistently? 
If so, could you alter the settings so that Windows generates a 'Complete Memory Dump' as per: https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/generate-a-kernel-or-complete-crash-dump and proceed to FDE as normal. Then, the next time this issue occurs would you be able to decrypt the disk via the ESET Recovery Media Creator. I would like this because if the process of 'Decrypting' the disk allows you to regain access to Windows without formatting and performing a fresh Windows OS install, we may be able to gather the 'Memory Dump' which will hopefully tell us more.
Thank you,
Kieran

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

Never mind... 5 minutes later it started to work. Sorry for wasting your time.
Regards
Jakub

Hi @santoso,
EEE will still have it's Pre-Boot Authentication screen and require a password to access the disk, and the whole disk will remain encrypted.
Please see this KB to understand what happens when your EEE license expires: https://support.eset.com/en/kb7536-expired-eset-endpoint-encryption-license
Thank you,
Kieran

Hi Kstainton,

I managed to find the find the laptop with an issue by clicking on the tab "Computer with missing  recovery". initialy i was clicking on the new policy thinking the system will automatically assign the computers with issues.