Some way some how, a user's machine couldn't get read the bitlocker password off of the TPM chip, and I had to enter the recovery key (stored in AD) to get in. No big deal, but once in the machine, I tried to suspend bitlocker per recovery documentation, and got an error message about the TPM not being initialized. I knew the TPM was on and activated in the BIOS, but Windows still made me reinitialize the TPM chip, and in the process it created a new TPM owner password.

I found that odd because it prompted me to save this password or print it (there wasn't an option not to), but it made no reference of a recovery password, nor did it back this password up to AD.

After the user took her laptop and left I started thinking that if the TPM password change, does the recovery password change also? If so, that new recovery password will need to be uploaded to AD, but MS' documentation doesn't make that clear, and doesn't back up the new recovery key (if one exists) to AD automatically when the group policy says it must, and from a network standpoint AD is accessible.


When BitLocker encrypts a drive it keeps the master encryption key on the drive itself, though not in plain text. The master password is kept itself encrypted by "Protectors". Each of these keeps a separate copy of the master key as only the protector that encrypted it can decrypt that copy of the master key.

When you have Windows encrypt a volume through the GUI it typically creates two protectors: a Recovery Password (RP) and a TPM key. As noted above, these are stored completely separately. If you have the GPO configured each time a RP is create it is stored in AD. This is completely automatic and if you have the GPO configured a RP cannot be saved to disk without uploading to AD (ie, no offline RP creation as AD wouldn't be available).

I strongly suggest ditching the GUI. It glosses over the function of BitLocker too much for a system administrator, and the actual operation of BitLocker really isn't that complicated. The CLI utility manage-bde comes with every version of Windows that supports BitLocker. It's pretty straight forward, though the syntax is a bit verbose.

To see what the laptop's drive is doing right now simply run manage-bde -status C:. As for TPM issues, after unlocking the PC and booting Windows I always run manage-bde -protectors -get C:, copy the ID for the TPM protector (including brackets), then run manage-bde -protectors -delete C: -id {the_id_you_copied} and finally manage-bde -protectors -add C: -tpm. It's 30 seconds more work, but you know exactly what it's doing, and exactly where you stand afterward.

  • Perfect. I am familiar with manage-bde, but since we are still rolling out bitlocker in our environment, it's still pretty new here and I didn't think to use it. I've set it up so that on our new machines we enable the tpm and enable bitlocker during our imaging process (sccm), up until this point we've had few machines that needed be to manually unlocked.
    – MDMoore313
    Nov 8 '13 at 15:09
  • This is all coming back to me now: a protector is stored on the TPM key to decrypt the master password that's stored on the (I'm guessing) bootloader, and if that's not accessible then the recovery key has to be entered to decrypt the master key, but the master key itself isn't stored on the TPM chip. Is that the jist of it?
    – MDMoore313
    Nov 8 '13 at 15:10
  • 1
    Yep, that's it. It's pretty rare that I have to unlock a machine (mostly just the dev's messing with settings they shouldn't be). I get calls semi-frequently when people leave bootable USB sticks in their machines though, TPM gets touchy about new bootable media like that (and once TPM is pissed you have to power off completely or it'll stay pissed).
    – Chris S
    Nov 8 '13 at 15:13
  • Yeah, she was a tinkerer, but we've started using BIOS passwords to prevent that sort of 'reset to default' thing happening (might not have been the case here but still), which would wreak havoc on our environment.
    – MDMoore313
    Nov 8 '13 at 15:16
  • 1
    We use HP laptops and update the BIOS (if necessary) and flash a "standard" configuration (including company logo and password) to it when the laptop gets imaged using the HPQflash utility (in the BIOS packages you get from them) and bcu (BIOS Configuration Utility). I'd be surprised if Dell didn't have something similar.
    – Chris S
    Nov 8 '13 at 15:21

I know this is old, got here looking for something else, but in my experience the automatic upload to AD after a change like that isn't always successful. I've been bitten at work several times because of this. After the 2nd time getting bit, I decided to script the upload process to ensure it happens instead of depending upon the automagic upload process that is supposed to happen. Here is what I wrote (BitLocker_UploadToAD.cmd):

@Echo Off
for /F "tokens=*" %%a in ('c:\windows\system32\manage-bde -protectors -get c: -type recoverypassword ^| findstr "ID: " ') DO SET ID=%%a
set ID=-%ID::=%
c:\windows\system32\manage-bde -protectors -adbackup c: %ID%
  • Reset, upload it, then pull it back down to make sure it was changed. Sounds good, +1. Oh, wait: you don't pull it back down? No powershell? You could probably implement the full cycle with powershell.
    – MDMoore313
    Feb 10 '17 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.