ConfigMgr 2012 SP1 with MDT 2012 Update 1, UDI Task Sequence and Bitlocker Error 6767

Redmond, we have a problem.  The “Client Task Sequence” template when used with Configuration Manager 2012 SP1 does not work too well when UDI is enabled and we want to Bitlocker our devices.

When we are performing a User Driven Installation, the MDT 2012 Update 1 template makes use of the ConfigMgr “Pre-provision Bitlocker” step, which adequately pre-provisions Bitlocker on the Operating System drive on a ‘used space only’ basis.  This is a good thing.   Later on in the Task Sequence we have an MDT specific step that uses the ZTIBde.wsf script which SHOULD configure and enable the protectors – but you may find that this will fail, resulting in an exitcode of 6767.  Tracing this error in the ZTIBde.wsf script takes us into a failure of the function that enables the Bitlocker protectors.  So what is going wrong?

Let us first understand that the ZTIBde.wsf was designed for MDT deployments primarily – with added ConfigMgr integration as an afterthought.  The ZTIBde.wsf script ON ITS OWN is capable of pre-provisioning Bitlocker in Windows PE AND ALSO, later (in the OS phase) configuring and enabling the protectors.  It’s a great little script.  In the MDT Client Task Sequence template however, the ZTIBde.wsf script is not used within the Windows PE phase to Pre-provision Bitlocker and instead the in-built ConfigMgr function is used.  The ConfigMgr function will pre-provision Bitlocker, however it does not then configure the appropriate variable that the ZTIBde.wsf Pre-provisioning function would and this is needed and consumed later by the ZTIBde.wsf script when it comes to Enabling the Bitlocker Protectors in the OS Phase.

The ZTIBde.wsf script has a section which checks if Bitlocker is enabled on the drive (IsBDE = TRUE) and also if the drive has NOT been pre-provisioned earlier (IsBDEPreProvisioned <> TRUE).  This test is used to accommodate the refresh scenario when the existing suspended protectors of a Bitlocker drive can simply be turned back on without having to configure any.  In the absence of the IsBDEPreProvisioned variable (or if it doesn’t equal TRUE) then this section of code will cause the script to skip over the configuration of any required protectors (specified in the UDI wizard) and simply try to enable any existing protectors, of which there are none – resulting in the error 6767 spat out by the EnableProtectors function.

