How to use a PreStage Wim (for serverless remote locations) using a single OSD-Task Sequence supporting Zero Touch, Bitlocker and Refresh Scenario for Windows 7 and 8.x

Admitted, that title is a handful, but I had to squeeze all the keywords in it.
This is going to be a huge post, with a lot of text and not that many screenshots (which would make it more attractive), and I may not do such a good job explaining it properly also, but bear with me anyway.
Before explaining the “what” and “how”, I’ll shortly go through the why.
There are three basic methods to do OS deployment:

  1. Network Installation
    There isn’t much to add to this one. You have your regular task sequence and most likely use a local DP to apply the image and all other content, unless you’re really friendly with your network guys and they don’t mind you pulling a few gigs over the WAN connection.
    This is mostly not going to work if there are locations without a server, using a likely already very busy WAN connection to the intranet.

  2. Full Media
    I don’t like that one very particular, although it has it purposes, the disadvantages outweigh the advantages in my opinion.
    The biggest advantage is, it basically does work without any network connectivity. If you really want no traffic at all, this is your choice, although Software Updates still create traffic anyway
    On the other hand the task sequence is hardcoded in the image, as all the other content from the task sequence is, and that content is backed in. Once those are handed out, change control is basically gone, unless you add custom code, still making it difficult to control them.
    Any change to the Task Sequence may require to replace some of the media handed out or even all and you may have a hard time to ensure they aren’t used anymore.
    Then there is the limit of how much content you can add, as all packages and applications have to be referred to directly in the task sequence. Once you hit that limit you’re screwed.

  3. PreStage Media
    Since CM12, that’s my favorite. You can add almost any content to the media and clients can use the content during the task sequence. But if there is a more current version available on a DP, that one will be downloaded and used instead. There is basically no limit on what can be added to the media, although common sense needs to apply. You could add your whole DP content to the media, but obviously that doesn’t make sense or would even work. Adding all drivers may make very much sense though.
    The task sequence isn’t backed in, so still full change control, as any change implemented later on is still executed by retrieving it from the DP/MP.

    This post is about using those PreStage media with way more automation and some really cool features added.

So, what does it do?

Let’s start with how PreStage media is usually used, which is a two-step process:

Applying the image

  • You have a task sequence to deploy the image, usually over the network, using “apply data image”
    (Defeating the purpose of reducing network traffic, which is what this post is about)

  • Or you apply the image locally on site IT using imagex or other methods
  • Or you provide the image to your hardware vendor and new delivered clients start directly with the next step.


  • The computer is started and a task sequence, usually a different one, is executed

While the Deployment part isn’t much different, applying the image is. I find the choices above rather cumbersome and it likely requires local IT guys to do it. You can’t do bitlocker (used disk space only) or a refresh. If you enable bitlocker later on, the computer would be very busy encrypting that already written content. Doing a refresh may get rather complicated or even impossible unless you apply the image through the network using the regular task sequence, again creating that network traffic we want to avoid. You may also need a local SMP or another local storage to get that working.

So again, what does it do?

Put very simple, this approach allows doing OS-Deployments using a single task sequence, automatically using the network (as today) or a local media (with the PreStaging wim) when provided, while supporting Bitlocker (incl. used disk space only) and client refresh with USMT hard-link or SMP support.

In other words:

  • Don’t provide a local WIM and it behaves as before.
  • Provide a WIM on any accessible local media and the wim file is used instead, taking care of all the required changes automatically
  • If you implemented bitlocker encryption, in particular used disk space only, all content written is already encrypted.
  • If you start a REFRESH and provide a WIM, the data is restored

It’s easier to explain by showing typical scenarios, assuming you implemented the changes of course.
It also assumes you implemented bitlocker and refresh support, at least if you want those benefits.

Starting a task sequence without preparing anything special, as today.

This will deploy an OS the same as before, meaning over the network doing whatever you implemented.
You start using PXE or a boot media and the task sequence starts.
If you support bitlocker and refresh scenarios, there isn’t (or shouldn’t J) be any difference. 

Starting a Task Sequence with PreStaging for bare metal install

