Just small update from me after talking to the support team. It looks like they qualify it not as BOIS issue but as security feature. Obviously for me it looks like a huge bug in current BIOS version as the only workaround is to disable bitlocker at all.

@gdreyv  No, those commands will not fix the issue you described if the Recovery Key prompt only appears when you've changed the connection state of your eGPU.  You didn't say that in your original thread, which was the basis for my original reply that you reposted here.  See the newer reply i just posted for some additional background and possible fixes/workarounds.

And by the way, Dell is correct that this is a security feature.  And it's absolutely not a BIOS bug.  This is how BitLocker is designed to work, for the reasons I already described.  And in any case it's Microsoft's design, not Dell's.  But Dell does offer those BIOS options that are specifically intended to mitigate this issue.

But even if you DID need to run those commands, no you would not have to run those commands for other partitions where you were using BitLocker.  The TPM protector only exists for the OS partition.

@jphughan if you don't mind I will repost your reply here to keep original conversation going in the proper place:

 if you're getting a BitLocker Recovery Key prompt every time you start your system, then it sounds like there's a problem with the TPM.  Getting a Recovery Key prompt is expected in certain situations such as after certain hardware or firmware configuration changes, because in that case it's occurring because the TPM has detected a change from its known and trusted configuration, so it refuses to release the decryption key automatically like it normally does, in case the change is part of an attempt to compromise the security of the system and steal the key.  So that's why you need the Recovery Key.  But if you enter the correct key once at that prompt, then the TPM "reseals" to the new configuration and trusts that going forward, at which point you shouldn't see the prompt again because the TPM should be releasing it automatically again.  So if you're seeing it every time, it means the TPM is either disabled or it doesn't actually have the correct key.  For the former, make sure the TPM is enabled in the BIOS.  For the latter, you can either disable and re-enable BitLocker, which will cause it to store a new key in the TPM -- but will also generate a new Recovery Key, which you will need to back up -- or you can just delete and re-add the TPM protector to your existing BitLocker environment in order to get BitLocker to send a new key to the TPM by doing this:

1. Open an elevated Command Prompt.

2. Enter "manage-bde -protectors -get c:"

3. Copy the ID of the TPM protector to the clipboard, including the curly brackets/braces.

4. Enter "manage-bde -protectors -delete c: -id {YourTPMID}" -- include those curly brackets/braces.

5. Enter "manage-bde -protectors -add TPM"

@jphughan sorry I'm pretty bad with TPM so sorry for the question if it's silly. Am I right that after running commands you shared:

1. Open an elevated Command Prompt.
2. Enter "manage-bde -protectors -get c:"
3. Copy the ID of the TPM protector to the clipboard, including the curly brackets/braces.
4. Enter "manage-bde -protectors -delete c: -id {YourTPMID}" -- include those curly brackets/braces.
5. Enter "manage-bde -protectors -add TPM"

I will be able to boot my devices without bitlocker prompt in both cases when it's connected to the egpu and when it's not connected?

And I have C: and drives. Should I run that command twice for both drives?

@gdreyv  ok, didn't realize there was another thread.  But reading over the original post here from @Viking42, the reported behavior is that the Recovery Key prompt appears when connecting or disconnecting the eGPU, not on every single reboot.  That is an important distinction, and that is the key (no pun intended).  Thunderbolt allows access to a system's PCIe bus, and a change to the composition of PCIe devices present in the system is considered a change from the TPM's known and trusted hardware/firmware state, and therefore would cause its "platform integrity check to fail".  So if you enable BitLocker while the eGPU is connected and then disconnect it, you'll see a Recovery Key prompt.  If you enter the correct Recovery Key, the TPM will reseal against this new hardware profile that doesn't have an eGPU -- but that means it will fail again when you connect the eGPU again, so once again you'll see a Recovery Key prompt.

This is why systems default to having the two BIOS options related to Thunderbolt boot support disabled.  In that case, Thunderbolt devices aren't even available at boot when the platform integrity check is performed, in which case changes to Thunderbolt device connections wouldn't be a problem.  But if you need those options enabled for the eGPU to work properly (are you sure about that?), then you'll see this issue.

There isn't a way to have the TPM trust multiple separate hardware profiles simultaneously.  There is a way to use Group Policy to tell BitLocker what sorts of changes should be checked as part of the TPM's platform integrity check, so in theory you could exclude the item that the eGPU changes, but I haven't delved into that -- and that would technically reduce your security by potentially allowing other hardware changes that might actually compromise security to be ignored.

