AAndrejko

I believe @santoso has the best recommendation for this. Once the command has been processed by the workstation, the device will instantly bluescreen and nobody will be able to login to the workstation. All the data will be encrypted too so zero chance of anyone accessing it without recovery data.

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

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 @Damian Hallay You can tell for sure by running an elevated command prompt and typing "manage-bde -status" More information on that can be seen here - https://support.eset.com/en/kb7191-using-bitlocker-and-eset-endpoint-encryption-full-disk-encryption-at-the-same-time

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

I'm very glad to hear that it has been resolved! In a future version of our software we do detect whether this has been enabled or not and allow/deny encryption starting when necessary so hopefully you wont run into a non-booting system in the future. All the best, have a good day.

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 Leon, You may find the switch within the BIOS under Config -> Storage -> Controller Mode. Although I'm unsure what Thinkpad device you have in particular, the emulator has lots listed, so I'm unable to say for sure where it would be. I can see you've submitted a ticket and it looks like it's being looked at now. I've given the assignee a message now too so hopefully they will be in contact soon, I'll give them all the info we've discussed on here but hopefully with a little more digging into the BIOS you should be able to find that switch to get the drive to detect in the recovery software. I would also like to mention though if this device is a brand new device, or one where you've got a backup you can restore from, it may be worthwhile to simply wipe and re-install Windows, restore from the backup if you have one. Then before you attempt the process again, grab a diagnostic log from the machine in question and send that to support, steps on that can be viewed here - https://support.eset.com/en/kb7123-eset-encryption-diagnostics-tool . I do apologise for the issues you've faced with the software, some hardware and certain configurations can cause issues which we can't always detect or work around. Kind regards, Ashley

Hi Leon The case with that is usually the system is using a RAID bus, which we cannot read. The solution to this would be to temporarily go into the BIOS and turn the disk operation mode to AHCI instead of RAID. More info on that here - https://support.eset.com/en/kb8338-error-disk-enumeration-failed-in-eset-endpoint-encryption-or-eset-full-disk-encryption If that still doesn't work then I'd urge you to submit a ticket straight away with what info you have.

Hello Leon For this process you don't need the recovery file at all. It's merely at a diagnostics stage at the moment so you'll still be able to get the disk information without the recovery file. Within the media creation tool feel free to select diagnostics only when selecting the product type. If it's stuck on SafeStart somehow, it usually only requires a couple commands to boot Windows as nothing has been encrypted yet.

Hello Leon, It sounds like your system has rebooted to do SafeStart however the system is having some kind of issue loading SafeStart or accessing the files to boot back to the OS. In order to properly diagnose this is the issue please can you use the Recovery Utility to grab the disk information of affected system, steps on that can be viewed here, the process will only take a few minutes - https://support.eset.com/en/kb7894-eset-encryption-recovery-utility-diagnostics#DisplayDiskInfo Once you have done that, please can you submit a support ticket with the log files from the USB device attached, if we need further logs then we can communicate via the ticket - https://www.eset.com/de/support/kontakt/

Thanks for submitting a ticket to support. One last thing, as the support teams will most likely need the logs from the recovery tool. Does the system support Legacy booting? Booting a recovery tool USB in WinRE mode whilst booting in Legacy mode may yield a different result when trying to boot the tool.

I would also like to add, if you successfully decrypt the device, an immediate backup (If one has not been taken already, or if the data is crucial) should be taken. The error you are presented with is the software saying that the data used to boot the system is not complete or as expected. This may be due to another encryption vendor being enabled, or a change in disk layout or even a hardware issue, amongst other things. If you would like to go ahead and encrypt the device again and still encounter the issue, I would suggest you submit a support ticket https://www.eset.com/int/support/contact/ . We will be able to better assist you there as we would require additional logs.

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