You created a PreStage wim file, copied it on a media, USB-drive, external HD or a DVD (likely blu-ray due size) and did send those out to locations.
The media is plugged in, the computer started, either using PXE or a boot media, the same task sequence used before starts.
Once the task sequence finds the local wim file, instead of applying the image through the network, the local wim file is applied, some boot configuration is updated and the client reboots using “wpeutil reboot”, exiting the currently running task sequence.
Now WinPE starts from the just applied PreStage wim, looking for a task sequence (again, remember two phases, but automated), as it would if you applied the image through other methods.
The same task sequence is starting, executing the remaining steps. 

Starting a REFRESH installation from within the OS using PreStage media

This is about re-installing from within the OS, as I haven’t implemented Offline USMT hardlink migration (yet).
The task sequence is started, either backing up the user data you defined using hard-links or a SMP, whatever you implemented, the client reboots into WinPE and if it finds a local PreStage wim, wipes the volume, except the task sequence and StateRestore folder, applies the image, updates boot configuration and restarts.
The WinPE of the Prestage wim starts up, starts the same task sequence and at the end restores the data. 

A typical screenshot when doing a REFRESH (or bare metal)

(D: is a mounted ISO in Hyper-V with the prestage wim)
(I really would like to have pass through of USB sticks to Hyper-V directly, like VM-ware does it)

What about Software Updates?

Usually, content you add to the PreStage wim is used automatically, if referred to by the task sequence (through dynamic task sequence variables for example). But Software Updates can’t be made available to a PreStage wim file or a Full Media for that matter, not when using “Install Software Updates”. Maybe Microsoft adds this in a future update. As said before, this is about reducing a major part of the network traffic, not eliminating it completely.

What is working with a PreStage wim?

Microsoft doesn’t support a refresh from x64 to x86 or a downgrade of an OS, hence I don’t, at least not for Refresh. A bare metal install doesn’t care of course.

This is working:

  • X86 to x64 using a PreStage wim, theoretically, as I haven’t tested that. But as this isn’t directly linked with this method, I don’t see why it wouldn’t. Your capture and restore part is actually responsible for that.
  • Windows XP to Windows 7/8. Not tested, but again, the Restore Part is the critical part and I guess besides files nothing would migrate anyway.
  • Windows 7 to Windows 8.x migration (REFRESH), also using a PreStage wim
  • Bitlocker (Used Disk space only and regular)
  • Refresh in general from within the OS using USMT hard-links or SMP, also for side by side migrations.
  • UEFI and regular BIOS. UEFI tested on Hyper-V only.
  • OEM Hardware Vendors. I haven’t tested that yet, but if the computer is switched off instead of rebooted after applying the PreStage image, you may have an encrypted, but not yet bitlocker enabled installation. You should be able to provide such a disk to an OEM hardware vendor for duplication to use on newly delivered clients. You can still use the same same task sequence to finish the installation, while the volume is already encrypted, making this a one-step installation for those clients.

If you implemented some parts differently (enough), it may not work for you. Especially the refresh scenario is assuming the more Microsoft SCCM/MDT kind of way.
If you’re not using Bitlocker “used disk space only”, you still have less traffic, but the full encryption will slow it down. Less of an issue with SSDs but rather annoying on regular HDs. 

Not (yet) implemented:

  • Offline USMT hard link migration

Is it reliable?

Well, I’ve done hundreds if re-installs (really), once everything was in place, it always worked. So, yeah.

Also I don’t think there is a compatibility issue and I don’t think there should be a support issue by Microsoft (I hope). What is done here is basically what usually is done manually using different methods. All the original steps work basically the same, I’ll just ensure the required data is available so they can.

How is it done?

Basically two scripts, a few command lines (some very long) and a few *.flag files are used and of course quite a few task sequence steps.
As it is basically a two-step process merged into one and no information can be transferred directly to the PreStage part (the WIM), flag files are used to control the task sequence.
When the image is applied, CM by default would put all files, including the boot files on the OS volume, which also needs to be the active partition: The OS volume and the boot volume are the same.
To support bitlocker, those boot files need to be moved to the boot partition and that partition made active instead.
After the image was applied, instead of re-creating the boot (BCD)-data, everything is just moved from the OS-volume to the boot volume and the BCD-data updated using the new location. That ensures it always uses the boot image and the configuration data already part of the prestage wim, only the location where to start from is updated.
Once the regular “Apply Operating System” step is executed, CM takes care of applying all the required steps as when using a PreStage wim the regular way, like when using “Apply Data Image”
For a REFRESH installation the “Apply Operating System” step would take care of wiping the volume and apply the image. To wipe for the PreStage wim instead, a custom step deletes all content, only leaving “StateRestore” and _SMSTaskSequence. ImageX is then used to apply the image.
After the PreStage wim is applied and the task sequence starts again, the task sequence would be missing the parameters required for the State Restore steps and that some things have to be done differently or skipped now. Those are defined depending on the flag files created and then used by the regular State Restore steps. 