Or you could use BitLocker without the TPM at all by enabling password-based security.  In that case, you don't have a platform integrity check at all.  Of course that's even less secure than a reduced integrity check, but it's fairly straightforward to implement.

So one thing you can try if your system allows would be to disable Kernel DMA Protection and instead set your Thunderbolt security mode to SL1 "User Authorization", which is the default for older systems that don't support Kernel DMA Protection at all.

@jphughan  How can I do this? Is it somewhere in bios?

I found an article on Dell's knowledge base but my BIOS (v.1.3.1) doesn't have such option. Was it moved somewhere?

@Viking42  (and maybe @gdreyv  this might help you), I just read your original post here more closely and saw that you'd already disabled the Thunderbolt boot options on your new XPS and that this worked fine on your older XPS.  In that case I believe the key difference is that newer XPS models support a newer Thunderbolt security mode called Kernel DMA Protection.  That has a fair amount of benefits that are useful in many use cases, but it does mean that Thunderbolt peripherals that support it are available at boot, I believe regardless of the BIOS settings you mentioned, which I believe only apply to devices that do NOT support Kernel DMA Protection if you have that security mode enabled.  So one thing you can try if your system allows would be to disable Kernel DMA Protection and instead set your Thunderbolt security mode to SL1 "User Authorization", which is the default for older systems that don't support Kernel DMA Protection at all.  At that point if you keep the Thunderbolt boot support options disabled, you should be ok because at that point your new system would behave like your old one.

If you want the gory details about Thunderbolt security levels, how it all works, why it matters, and why various options operate they way they do, I wrote an explainer post here a while ago.

@gdreyv  It would be in the BIOS, yes.  I don't have your specific system, so I don't know for certain that it offers this option, but if it does, that's where you'd find it.

I have XPS 13 7390 2-in-1 and it looks like it doesn't have such option... no ideas why.

So keep investigating I found that it's possible to change what exactly Bitlocker checks before showing key prompt. It's called Platform Configuration Registers (PCR). And on Windows I can disable PCR which are changed when eGPU is connected.

But there is one problem. To find out what PCR was changed I need to parse Measured Boot logs. But the tool which parses that logs is available only for Windows Server 2012. So now we need to find out how to decode logs without that tool as Dell support doesn't have windows 2012

@gdreyv  Maybe Dell isn't offering that option on systems that support Kernel DMA Protection, although that's strange since Kernel DMA Protection can only be used with Thunderbolt devices that support it (and when you're running a new enough version of Windows 10 to use it), so the system would have to have some sort of "legacy fallback" mode defined for how to operate when those conditions aren't met.  But in that case you could either try using Group Policy Editor to customize the platform integrity check parameters so that the check doesn't fail based on the presence or absence of the eGPU, or just enable password-based BitLocker, which cuts out the TPM entirely and therefore doesn't use a platform integrity check.  Either of those will technically reduce the overall security of the system since you would now have no "alert mechanism" if there was an actual hardware/firmware change that might be related to an attempt to compromise your decryption key, but if you're ok with that in exchange for this convenience, then those options are available.

@gdreyv  To exclude a failure caused by a change to the presence of a device on the PCIe bus (which is what Thunderbolt "exports"), try excluding either PCR 0 or 2.  The others don't really make sense for that scenario.

Yes, I'm trying to update Group Policy within Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives in "Configure TPM platform validation profile for BIOS-based firmware configurations". It requires set of PRCs which should be used. But I don't know which of them to exclude as I can't decrypt Measured Boot log which contains info about which PCR failed on boot with eGPU connected. If I got it right default PCRs are:

• Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0)
• Option ROM Code (PCR 2)
• Master Boot Record (MBR) Code (PCR 4)
• NTFS Boot Sector (PCR 8 )
• NTFS Boot Block (PCR 9)
• Boot Manager (PCR 10)
• BitLocker Access Control (PCR 11)

and one of them (I hope just one) should be disabled.

I disabled 0 and 2 and nothing changed. Of course disabling 11 makes it work but it means just disable everything. Still looking for a way to decode measured boot log on windows 10...

Seems like the easiest solution is to return my New XPS 13 laptop to dell