Windows 10 - Bitlocker - D: drive only locking and requesting Recovery Key on large number of machines RRS feed

  • Question

  • Hi

    Hoping for some advice on an issue with Bitlocker on Windows 10 (both LTSB and CB).

    BACKGROUND (brief):

    -- Windows 10 deployed via SCCM 2012 SP2 CU3 (LTSB)

    -- Local disks are SSD, machines are configured as UEFI

    -- Two primary partitions configured, C: for OS and D: for data, folder redirect, etc (not including UEFI partitions)

    -- Bitlocker configured via task sequence on Operating System Drive as TPM and PIN

    -- Bitlocker configured via task sequence for D: drive (not much else you can do here)

    -- TPM specification version on all client machines is 1.2

    -- Recovery key is stored in McAfee ePO via McAfee Management of Native Encryption agent


    We are deploying Windows 10 client machines - same laptop model, same SSD disk, same memory, same task sequence build - to a small-ish number of users as part of a pre-pilot, early adopter process. Thus far we have deployed around 100 of these Windows 10 machines.

    However, we are seeing regular instances of the D: drive locking and requesting the Recovery Key usually after an unexpected shutdown. By unexpected shutdown, I mean impatient users holding the power down until the machine turns off (they've been told not to do this obviously) and also sometimes when a software update is installed and causes a restart, or when there is an occassional blue screen, the one with the :( icon.  Really, any unexpected restart can trigger this lockout of the D: drive.

    I must make clear that so far no instances of the C: drive - the OS drive - locking out have been reported, it is only the D: drives. This is happening on something like a 1 in 3 basis, so it's a problem, especially as we redirect user profiles to the D: drive, and have the SCCM client cache stored on the D: drive.

    Now, we are using Bitlocker for the first time in our environment, replacing another vendor's encryption software, so I am new to Bitlocker - please be patient.

    This is my understanding of the very high level process - please correct me where I am wrong:

    1) User powers on laptop

    2) Bitlocker Pre-Boot Authentication screen appear

    3) User enters Bitlocker PIN - this unlocks the C: drive only (still encrypted just unlocked)

    4) Windows 10 boots and starts to load (assuming TPM did not detect any BCD, etc changes)

    5) The D: drive is set to automatically unlock.  This requires the OS drive to be Bitlocker encrypted, which it is. The Bitlocker keys to unlock the D: drive are stored in the C: drive. So at some point after C: is unlocked and Windows starts to load - and this is where I am really unsure - Bitlocker will access the keys for D: (which are stored on C: and now accessible) and use them to auto-unlock the D: drive

    6) User logs on and both C: and D: are in an encrypted and unlocked state, as desired

    7) Once the McAfee Management of Native Encryption agent is running, Bitlocker keys for C: and D: are stored in McAfee ePO for recovery purposes


    That's my very high level idea of the process.

    Looking into it I read this:

    This was interesting - there's a long list of issues which can cause locking and the request for the Recovery Key - but I couldn't see anything which matched what is happening in our environment. Our users do not have local administrator access so they are limited in terms of what they can do i.e. they can't configure Bitlocker, TPM, update firmware, etc.

    The fact that it is only ever the D: drive which gets locked is also interesting, and I suspect meaningful.

    On any machine which has experienced this problem, we have usually been able to confirm an unexpected restart, so that is presumably the root of the problem.

    Can anything be done to remedy this?

    Can a delay be configured on the D: drive unlock process to make sure it waits until C: is loaded and in an accessible state?

    Or can D: drive unlock retries be configured?

    Or is there something wrong with our configuration? I doubt this, as - as stated above - only around 1 in 3 are affected.

    My gut feel is that the unexpected restarts are somehow stopping Bitlocker from getting the keys from C: to unlock D: - is there a way to confirm this?

    Apologies if the above makes no sense. Hoping someone can steer me in the right direction.



    Sunday, October 2, 2016 2:29 PM

