none
MDT 2013 with SCCM 2012 R2 CU4 - BitLocker to store the key in AD RRS feed

  • Question

  • Hi everyone,

    I am running into an issue while trying to deploy a machine that I want to automatically encrypt with BitLocker and have MDT store the key in AD. Could someone please tell me what values I need to set and how to get this to work? I have my AD prepared to store keys inside and if I do that manually on a machine, all works fine and keys venture to their respective objects in AD. Currently I have something like this in my CustomSettings.ini:


    OSDBitlockerMode=TPMKey
    BDEInstallSuppress=NO
    BDEWaitForEncryption=False
    BDEDriveLetter=S:
    BDEDriveSize=512
    BDEInstall=TPMKey
    BDERecoveryKey=AD
    BDEKeyLocation=C:\Windows\BDEKey

    This setup only enabled protection on my C drive, but the drive does not get encrypted nor the key is not in AD. When I try to click Manage BitLocker it errors out with message - no keys to manage.

    Anyone has any idea how this should be set?

    Thanks!

    Jakub

    Thursday, July 9, 2015 7:49 AM

Answers

  • This is silly, but whatever I did with MDT task sequence variables, it would not work. The only thing I had to do is replace the Enable BitLocker sequence that runs cscript.exe "%deployroot%\scripts\ZTIBde.wsf" /UDI
    with SCCM native BitLocker sequence:

    After this, the BitLocker turns on fine and key gets stored in AD.

    Thanks for looking into it!

    Jakub

    
    • Marked as answer by Jakub Fuczek Saturday, July 11, 2015 6:44 AM
    Saturday, July 11, 2015 6:44 AM

All replies

  • This is what I use and it's been working fine:

    SkipBitLocker=YES
    OSDBitLockerMode=TPM
    OSBBitLockerCreateRecoveryPassword=AD
    OSDBitLockerWaitForEncryption=FALSE
    BDEInstall=TPM
    BDEInstallSuppress=NO
    BDEWaitForEncryption=False
    BDERecoveryKey=AD
    BDEKeyLocation=\\SERVER\Share$\BLKeys

    Of course make sure you also have your domain information set in custom settings and that the machine joins the domain (Recover from Domain) before BitLocker activates (Enable BitLocker). I would strongly caution against storing your recovery key on the drive that's encrypted. Should you not be able to get the key from AD you won't be able to access the recovery key if it is also encrypted.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, July 9, 2015 2:15 PM
  • Thanks for responding. These do not work for me I'm afraid...I'm starting to think it may be related to our AD configuration...however, when I log on as local administrator right after the laptop got built and run this command:
    manage-bde –on C: -recoverypassword

    everything works perfectly fine. computer requires a reboot and starts encrypting right after I do so. The key also goes to AD without an issue. I am wondering however if maybe it has something to do with Enable Bitlocker phase being run in TS as local computer account? Could that be an issue?

    Jakub

    Friday, July 10, 2015 9:55 AM
  • The only AD account that does anything when I deploy is the one that joins the computer to the domain. I have BitLocker pre provision on my Windows 8 deployments, but even with my Windows 7 deployments I don't have issues with the key being stored in AD and Bitlocker is run by the local administrator account.

    Do you see any errors at the end of the deployment? If so, can you post your BDD.log maybe there's something in there that might point to the issue.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, July 10, 2015 1:03 PM
  • This is silly, but whatever I did with MDT task sequence variables, it would not work. The only thing I had to do is replace the Enable BitLocker sequence that runs cscript.exe "%deployroot%\scripts\ZTIBde.wsf" /UDI
    with SCCM native BitLocker sequence:

    After this, the BitLocker turns on fine and key gets stored in AD.

    Thanks for looking into it!

    Jakub

    
    • Marked as answer by Jakub Fuczek Saturday, July 11, 2015 6:44 AM
    Saturday, July 11, 2015 6:44 AM