So what do we need to do about this?  Well you could amend the script – but that wouldn’t be supported by Microsoft and your modifications could well be wiped out by any future revision (which may or may not address its shortcomings.  There are a few (non-exhaustive) alternatives that I could propose;

  1. If you are using the UDI Wizard AND you want the Bitlocker options to come through from it, then you should replace the “Pre-provision Bitlocker” step in the task sequence that uses the ConfigMgr function with the ZTIBde.wsf script – the very same script used later on to “Enable Bitlocker”.  This keeps the Pre-provisioning process and the Enable Bitlocker process solely in the MDT camp.  However, if you want the Recovery Key to be backed up to Active Directory then you will need to use a script afterwards to do that, or implement MBAM.
  2. If you are using the UDI Wizard AND are removing the Bitlocker configuration page but still want Bitlocker enabling then replace the “Enable Bitlocker” step in the task sequence with the ConfigMgr function – as you can specify the protectors used and also escrow the Recovery Key to Active Directory automatically.
  3. If you are NOT using the UDI Wizard but want to implement Bitlocker in your Task Sequence, then stick with the ConfigMgr step for pre-provisioning Bitlocker and replace the ZTIBde.wsf method for Enabling Bitlocker with the ConfigMgr function – for the same reasons as above.  In this scenario, you would need to ensure that your partitioning layout is suitable for Bitlocker.

Have fun with that!



ZTIMoveStateStore.wsf does not move the StateStore folder during Refresh

When ConfigMgr 2012 is integrated with MDT 2012, the Client Task Sequence template includes a step that uses ZTIMoveStateStore.wsf to move the StateStore folder to WINDOWS\TEMP in the event of success or failure, however this script has not been updated to cater for the new location of the StateStore and when it runs it will simply not find the StateStore in the expected location and exit without any error.  This isn’t too much of a problem until you attempt a second refresh of a system -which will result in the Task Sequence failing to store the user state.

To rectify this, create a backup copy of the ZTIMoveStateStore.wsf script within the MDT Toolkit Files package and then open the original for editing.  You will be looking for any references to “oUtility.LocalRootPath” and replace these with “oUtility.StatePath” and remove the additional path.  There are 6 (SIX) lines to which this amendment needs to be made;

– 1 –

If oFSO.FolderExists(oUtility.LocalRootPath & "\StateStore") Then


If oFSO.FolderExists(oUtility.StatePath) Then

– 2 –

oLogging.CreateEntry "Moving " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore", LogTypeInfo


oLogging.CreateEntry "Moving " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore", LogTypeInfo

– 3 –

oFSO.MoveFolder oUtility.LocalRootPath & "\StateStore", sArchiveDir & "\StateStore"


oFSO.MoveFolder oUtility.StatePath, sArchiveDir & "\StateStore"

– 4 –

oLogging.CreateEntry "Error moving " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


oLogging.CreateEntry "Error moving " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning

– 5 –

OFSO.CopyFolder oUtility.LocalRootPath & "\StateStore", sArchiveDir & "\StateStore"


OFSO.CopyFolder oUtility.StatePath, sArchiveDir & "\StateStore"

– 6 –

oLogging.CreateEntry "Error Copying " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


oLogging.CreateEntry "Error Copying " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


This has worked great for me.

MDT 2012 Update 1: Missing “Request State Store” step causes state restore to fail from State Migration Point in REPLACE Scenario.

I have found that the MDT 2012 Update 1 Client Task Sequence Template is now missing a crucial step in the later stages of the task sequence which is needed to restore captured data from the ConfigMgr State Migration Point when working under the REPLACE scenario – and we need to add this back in.

You simply need to add a “Request State Store” step just above the new “Connect to State Store” step (which looks to just do an authentication against UNC path) and add a condition on the step to run only if Task Sequence Variable “USMTLOCAL” not equals TRUE.

Also add a “Release State Store” step below the “Restore User State” task, again with the same condition as above.


ConfigMgr 2012 RC2 / MDT 2012 Issues

I’m now just starting to be able to commit some more time to taking a good peek under the hood of Configuration Manager 2012 Release Candidate and as I come across interesting features or, er, not so interesting “features” then I’ll throw them quickly into this blog post.

  • Capture Media not working – TSMBAutoRun.exe does not seem to do anything for me.  I have tried regenerating the capture media iso but so far nothing seems to happen when I try to capture a running OS.  If I use capture media from my old ConfigMgr 2007 environment the wizard launches fine.  Performing a Capture using an automated Build and Capture Task Sequence still seems to be OK, but I prefer to inspect, patch, tweak, clear logs, remove temp files and otherwise manually refine my reference OS before I capture it.
  • Bitlocker Partitioning – Partitioning has always been a sore point for migrations and it is interesting to see that Microsoft now have a partitioning step for the New Computer scenario that creates a partitioning structure suitable for Bitlocker.  I have implemented this method myself in the past, however recently I changed to creating only a single partition initially and then utilising the ZTIBde.wsf script to do the Bitlocker drive configuration later in the task sequence – which leaves the OS partition as the first partition on the disk and makes life easier when refreshing.  In the new MDT 2012 Client Task Sequence Template a 512MB BDEDrive partition is created at the start of the disk and the remainder of the drive is partitioned and assigned the OSDisk variable.  The subsequent Apply Operating System Image step is configured to apply to the OSDisk variable, which is fine, however, from experience I know that there can then be problems when attempting to perform a Refresh due to the lack of the OSDisk variable as there is no partitioning step.  I’m just starting to look at this to see if Microsoft have improved or implemented something I can’t see which is clever enough to figure out the correct drive to apply the OS Image to during refresh – otherwise we have to use a custom script just after rebooting into WindowsPE to detect on which drive letter the existing OS is living on and then set the OSDisk variable accordingly for the Apply Operating System Image step to use.  ** Update – Microsoft seem to have taken care of this with a revised ZTIUtility.vbs that now has a function for determining the correct partition to apply the Operating System image to and setting the OSDisk variable accordingly. ** – This is a very welcome addition.
  • USMT Hardlinking option with MDT 2012 Task Sequence – It is good to see that you can now check options in the Capture User State Task Sequence step UI to enable local state captures to use hardlinks, however this option should not be ticked when using an MDT 2012 Client Task Sequence as the “Determine Local or Remote User State” Task Sequence step employs the ztiuserstate.wsf which will, where possible, append the /hardlink and /nocompress options to the Scanstate.exe command line automatically.  If the option is ticked, the options will be duplicated on the resulting command line and the Capture User State step will fail.
  • Driver Importing – I don’t seem to be able to have the option to import drivers into sub-folders within the Drivers node – thus everything so far has to be imported at the root level and then moved afterwards.
  • BGInfo Backgrounds – The MDT 2012 Toolkit files package does not contain the WindowHide.exe and the ZTISetBackground.wsf script no longer hides the FirstUXWnd – this means that once you are out of the initial Windows PE phase you can no longer see your custom BGInfo backgrounds/custom wallpaper.  I have yet to try re-including this functionality.  MDT 2012 Release Candidate now includes the WindowHide.exe – yaay!

More to come…