All replies

  • Hi John.

    Two things: 1st: your list 1-7 is correct, completely correct.

    2nd: BL autounlock is buggy sometimes. I have seen weird things like it onlky unlocks for one user while it is locked for the other user of the same machine for NO APPARENT REASON, no crash, nothing.

    Although bitlocker is very mature, it is not free of bugs. To overcome your issue, I am afraid you will have to do some experiments and deliberately crash or reset your pc multiple times. Maybe this will at least ensure your theory of "when it happens" is correct.

    "Can a delay be configured on the D: drive unlock process to make sure it waits until C: is loaded and in an accessible state?" - no. What you could do (but that is just a workaround), is do your own way of auto-unlock using a scheduled task that gets triggered on any user logon and unlocks d: using the recovery password as in:

    manage-bde -unlock d: -rp 354354-464367-...

    Tuesday, October 4, 2016 6:56 AM
  • Hi Ronald

    Thank you for taking the time to reply.

    It is, I'm sure you will agree, disappointing that Bitlocker is still 'buggy' even though it is as you say a mature product.

    Even worse, I am feeling a bit foolish, because we currently have a third party disk encryption product in place (it causes no end of problems) which we will replace with Bitlocker, and we have been telling our users that problems associated with disk encryption will be greatly reduced when we move to Bitlocker - only for this issue to start causing problems for our pilot users! That's Microsoft for you.

    The workaround you mention I have read about before, from memory it was from a chap who had a similar problem, though not with a second partition, but with a second disk.

    I don't think we can consider this, as we will soon be deploying W10 machines in the hundreds.

    We have a support call opened with Microsoft, but often I have found that responses on technet are more helpful than the official response from Microsoft PSS, which is why I posted the question.

    Thank you again for responding,


    Tuesday, October 4, 2016 8:08 AM
  • Having a call open with MS is (my own experience) like sending oneself to the nuthouse. It will take a week until they understand what you want, another week to look at tons of logfiles, another to start working on it and after 4  weeks they give up telling you all sorts of sorry excuses why it wouldn't work this time.

    "I don't think we can consider this, as we will soon be deploying W10 machines in the hundreds." - you should reconsider. The workaround can be automated and is in fact just the same thing they already do, read a key at startup. But this time, you control it, and it works. We can deploy tasks, we can automatically create keyfiles. That's all you need. So consider using key files (.bek)

    Creation: startup script going

    manage-bde -protectors -add d: -sk c:\windows\admin\BL\

    Make sure to setup a GPO that makes that directory unreadable for users.

    Then, deploy a task, triggered at logon of any user. Executing account: system. Action:

    for /f "tokens=4" %a in ('dir c:\windows\admin\bl /a:h') do manage-bde -unlock d: -sk c:\windows\admin\bl\%a

    And that's it.

    Edit: I changed the code.
    Tuesday, October 4, 2016 8:28 AM
  • Hi Ronald

    Thanks for taking the time to detail that.

    Unfortunately, as a finance related firm, our security team will not allow us to use that workaround.

    I do appreciate you posting it though, it may well help others.

    I will continue to pursue Microsoft PSS for a solution to this, we have an account manager we can involve, might make zero difference but I'll keep at it.

    If I get any information I think is worth sharing, I'll post.

    Bets regards


    Wednesday, October 5, 2016 9:06 AM
  • "as a finance related firm, our security team will not allow us to use that workaround"

    We work in the defence sector and I (as system admin) would have no worries to deploy it. I have more control over it this way, not less.

    Wednesday, October 5, 2016 9:36 AM
  • Just for the record, it's been over three weeks since I last heard from Microsoft PSS regarding the ticket I logged about the above Bitlocker issue.

    What a joke (a bad one)!!

    Wednesday, October 26, 2016 10:20 AM
  • This is no joke, this is for real.

    MS closed tickets they had with me and I said, "hey, that's no solution, you haven't even understood the problem, it seems" - but they insisted they had and left them closed. That is how they act with paying customers.

    Wednesday, October 26, 2016 11:46 AM
  • Well it's around a week away from TWO MONTHS since I logged this call with Microsoft PSS.

    They STILL haven't been of any help with this Bitlocker issue.

    Microsoft PSS are becoming as bad as McAfee support.


    Tuesday, November 15, 2016 3:45 PM
  • I have a couple of questions for you that may or may not help uncover a problem.

    1) how do the laptops in the pilot group connect to your network? VPN or direct access?

    2) have you ran a test group of storing the recovery key in active directory rather than the 3rd party application?

    I suspect the problem will lay with the 3rd party app agent not starting correctly and thus not being able to supply the recovery key thus leaving the drive locked. (I'm open to being wrong with that though as I have not utilised a 3rd party app to handle the unlock stage)

    Tuesday, November 15, 2016 5:09 PM
  • Thanks for replying Andy

    1) When in the office they connect via LAN cables, when from home they connect via VPN

    2) We don't have MBAM yet, so we're not using AD.

    I'm not sure about your theory: I don't believe the 3rd party app is involved in the Bitlocker auto-unlock process for the data drive, given the key for the data drive is stored on the C drive and is accessed by Bitlocker, not the 3rd party agent.

    My understanding is what the 3rd party agent does is backup and store the recovery keys should they be required - but it is not involved in the auto-unlock process.



    Wednesday, November 16, 2016 9:54 AM
  • Hi John,

    looking into this a little more it looks like this is actually a usual 'feature' of unexpected loss of power. (i.e. turned off rather than shut down).

    there is a whole list of other possible causes, not sure if you have read the article so I'll post it here:

    also looking into it you are correct, the recovery key storage shouldn't impact the auto-unlock, that being said, it wouldn't be the first time that I've seen a 3rd party app do more than what it says on the tin, the auto-unlock feature uses registry settings and metadata for the unlock, if the 3rd party app is supplementing that information and/or is using the agent as a pointer or reference that may cause it too.

    sorry I can't be more help

    Wednesday, November 16, 2016 1:21 PM