Title in the subject line pretty much says it.
I've got a Dell Precision 5510 and a TB16 dock.
It is currently running Windows 10 1703 but this issue existed under Windows 10 1607 as well.
Sequence of events/how to replicate:
One you go back to connecting to the TB16 though... you guessed it, you need to re-enter the recovery key again.
I see two ways to look at this:
Question 2 is probably best answered elsewhere but has anybody else encountered this situation or can anybody from Dell suggest answers to Question 1? Is there anything I can do differently with Precision 5510 and TB16?
I've recently updated to Windows 10 1709 and this issue still exists.
This is just one of the ways that the TB16 dock has caused headaches and disrupted my working day. Not Happy!
I don't work for Dell but the only two reasons I might think the Dock would be involved is if you have a drive on the dock it needed to access or the Ethernet network connection. You might try disconnecting the Ethernet from the Dock and verifying whether you are on a Public or Private network.
I don't use BitLocker but my system likes to encrypt my OS partition when I reset my install or do a clean install. My BCD store contains the entry below, in the bootmgr section, which my other systems do not.
Is there more than one key for your system on the website? It may point you to a OneDrive.live site.
And lastly, I would try setting up BitLocker without being connected to the Dock.
XPS 2720, Inspiron 17 7779, Inspiron 15 7567, XPS 13 9365, Inspiron 1545, TB16 Dock
Sorry to hear of your issues. Please try updating the BIOS, there are a couple of Bitlocker recovery fixes included:
Let us know how you get on.
Social Media Support
I'm based in the UK and I'm usually available Monday to Friday 10am-5pm GMT (BST)
Get Support on Twitter @DellCaresPro
You have to disable Thunderbolt boot support in the BIOS. This behavior has nothing to do with Windows and only partly to do with BitLocker; it's mostly the TPM. It's occurring because when BitLocker uses a TPM, it stores the key as a special type of key that requires a "platform integrity check" to be released. Basically, before the TPM releases the decryption key at boot, it checks the hardware environment to ensure that nothing has changed that might compromise the security of the hardware platform. Thunderbolt operates over PCIe, and changes in the PCIe devices connected to the system can change the overall security of the system. This means that when Thunderbolt boot support is enabled, every time the connected/disconnected state of the dock changes compared to the hardware profile that the TPM has been told to trust, it refuses to release the decryption key and prompts for the Recovery Key instead. When the Recovery Key is entered, the TPM “re-seals” to the current hardware profile, but then it no longer trusts the previous profile. This is all why Thunderbolt boot support is DISABLED by default in the BIOS.
Note that if you make this change while your TPM trusts the "dock connected" hardware profile, you will see the Recovery Key prompt one more time, after which you'll be fine since the dock will always appear disconnected at boot time from that point on, even when it actually is connected.
Incidentally, you may have noticed that updating your BIOS triggers a Recovery Key prompt, and that occurs for the same reason. A change in BIOS revision is a potential security-affecting change, because the system might have been downgraded or even upgraded to a specific release that contains a known security exploit.
Just as a follow-up to the above suggested solution, if disabling boot support isn’t acceptable, then you would have to use password-based BitLocker rather than TPM-based. That’s disabled by default because it lacks the platform integrity check functionality I described above (and you also can’t perform an unattended remote reboot anymore), but it can be enabled in Group Policy Editor. It’s also only intended for systems that lack a TPM, so you might have to actually disable the TPM in the BIOS to block BitLocker from using it (haven’t tried this scenario myself), but that would avoid the behavior you’re seeing, at the cost of reduced security and convenience.
You can use Group Policy to adjust the which PCR values are checked in the platform validation profile.
Found under Computer Configuration/Administrative Templates/Windows Components/BitLocker Drive Encryption/Operating System Drives > Configure TPM platform validation profile (there can some variations of this name to cover different Windows versions, UEFI, etc. depending on what level of OS you are using).
You can set to just check PCR 11 as the base. If you've got the time, you can enable others (some of the GP notes will tell you the defaults) to see what gives you enhanced protection while not triggering the need to the recovery key unnecessarily.
And yes, I have done this because I was encountering a similar situation with Latitude 7480 laptops and TB16 docks. This allows you to continue to use the TPM as one of the authentication factors for BitLocker.
I knew about that, but I specifically didn't suggest it because weakening the platform integrity check significantly reduces security. Typically Thunderbolt Boot Support is enabled just to get a laptop imaged when it lacks a built-in NIC (an increasingly common problem for enterprises these days), but after that's done, how often do you need to boot from a device connected via the Thunderbolt dock? That's why I suggested simply disabling that option after imaging, thereby maintaining the security of the platform integrity check.