Although I provide an export of the task sequence, you probably can’t use it as-is (in a lab you likely can though). It’s provided so you can copy/paste into your task sequence, instead of entering everything manually.
The steps implemented are building up on what YOU implemented. Meaning if you didn’t implement bitlocker or a refresh scenario, it wouldn’t do it either.
In other words: If you implemented bitlocker and refresh already, close enough on how the default (MDT) task sequence does, this should work. Otherwise you have to figure out how to make this compatible. 

With that in mind, you need:

  • MDT-based “Client Task Sequence”
    It may work with a standard SCCM only task sequence, but I didn’t test. If you haven’t integrated MDT into SCCM, even just the minimum, you’re missing a lot.
  • A package
    No program.
    I named it “PreStagingTools”. You need to resolve the missing package when importing the task sequence. The package contains: 
    • ZTIUtility.vbs (from MDT, used by ApplyImage.wsf)
    • ApplyImage.wsf
    • GetWimPath.vbs
  • Prestage WIM File
    How you create this depends on whether or not you implemented zero touch, specifically if your deployment for the task sequence is “required” already or not (still prefer the term mandatory…).
    • PreStage Media with Zero Touch
      This process is meant to use zero touch deployment. While you could do lite touch, not suppressing the dialogs also means the process is interrupted, like in the middle, when WinPE from the PreStage wim starts. 

    Checking this option allows making this a fully automated process as it suppresses the dialogs once the prestage wim starts, but it also means additional requirements:

    • A “required” deployment
      Otherwise, the task sequence will just exit, complaining in the log that there isn’t a “required” deployment. 
    • Deploying to a known client record
      Not as much a required but a recommendation and I’ve tested it with zero touch only.
      As I favor zero touch very much, especially since I’d like to avoid the requirement for technical know-how on (remote) sites or even more, users entering any data at remote locations, where this is mostly used. Less of an issue on large data center sites, where prestage isn’t needed anyway, but likely one at small sites. 


    • PreStage Media with Lite Touch
      As said, not enabling the checkbox results in the wizard from the PreStage wim being displayed. While you still have the network traffic reduction and all the other imporovements, but it also means you have to click through the wizard once WinPE from the prestage media starts.
      If the computer is not known at this point, you need to enable “Unknown Computer” support when creating the wim and also likely need a script and some logic to define the computer name. I don’t think you want to add that information in the middle of the staging process, so maybe you take care of making that client a known entry during the first phase.
      In an OEM hardware vendor scenario it may be less of an issue as it starts directly with the PreStage wim and you likely have less of a problem with entering data at this point. 
  • An external Media for the PreStage wim
    The device needs to be accessible by Windows PE, basically any external HD or USB-stick should do. Also DVD (Blu-ray) if they are big enough (haven’t tested that). Using USB 3 will of course speed it up a lot. You can of course put the wim file on a bootable media also. You likely need to use the exFAT filesystem due the expected size of the wim. 

Task Sequence Steps

Initialization UEFI Disk Preparation

Due a bug, using the original disk layout may cause a failure. As that disk is only needed temporary, just creating one volume is sufficient avoiding that issue in any case. See Johan’s blog:
Where and order: 

In “Script exists and non-NTFS partitions”:

  • Duplicate “Format and Partition Disk (UEFI)”:
  • Delete all volumes except “OSDisk”

  • Delete or disable original step

Same for “Script does not exist or no partitions”:

  • Duplicate “Format and Partition Disk (UEFI)”:
  • Delete all volumes except “OSDisk”
  • Delete or disable original step

Preinstall Disk Preparation

Existing steps for regular deployment are duplicated and modified (instead of newly created). Additionally the original steps and the new ones are moved into new groups.

