Detecting and Disabling BitLocker During OSD Task SequenceWritten by Andy
There are quite a few blog posts and articles that provide guidance on how to enable BitLocker during an OSD Task Sequence, however most (if not all) of them omit critical information as to how to correctly handle the detection and disabling of BitLocker during the REFRESH scenario. So here goes…
Out of the box, the standard Client Task Sequence MDT Template has a disabled step for ‘Enable BitLocker’ and as long as you have either manually or scripted the enable and activation of the TPM chip and completed the Active Directory work required this will do the job of encrypting your OS drive. You probably already got this far, which is no doubt why you are reading this article.
You then arrive at testing your Task Sequence in the REFRESH scenario (initiating the Task Sequence from within the running OS) and find that if BitLocker is enabled then your standard Task Sequence fails – as it cannot stage the boot image to your OS drive. You then add the ‘Disable BitLocker’ task to the Refresh section of your Task Sequence and this works nicely. However, your Task Sequence will now fail if you attempt to refresh a system that does not have BitLocker enabled to be disabled – a poor show by the ‘Disable BitLocker’ step really. You could enable the ‘Continue on error’ option on this step, however if the step genuinely fails to disable the BitLocker protectors then it will still proceed to attempt to stage the boot image, which is far from ideal.
The solution then, is that we need ‘something’ to first check to see if BitLocker is enabled and use this to govern whether the ‘Disable BitLocker’ step runs. I used to use a script I found out on the web but I had to amend it a little so that it worked on both x86 and x64 platforms, by using references to SYSNATIVE rather than the hardcoded paths to managebde.exe – as x86 and x64 require the correct version to be ran. It worked, eventually, after experimenting with the command line and disabling/enabling 64bit redirection – quite exactly what I did I don’t recall. Many months later, I needed to do the same again for another customer but I wasn’t happy implementing this again – there had to be something better?
Enter – UDI Preflight Checks! The MDT User Driven Installation (UDI) Client Task Sequence template includes the ‘Disable BitLocker’ step by default, but on the condition that a the variable ‘OSDBitLockerStatus’ equals ‘Protected’ – so how does it determine this? The UDI Task Sequence runs a series of pre-flight checks which, amongst other things, checks to see if BitLocker is enabled. The Script responsible for this is called ‘OSDBitLockerState.vbs’ and can be found in the ‘<MDT Toolkit Files Package>\Tools\<platform>\preflight’ folder which gets downloaded locally during build as part of the ‘Use Toolkit Package’ step. You just need to create a step which runs and passes the script the drive letter (ie: ‘C:’) of the partition to be checked and if BitLocker is enabled on that partition it will set the ‘OSDBitLockerStatus’ variable to ‘Protected’. I have a step in my Task Sequence before the ‘Disable BitLocker’ step which runs the following command;
cscript.exe "%TOOLROOT%\preflight\OSDBitLockerState.vbs" C:
The %TOOLROOT% variable resolves to the correct MDT Tools platform folder for the currently running OS – although the script does appear to be the same in both folders. You would then add a condition to your ‘Disable BitLocker’ step to check for this condition prior to restarting into Windows PE.
You now have a Standard Client Task Sequence that performs to the same specification as the UDI Task Sequence template with regard to Checking for and Disabling BitLocker, and we DO like standardisation!
Latest from Andy
- ConfigMgr 2012 SP1 with MDT 2012 Update 1, UDI Task Sequence and Bitlocker Error 6767
- ConfigMgr 101: Patience dear boy… SMS_SERVER_BOOTSTRAP
- ConfigMGr MPControl.log: Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden
- ATI Catalyst Drivers Installation
- ConfigMgr 2012: 64bit file system redirection bites again…