Where and order:

  • If you use “Set Diskpart BIOS Compatibiliy Mode”, place it below “Format Disk”

  • Create step “Run Command Line”
    Name: Check for local WIM file
    Command line: cscript.exe getwimpath.vbs prestage.wim WIMPath
    Package: “PreStagingTools”
    Conditions: if file %OSDisk%\PreStage.flag doesn’t exist 

    NOTE: Assumes that “OSDisk” is used as variable on the format step, which is default
    Searches for the wim in the root (only) of connected media and sets the full path of the wim file in the variable “WIMPath”
    The first file found will be used, you better not have several on different media or even one on the OS-Disk…
    There is currently no validation of the wim file, any wim would be applied. For security reason I’d add some checks. Even a simple size check could be sufficient where the size is provided as additional value to the script. Or even several.
    Update the preferred file name and variable name as appropriate. If you do, ensure that you update it everywhere else. 

  • Create Group
    Name: PreStaging
    Conditions: if Task Sequence Variable WimPath exists

  • Copy step “Format and Partition Disk (UEFI)” from below, rename to: “Format and Partition Disk (UEFI) PreStaging” and move in group “PreStaging”
  • Copy step “Format and Partition Disk 6.1” from below, rename to: “Format and Partition Disk 6.1 PreStaging” and move in group “PreStaging”
  • Copy step “Format and Partition Disk 6.0” from below, rename to: “Format and Partition Disk 6.0 PreStaging” and move in group “PreStaging”
  • Delete from all the duplicated PreStaging steps the condition “_SMSTSMediaType not equals OEMMedia”
  • For all non-UEFI PreStaging steps, add the BDEDrive variable to the BDEDrive partition:

  • Create Group:
    ame: Network
    Conditions: if Task Sequence Variable Wimpath not exists

  • Move original “Format and Partition” steps into the Network Group

Applying Image and Boot Configuration

This takes care of wiping the OS volume for a REFRESH, applying the image, creating some flags for later use, creating some variables and a (temporary) drive letter to have direct access to the UEFI boot partition, allowing moving/configuring BIOS/UEFI boot data for the prestage WinPE.
At the end a reboot is forced (the regular task sequence reboot steps can’t be used for that). 

Where and order:

  • If required, put “Set Variable for Driver Letter” after “Set Status 2”
    NOTE: I deploy images created by using Build and Capture, have that step disabled, and it always uses C:
  • Create step “Run Command Line”
    Name: “Check for local WIM file”
    Command line: cscript.exe getwimpath.vbs prestage.wim WIMPath
    Package: “PreStagingTools”
    Conditions: if file %OSDisk%\PreStage.flag doesn’t exist 

    OTE: You can also duplicate and move the same step from above
  • Create Group
    Name: PreStaging Image
    Conditions: if Task Sequence Variable WimPath exists
  • Create step “Run Command Line”
    Name: Wiping %OSDisk% (PreStaging)
    Command line: cmd.exe /c cd /d %osdisk% & for /d %i in (*) do if /i not “%~nxi”==”StateStore” if /i not “%~nxi”==”_SMSTaskSequence” rd /s /q “%i” & del /q *.*
    Watch out for the double quotes!
    Options: Continue on Error
    Conditions: Task Sequence Variable DeploymentType equals REFRESH

NOTE: This deletes all folders and files on the OSdisk, except “StateStore” and “_SMSTaskSequence”. I’ve started using powershell for this, but there is a known issue when deleting folders recursively: it just wouldn’t delete all, so I’ve used the RD command shell for deleting, mixing PS and CMD. But what’s the point, so I’ve opted to not use powershell at all, one pre-requisite less and use CMD only. I didn’t bother to do a progress support for that

  • Create step “Run Command Line”
    Name: Apply Operating System Image (PreStaging)
    Command line: cscript.exe ApplyImage.wsf %WimPath% 1 %osdisk%
    Package: PreStagingTool
    NOTE: This is applying the image and providing progress support

  • Create step “Run Command Line”
    Name: Create PreStaging Flag
    Command line: cmd.exe /c echo. >%OSDisk%\PreStage.fla
    NOTE: Without some kind of flag, it would cause a loop. And it’s easy doing it like that, even if there is fancier way doing that.
  • Create step “Run Command Line”
    Name: Create USMTLocal flag
    Command line: cmd.exe /c echo. >%OSDisk%\USMTLocal.flag
    Conditions: USMTLOCAL equals TRUE

    NOTE: That indicates that USMT was using hard links

  • Create Group
    Name: REFRESH
    Conditions: DeploymentType equals REFRESH
  • Create “Set Task Sequence Variable”
    Name: Set BDEDrive Variable
    Variable: BDEDrive
    Value: c:
    NOTE: In a REFRESH scenario, the disk wasn’t formatted, hence the variable is missing. It is always C: on REFRESH

  • Create step “Run Command Line”
    Name: Create Refresh.flag
    Command line: cmd.exe /c echo. >%OSDisk%\Refresh.flag
    NOTE: Required for later on at “Restore State”

  • Create step “Run Command Line
    Name: Assign letter for UEFI
    Command line: cmd.exe /c echo sel dis 0 >%temp%\dp.txt & echo sel par 2 >>%temp%\dp.txt & echo ass letter=s >>%temp%\dp.txt & diskpart /s %temp%\dp.txt
    Conditions: Task Sequence Variable _SMSTSBootUEFI equals TRUE
    NOTE: To be able to move the configuration data, a temporary mapping is created. It does assume the default disk layout.

  • Create step “Run Command Line”
    Name: Move/Configure BIOS Boot Data
    Command line: cmd.exe /c move %OSDisk%\bootmgr %bdedrive%\ & robocopy %OSDisk%\boot\ %bdedrive%\boot\ /e /move & bcdedit /import %bdedrive%\boot\bcd /clean & bcdedit /set {default} device ramdisk=[%osdisk%]\sources\boot.wim,{ramdiskConditions} & bcdedit /set {default} osdevice ramdisk=[%osdisk%]\sources\boot.wim,{ramdiskConditions}
    Conditions: Task Sequence Variable “_SMSTSBootUEFI” not equals TRUE
    NOTE: moves all boot data to the BDEDrive (the format step needs to have this variable set), imports the BCD store and redirects the path to use the OSDisk.

  • Create step “Run Command Line”
    Name: Move/Configure UEFI Boot Data
    Command line: cmd.exe /c robocopy %OSDisk%\boot s:\boot /s /move & robocopy %OSDisk%\EFI S:\EFI /s /move & move %OSDisk%\bootmgr.efi s:\ & bcdedit /import S:\EFI\Microsoft\Boot\BCD /clean & bcdedit -set {Default} device ramdisk=[%OSDisk%]\sources\boot.wim,{ramdiskConditions} & bcdedit -set {Default} osdevice ramdisk=[%OSDisk%]\sources\boot.wim,{ramdiskConditions}
    Conditions: Task Sequence Variable “_SMSTSBootUEFI” equals TRUE
    NOTE: Same for UEFI systems but using the temporary drive S:
  • Create step “Run Command Line”
    Name: Reboot
    Command line: cmd.exe /c timeout /t 3 & wpeutil reboot
    NOTE: Give it some time to write any cached data left and force a reboot.
    By using “wpeutil shutdown” instead, you should be able to use this disk as a base for OEM hardware vendors. Of course only a bare metal install does make sense.

State Restore 

This takes care of restoring the user data. On installations without using a prestage media the behavior is as-is, what you’ve implemented. When using Prestage media some variables have to be created.

Where and order:

  • Create Group below “Set Status 5”
    Name: PreStaging Restore Preparation
    Conditions: file %SYSTEMDRIVE%\Refresh.flag exists

    NOTE: All steps are skipped if PreStage media wasn’t used for REFRESH 
  • Create Group
    Name: SMP based Restore
    Conditions: if file %SYSTEMDRIVE%\USMTLOCAL.flag doesn’t exist
  • Create step “Set Task Sequence Variable”
    Name: Set DeploymentType to NEWCOMPUTER
    ariable: DeploymentType
    NOTE: if there isn’t an USMTLOCAL.flag, the REFRESH would have used a SMP, so setting DeploymentType to NEWCOMPUTER (bare metal). If there is a backup on the SMP this would be restored, also if there is an association. 
  • Create Group
    Name: Hard-link based Restore
    Conditions: file %SYSTEMDRIVE%\USMTLOCAL.flag exists

    NOTE: When USMT hard links were used, the path of the the store, DeploymentType and some variables need to be set. The steps doing the actual restore are unchanged. Without using PreStage media they are executed as by default
  • Create step “Set Task Sequence Variable”
    Name: Set DeploymentType to REFRESH
    Variable: DeploymentType
    Value: REFRESH
  • Create step “Set Task Sequence Variable”
    Name: Set OSDStateStorePath to %SYSTEMDRIVE%\StateStore
    ariable: OSDStateStorePath
    Value: %SYSTEMDRIVE%\StateStore
  • Create step “Set Task Sequence Variable”
    Variable: USMTLOCAL
    Value: TRUE
  • Create step “Set Task Sequence Variable”
    Name: Set OSDMigrateAdditionalRestoreConditions
    Variable: OSDMigrateAdditionalRestoreConditions
    Value: /hardlink /nocompress
  • Create step “Run Command Line” below “Apply GPO Pack”
    Name: PreStaging Cleanup
    Command line: cmd.exe /c rd /s /q %SYSTEMDRIVE%\statestore & del %SYSTEMDRIVE%\bootmgr & del %SYSTEMDRIVE%\smsbootsect.bak & del %SYSTEMDRIVE%\USMTLOCAL.flag & del %SYSTEMDRIVE%\Refresh.flag & del %SYSTEMDRIVE%\PreStage.flag
    Conditions: Continue on error

  • Attachments on my OneDrive as I can’t attach zip files:


Pausing an SCCM Task Sequence, a bit different.

That’s the first entry on my just newly created blog. Nothing fancy yet, more to come I hope.
And yes, I’m aware that there are countless postings on how to pause a task sequence.

I actually used one of those for my variation.
(Credits to the original author:

The difference is that while troubleshooting a Task Sequence, it may have quite a few breakpoints and not being able to figure out where it paused bothered me. Hence this improved version.

What does it do?

Instead of just opening a text box, saying like “pause, press ok to continue”, it displays the step name instead, informing at which point in the task sequence it stopped.
Additionally any variable available to the Task Sequence can be shown.

An example. Assume this is the Task Sequence Name;

(“! PAUSE” is added to make finding them easier in a (long) task sequence)

results in:


  • MDT
    It may actually work without it, but I didn’t try as I don’t see a point of not having MDT integrated with SCCM. It is so useful and base functionality is easy to learn.
  • A small VB-script.
    It’s small, I just add it here. Save this to a *.vbs file. Naturally the one you want to use for the command line, like “pause_ts.vbs”

    Set TsProgressUI = CreateObject(“Microsoft.SMS.TsProgressUI”)
    for i = 0 to wscript.arguments.count – 1
        step = step & wscript.arguments(i) & ” “
    MsgBox “Step: ” & step + chr(13) + chr(13) & “To resume the task sequence please click on OK.”, 64,”Task Sequence PAUSED!”

  • The servceUI.exe from MDT
    located here:

    For (automatic) x86 and x64 support, copy them both and rename them to (saves using scripts or if’s):

    • serviceUI_AMD64.exe
    • serviceUI_x86.exe
  • Put the script and the exe(s) in a package and distribute.
    No program required.
  • The Task Sequence Step
    Provide the Name (text) you want to be displayed, e.g.
    • “! PAUSE _SMSTSMachineName=%_SMSTSMachineName%”
    • “Pausing before my fancy custom action”
      Enter the command  line:
    • serviceUI_%PROCESSOR_ARCHITECTURE%.exe process:TSProgressUI.exe %SYSTEMROOT%\System32\wscript.exe pause_ts.vbs ‘%_SMSTSCurrentActionName%’
    • Select the package you’ve created


“That’s awesome, but I want to display a zillion variables at the same time and it doesn’t fit in the name field”

While you can add all kind of variables into the step name, you’re limited by the max. length for a step name: 50 chars.
If that isn’t enough, use the command line directly or a mix, to extend:

serviceUI_%PROCESSOR_ARCHITECTURE%.exe -process:TSProgressUI.exe %SYSTEMROOT%\System32\wscript.exe pause_ts.vbs ‘%_SMSTSCurrentActionName% COMPUTERNAME=%COMPUTERNAME%’

“How can I suppress those messages without deleting them?”

The simplest method is to check against a Task Sequence Variable such as “Debug equals true”.

Either enable/disable directly in the task sequence at the beginning for all or use collection/machine variables to control them more specifically.

Feedback welcome