Archive for the MDT 2012 Category

After quite some requests I’ve spend some time to work out a new task sequence and updated file package for my original post “Configuring Windows RE with MDT 2012 Update 1”. The first version I published back for MDT 2010 required manual configuration in order to work properly, the updated post for MDT 2012 was built on top of that work but re-writing almost everything in order to make it a lot easier to use. I also included a proof-of-concept ready to use WinRE image (a modified WindowsPE image).

This updated version includes a new scenario that I’ve seen many try to implement after finding my post and then stumble upon various issues.

In a nutshell, I’ll describe in short what happens during the task sequence (obviously edits can be make to adjust to your needs)

  • Windows is deployed onto the system, but using a different partition layout: 2 partitions, the first is 10GB and marked as Recovery partition using Type 27, and the second is the remaining volume space for Windows.
  • After Windows has been installed, during the State Restore phase, a script will copy the custom WinRE image to the Recovery partition, and configure windows using ReAgentC.exe to use a custom WinRE environment.
  • Once all the steps in State Restore have been finished, Windows will reboot into WindowsPE (litetouchPE) and capture the Windows installation that was just installed to the Recovery partition.

This allows for very fast recovery of the system if the operating system is really messed up, as long as the bootmgr is still able to boot and the hardware is healthy. This solution is very similar to the recovery partitions that the big brand OEM’s supply with their systems.

The original task sequence I created would sysprep the system before rebooting into PE to capture the image, but this would disjoin the computer from the domain (if joined to a domain), and also cause an OOBE to appear after the task sequence was completed. This scenario would be fine for workgroup computers, or a system builder who wants to provide a recovery solution with their pc’s to their customers. However I’ve been contacted by quite some fellow admins working for large companies also wanting to setup something similar, but not have the machine disjoin from the domain.

The extra task sequence that’s provided in the script file package now actually does just that, it will work for enterprise usage… at a cost (I can’t see a way around this, but we’ll come to that in a minute).

  • Once all the tasks in the state restore phase have been completed, it will move on to the [Custom] Capture Image group, now instead of sysprepping the system it starts a different script.
  • This script does the following: It removes the drive letter R: from the recovery partition (this normally happens during sysprep), remove auto-logon/resume task sequence upon windows logon, re-enable system restore function, remove registry entry for last logged on user; this is not the policy setting “do not display last user name” (that way when the computer boots up for the first time it does not display pcname\administrator) and last.. but most importantly it sets the registry setting to disable the computer password change.
  • After that it reboots into WinPE, and captures the image and it’s done. Once you boot into windows you’re still joined to the domain and if you recover the image right away you’re still joined to the domain.

I would like to point out, that the last item, disabling the computer password change is not a recommended setting. However this is the only way to keep the system joined to the domain without losing it’s AD trust after restoring the recovery image after 30 days (if anyone knows an alternative I’m all ears). If you want to implement a solution like this, I would recommend you to read the following two Technet blog articles:

For more details on the task sequence itself and how to use it (as it’s almost identical to the original one), I’d like to refer to the original post.

The script files and ts.xml files are for download on the technet gallery, and the custom WinRE images are available for download on my skydrive.

Kind regards,

Stephan Schwarz

In this post I describe how I use a powershell script to automate the domain join process in MDT/SCCM to the correct OU based on the comptername.

While installing operating systems, software and troubleshooting the installation processes are one of the things I really enjoy doing, it frustrates me when I see a poorly implemented environment. Our environment unfortunately is one of those, so I’ve spent quite some time in order to get to a point where it’s starting to become fun again.

The Hospital I currently work for has a lot of OU’s, every department has it’s own OU for workstations (114 OU’s just for workstations). Since we didn’t have an automated method to place the computer automatically in the correct OU during deployment, it always meant there was manual work required; either create the computer object in AD before installing Windows, or move the computer account afterwards from the computers container.

At least we have a simple enough naming standard for the workstations, which is built in the following method: “Division number”-“department abbreviation”-“last 2 digits of the year when PC was bought”-“4–digit number, starting with 0001 as first PC bought that year”. To give an example, My workstation would be 0–ICT-12–0011 (11’th PC bought for the IT department in 2012), and the computer object for that PC would need to be placed in the workstation OU for the ICT department. When I went to look for some ready to use scripts to determine the OU based on a computer name I only found a handful of vbscripts that generally used a predefined number of control characters, for example the first 2 letters of the PC name. This was not a viable option for me, since I need to actually do a three step check on the name to place the computer in the proper OU. The following process is that we need in our environment.

  • Lets take 0–ICT-12–0011 as example
  • Check the first 2 characters of the name, if this matches 0–,1–,2–,3–,4– or 5– then go to next step
  • Since the PC name starts with a digit matching a division, it then needs to find the correct department; in my case it now needs to match 0–ICT
  • Once it matches a division and department, it also needs to verify the last 4 digits of the name, if this starts with the letter “K” (we have a few more exceptions) it means it’s a kiosk/panel PC which have their own OU…
  • Based on the last 4 characters of the name, we can determine wether we need to be placed in the workstation OU for ICT, or in the Kiosk OU for Division 0, since the last 4 characters are 0011, it means it’s a WS.
  • If for some reason the name would not match all criteria’s, I defined a “NonCompliant” OU which will contain all computers that do not follow the default naming policy, example: If I made a mistake while typing in the computername during the import computer object in SCCM and named it 1–ICT-12–0011, it would then be placed in the NonCompliant OU, since ICT is a department part of division 0, and not division 1.

I figured powershell would be a good candidate to tackle this for me, since I’m a lot more comfortable with that than with vbscript. So I started to write my own script to follow the exact steps I described above, due to the large amount of different OU’s I needed to define I ended with a 664 lines long script (also due to my formatting, however I find this very easy to read), but I figured I might as well share this in a more compact version that shows just how I applied this logic if you happen to need something similar in your environment.

The functionality of this script is very simple, it will define the task sequence variable ‘MachineObjectOU’ based on the OSDComputerName variable using If, ElseIf and Else statements. It also dumps all TS variables before, and after setting the MachineObjectOU variable to a file named ZTIVariablesExport.log in regular SCCM/MDT log path.

The script can be downloaded from the TechNet Gallery where I’ve also posted a small snippet of the code I’ve used. It can be used in the following scenario’s:

MDT standalone:

  • When using Windows PE 4.0 images, with the powershell component you can execute this script at any stage before the “Configure” step in the [Preinstall] node of a task sequence.
  • When using Windows PE 3.0 you’ll need to configure the task sequence (or your custom settings) in such a way that it does not join the domain by updating the unattend.xml file during the “Configure” step, since this will actually join the computer to the domain during the windows installation. By letting it default to a workgroup, and then run the powershell script during the [State Restore] node in the task sequence prior to the step “Recover From Domain” the PC will be placed in the proper OU during this part of the domain join process.
  • The only drawback for placing computers in a particular OU using the MachineObjectOU variable in MDT is that if the computer object is already present in AD, it will not be moved. Instead the PC will still be joined to the domain but the object will remain at the same location that it was already in. While you can do this with scripts as well, I really like Maik Koster’s web service (link) for this (and other) functionality.

ConfigMgr with MDT:

  • With ConfigMgr, configure a default OU (our staging OU) in the “Apply Network Settings” step in the [PostInstall] node (or when using UDI, configure the Domain Settings in the UDI designer) and during the [State Restore] node add this powershell script which will configure the MachineObjectOU variable, then execute Maik Koster’s ZTI_ExecuteWebservice.wsf script to move the account from the staging OU to the destination OU.


Feedback is always appreciated


Kind regards,

Stephan Schwarz

Updated @ 04/05/2013: Updated script files to include Domain Joined scenario.
I still need to update this post to reflect all the information in this post.
Important note: Thanks to the feedback, an issue has been found when using Windows ADK and deploying these task sequences, I’ve finally pinpointed the cause of the error and will soon update the file package to solve the issue (it has to do with the autofailover ability of Windows 7).

This post is an update of my previous post regarding the Windows Recovery Environment and how to configure it using MDT. My first post was based on MDT2010, this post has been revised to make use of MDT2012 (Update 1). If you’re not very well known with WinRE itself, I would recommend to read my original post regarding this topic: link

I will try to keep this post shorter than the original one, since most of the basics are still the same. Instead what I’ll discuss will be the changes that I’ve made to improve the overall ease of use. The last few months I’ve seen an increased number of emails asking for assistance with my original post on this topic, instead of always trying to help 1 person at a time and try to pinpoint their specific issues I figured I’d just create an update to this that’s less prone to errors.

I’ve spent quite some time in refining the scripts that I’ve used and added some basic logging that should make it easier to identify errors in case one of the tasks fails. I’ve also managed to consolidate all the different batch files, and the different diskpart scripts to 1 single batch file.

So in a bullet point list as of what’s new:

  • Scripts are now located in a subdirectory of the %scriptroot% folder named [\WinRE]
  • All script files have been consolidated into 1 single batch script [MDT-WinRE.cmd]
  • Support for cross-architecture deployments (meaning you can deploy a 64-bit Windows version from a 32-bit WinPE)
  • LTISysprep.wsf from MDT2012 U1 has been modified in order to function properly.
  • ZTIBackup.wsf from MDT2012 U1 has been modified, this time I’ve taken the time to carefully edit the file and only remove the unneeded sections. It’s no longer a simple rename action of the uselocal variable value in order to force it to use the local disk. All checks are still in place, it will now properly fail before starting ImageX to capture if there’s not enough disk space available to create the .wim file.
  • All variables that previously needed to be edited inside the various script files can now all be configured within the task sequence, as task sequence variables.
  • Disk Configuration will be handled by the MDT built-in Format and Partition disk step, you can adjust this to your needs.
  • I’ve created a Custom Recovery tool for inside Windows RE, this means that the Windows Setup is no longer used for the restore process, but instead ImageX will be used. Using this method will delete all data on the Windows volume, and no “Windows.old” folder will be created.
  • I’ve configured a custom hotkey to directly start the custom recovery tool, this is [F1]. You can manually assign a different boot key by editing the MDT-WinRE.cmd script (look for /Bootkey).
  • I’ve noticed a lot of people had issues once they had restored their image with a duplicated boot menu entry. This meant that upon startup they would see two identical boot menu entries for Windows 7, adding a boot delay of up to 30 sec. The script that restores the recovery image onto the HDD will configure a new BCD meaning that this issue has been resolved.
  • This time I’m also providing a pre-built WinRE.wim for both x86 and x64 machines. Note: these will be driver-less, however they will contain the CustomRE tool and have all the packages as required, you can use as reference to see what I did if you want to create your own. These images are ready to use, unless you need to add drivers, or other language packs since I only choose to use the en-US language.
  • The task sequence template has been revised and I’ve updated the descriptions of various tasks.
  • It’s now no longer required to use Audit-Mode, hence I’ve removed providing a unattend.xml file; you can use the default unattend.xml file that’s created by MDT.
  • If you need to use USMT to migrate data from the user profile(s) and possibly even restore it, this is all completely possible, however you will need to add this functionality yourself by adding the proper commands to the scripts.

As for the actual links to the files, scroll to the bottom of this post. They will be hosted on my SkyDrive account, I’ve marked them as public so anyone should be able to download them.

Next I’ll provide some screenshots of how the changes look like.

Below you can see the new Task Sequence, along with the different variables. Important: Do not forget to adjust the Install Image inside the task sequence so it points to one of your own images, when opening the task sequence you will be pointed out there is an error regarding this.
Task Sequence

If you want to trigger the recovery environment from within Windows itself, you can do it from within this menu.

Windows 7 Recovery Control Panel

After you select the “Return your computer to factory condition” you are prompted whether or not you want to create a backup of your data, regardless of your answer; when you have restored Windows and boot into Windows for the first time, you’re prompted whether you want to restore your files from a backup or not. When you confirm that you want to recover the pc, the pc will reboot right away and start WinRE and load the custom recovery tool. There will be no WinRE menu.

Windows 7 Advanced Recovery Options

This is the default WinRE menu that is present when you start windows by pressing [F8] and using the “Repair my computer” option. However, now there’s an additional item at the bottom that will be able to start the custom recovery tool.

WinRE Menu

The HTA that I’ve created that will function as the “front-end” for the recovery process, has been configured to display no borders, and fill the screen. Below is a screen capture from within WinRE. This screen will be started right away without the WinRE menu (previous picture) when you boot the pc and press [F1] or start WinRE from within Windows’s Recovery control panel item.

CustomRE tool (hta application)

Once you start the recovery process, it will look as followning.

Recovery in progress


The message below would be displayed if the recovery process succeeds, if a failure occurs for whatever reason, it will display a message box that will return the error code.

WinRE recovery success

The download link to the script files and TS is the following:
The download link to the WinRE images is the following:

Please drop me a line through one of the channels to contact me on the [About Me] page whether everything’s working properly or not, this info can help me to make improvements. Next to that it gives me an idea what the interest is in this particular topic. 

As for what to do with the files inside the package, it will contain two different folder structures.

The DeploymentShare folder contains the files in the appropriate structure that should be placed inside the root of your deployment share. Note: The task sequence file that I’m providing actually needs to be manually replaced with a task sequence that you create yourself. This means you create a new task sequence, and take note of the TSID you give it, go to the DS\Control\TSID folder and replace the ts.xml file with the one I’m providing. You can see a WinRE folder at the root level of the DeploymentShare folder, I’m using this location as the new default folder that will contain the WinREx86.wim and WinREx64.wim image files (these files are available for download as well), if you do not want to host these files inside the DS, you will need to alter the path for these images in the task sequence variable [RecoveryImagePath].

The WinRE.wim source files folder will contain all the files in it’s appropriate file and folder structure to create the WinRE.wim image manually. This also gives you insight into the specific tasks being executed when the recovery process starts, allowing you to edit this if you need to adjust this. Note: The CustomRE.exe executable is a simple launcher for the RecoveryWizard.hta file, all it does it load a file with that specific name and wait for the process to terminate before it closes itself. This is a requirement because the CustomRE tool defined within WinREConfig.xml has to be an .exe type of file in order to read the product name, and description and the icon, otherwise you might end up with a very weird looking menu entry. The code I used for creating this file is included as well.

Kind regards,

Stephan Schwarz



This post will explain a limitation of cross-architecture deployments of Windows 7 using MDT2012 along with a work-around.

After receiving an email from someone who was having issues deploying a Norwegian version of Windows 7 64-Bit using the LiteTouchPE 32-Bit environment (and had no problems at all when deploying it using LiteTouchPE 64-Bit) I quickly came to the conclusion that the actual setup.exe process that was executed when running in LT-PE x86 was from a set of source files that was from a different language. This is an error that I’ve seen often enough back in MDT2010 where you’d import a new custom .wim image to the deployment share without the setup source files and the image being deployed is actually a different language from those that are already present in the deploymentshare.

Windows Setup Error

This was also one of those topics that came by on the technet forums rather often, and the simple solution was by re-importing the custom image with the setup files (in the appropriate language). However, cross-architecture deployment was not possible back with MDT2010, but now that it is, this very same subject resurfaces again due to the built-in logic of finding setup.exe.

So why does this happen? It’s simple when deploying Windows Vista/7/Server 2008/R2 this will be handled by running setup.exe along with an unattend file, but with a cross-architecture deployment (note: can only deploy x64 from x86, but cannot deploy x86 from x64 PE environments and only works for Windows 7/Server 2008R2) the 64-bit setup files are not able to be executed from a 32-bit PE environment. MDT will look in this scenario for an alternate setup anywhere in the other Operating Systems that have been imported into MDT that did include 32-Bit setup files (note: importing a x64 .wim file and providing 32-bit setup files will still report to MDT as a x64 platform).

At first when I saw this, I thought of a couple of solutions. However, after some more research I’ve came across a post regarding issues deploying Windows 7 with MDT2012 in combination with ADK (this replaces the WAIK/OPK for Windows 8). The following quote is a post of Michael Niehaus [link] (scroll down near to the bottom).

As mentioned before, this is an incompatibility between the beta ADK and Window 7 Setup.exe. This won’t be fixed in ADK or in Windows 7 Setup.exe, so in a future MDT release we will stop using Setup.exe to install Windows, which will avoid the issue.

This issue is also documented in the MDT 2012 release notes. We still suggest using Windows AIK for Windows 7 deployments, unless you are in a lab environment and are willing to put up with small issues like this.

Note that if you import your Windows 7 and Windows Server 2008 R2 images into Workbench without the full source files (just import the Install.wim), then you won’t see this popup when using ADK because MDT 2012 will automatically fall back to using ImageX to install the image instead of Setup.exe. (The change we are making in our next release is to make ImageX the default.)

Now seeing the statement regarding that the default behavior for Windows 7 and Server 2008R2 installations will be handled by ImageX instead of setup.exe, I would personally just suggest to already start planning towards this new change. There’s no drawback for using ImageX.exe vs Setup.exe since offline servicing will still be done after the image has been applied onto the disk (this adds the drivers, LP, patches and such).

I’ve already updated my deployment share that I use for development/testing to reflect this new change, I’ve re-imported all images as plain install.wim files so the entire deployment share does not include any setup files for Windows 7/2008R2 (this can be done for Vista/2008 as well if you wanted to, these do not support cross architecture deployment though). This change also gave me back about 300MB per imported Operating System in my workbench this can add up quickly if you’ve imported a lot of OS’s into the workbench. Note: I don’t even use the ADK yet for this particular share, I still use WAIK to be honest, I prefer this method over running setup, since you gain a time indicator that will tell you how long it’ll take before the image is applied onto the machine, but more importantly the install time is decreased significantly (image being applied within 5 minutes in my lab environment). This is also the method that ConfigMgr 2007 and 2012 apply custom wim images to clients, they dont use setup.exe for that either.

Kind regards,

Stephan Schwarz

Note: I’ve revised this topic to include a task sequence for MDT2012 at


This post will give a more in-depth explanation how to properly setup the Windows 7 Recovery Environment. Quite some time ago I helped someone on TechNet forums the to set this up, however I never really gotten around to clean up the info I provided into an easy to read format and consolidate all the information into 1 single post. At the end of this post, I’ll provide a TS.XML file for MDT 2010. This will be a template so it’s easier to see what steps need to be done in order to get everything working. Also I’ll provide the necessary scripts at the end. This will also give you the general idea how to configure this with the beta of MDT 2012. Once MDT2012 has been released as a final build, I’ll provide files for that as well.

While by default Windows 7 has “WinRE” installed on it, this is only the default Windows PE environment with a couple of recovery options, to enable a full system recovery from HDD further configuration is required. The purpose of this post however is to show how you are able to make a fully functioning recovery partition like the big OEM’s have, but then with the built-in tools from Microsoft. This means that you’re able to revert to the fresh Windows installation at the time the pc was first put to use.

This also could help providing mobile workers with a method to re-install their system, without needing to be in the office. For an enterprise scenario like this, where you often have to deal with domain joined systems, further configuration is needed and goes beyond the scope of this post. If this is something you seek to do, feel free to contact me (contact details are on the about me page) and I’ll be happy to point you in the right direction.

This post will cover how to successfully get WinRE working with MDT, with single disk configurations. While it’s possible to configure it to work with multiple HDD’s, this will make this entire post far more complex. Again, feel free to contact me if you need assistance for that scenario.

The reference documentation for the Windows Recovery Environment can be found here. It’ll explain how to customize the PE environment with your own custom tool if you would want to use that instead. Or define a bootkey on which WinRE should respond and several other things (default is F8). However the various pages often link to a different section again and you’ll find yourself jumping from page to page to find all the information you need.

For the following information, I assume you will have basic knowledge when it comes to imaging with Windows 7, and have some experience with ImageX and Dism to mount and modify a WinPE image to add drivers. I’ve followed most of the guidelines and recommendations set by Microsoft for setting up the recovery environment I once created for the company I used to work for. However I’ve deviated somewhat from these since it either worked out better, or since the default caused problems.

Please note: This guide will help you to create a task sequence with MDT 2010/2012, that installs Windows 7 (or Server 2008, method is exactly the same) in audit mode, configures WinRE accordingly and then syspreps the system. After this the system will reboot and start a capture of the system state onto the Recovery Partition. Once that’s completed, the system can be rebooted and be put to use, you will be presented with the Windows OOBE, and can either call the recovery environment from within Windows (Start Menu > type “Recovery” in search > Open Recovery > Advanced recovery methods > Reinstall Windows) or during the boot phase, right before Windows boots press F8, and select the “Repair my pc” option on the top. Once inside WinPE, select “Reinstall Windows”.

Windows Recovery environment requires a separate partition from the actual Windows Partition, the files WinRE.wim and Install.wim. You should be familiar with the .wim file extension. The WinRE.wim file can be found in the \Windows\System32\Recovery folder of a default Windows 7 or Server 2008 Install.wim image. The WinRE.wim image is not bound to a certain Windows Edition, however architecture type needs to be separated. This means if you use both x86 and x64 systems in your environment, you will need to extract both of these files. Please note; If you require special mass storage device drivers (for example sas/sata hba’s or raid controllers) you should include these in the WinRE.wim file, so the end-user does not have to load the driver manually.

The proper partition scheme according to Microsoft is

Recovery partition System Reserved (Boot) Windows

However, when I applied this partition scheme, I ended up with several unbootable systems that were build at that time. The moment the HDD’s had this partition scheme, the HDD’s would no longer be detected during the AHCI disk detection, when SATA operation mode would be changed to IDE, everything was working properly though. This was unacceptable for me, and since I have not yet found a fix for it yet (this occurred on both recent Intel and AMD systems on the onboard HBA) I’ve tried a different layout, which worked flawless in my case.

Recovery & Boot Partition Windows

The added benefit of this is that you have one more primary partition that you can create on the disk compared to the recommended layout, since with a basic disk, a max of 4 primary partitions is possible. I’m personally not a fan of many partitions, since this makes migration to a new OS always harder (read: more work).

The Recovery partition will be given the ID of 27, which will hide the disk in the Windows Explorer, and make no actions possible on it in the Disk Manager MMC Snap-in. Since MDT lacks the option to set an ID with the GUI, I created a small diskpart script that does this for me. At this same time I copy the WinRE.wim file that I extracted to a network share, to the recovery partition into the folder “\Recovery\WindowsRE\”

After Windows boots into audit mode, ReagentC.exe is called to configure the paths of the WinRE.wim and Install.wim files. During this time you have the option to install any software you want to be included in the recovery image. After the system has been updated and all necessary software has been installed, Sysprep will be executed (default is with /generalize option, however if you do not plan on using cloning techniques to provision the same HDD image to other computers, this option can be disabled) and WinPE (LiteTouchPE) will be installed onto the HDD, and the computer will restart. Once inside the PE, the task sequencer will start to run a customized version of ZTIBackup.wsf that saves the image onto the recovery partition.

Both the modified LTISysprep and ZTIBackup scripts will be included with the rest of the files I’ve created to create this task sequence. You can find these files at the bottom of the post.

The provided task sequence will have descriptions in some of the custom task sequence steps, it’s possible the field is not large enough to display the entire text, so use your mouse to highlight it all and copy paste it into notepad for example. Every step that deviates from the regular “standard client install” template has been marked with [Custom] tags, and all steps that are not needed, have been disabled. Some steps will not work properly if enabled (Bitlocker will cause problems for example if you try to capture the OS from inside WinPE if the drive has been encrypted).

The easiest method to import the task sequence is to create a new task sequence in your workbench, and remember the Task Sequence ID. When you go to the folder \DeploymentShareName\Control\TaskID\ you will see both a unattend.xml and ts.xml file. Replace both of these with the files provided in the archive. All other files will need to be placed in the %Scriptroot% (\Deploymentsharename\Scripts). To avoid clutter, only 2 files will be placed in the root, since these require other mdt files to work properly, and the rest will be placed in a new folder named “WinRE”. The only change to the unattend.xml file is the addition of the boot into Audit mode setting, since this is a requirement for this task sequence template.

Once you open the task sequence after the ts.xml file has been replaced, you will notice there’s an error. This is normal since you will have to fix the Windows Image that has to be installed. See the screenshot below.

Task Sequence (Win7 with RE)


Please edit the following files with the appropriate servername and unc path.
WinRE\Configure-HDD.cmd, change the REimagepath and DS entry.

WinRE\Enable-WinRE.cmd, change the DS entry.

WinRE\Re-assign DriveLetter.cmd, change the DS entry.

The partition size can be edited in the file “DiskConfig.txt”, my default setting is 10GB. Make sure this partition is large enough if you decide to install many applications that need to be included in the system recovery image.

LTISysprepOEM.wsf. At line 108, you can choose to remove the ‘ at the beginning to enable the copying from a custom unattend.xml that sysprep should use to apply system settings for the end-user. Examples would be, time-zone, creation of user accounts, automate ( all or most of) the OOBE. Make sure to supply the unc path to the unattend.xml file. At line 121 you can remove the /generalize option if you do not plan on cloning the hard disk to other pc’s after the task sequence has completed.

You can download the zip archive that contains the files used for this task sequence here: link.


Kind regards,

Stephan Schwarz.

Andrew Barnes recently posted on his blog how to make use of BGinfo with the LiteTouch WindowsPE environment to show some very usefull local information (or simply change the background during certain steps in the task sequence if you wanted, since that works too). The main downside of BGinfo, or WindowsPE (depends which you want to blame) is that BGinfo will only work in the 32-bit/x86 WindowsPE environment. This is due to the fact that BGinfo is a 32-bit application and WindowsPE x64 does not have the Windows on Windows subsystem to provide compatibility with applications that are 32-bit.

This actually reminded me of a new feature which will be added to MDT2012, it’s cross-platform installation support. While this actually isn’t entirely “new” as this has been supported with the Windows Setup client from Windows Vista. There’s a catch though, from an 32-bit WinPE you can install both x86 and x64 images. On the other hand, with a 64-bit WinPE you can only install x64 images, x86 images will simply be filtered out. Since WDS uses pretty much the same Windows Setup, the same was supported for WDS as it was for normal media installations although in the latter one you would have to create your custom install.wim that would contain all the different windows editions.

I personally am a minimalist regarding pretty much everything, the fewer things my technicians are able to choose from the less support I have to provide. While I’m still testing out MDT2012 in my dev. environment to make sure all my custom scripts are still working as intended, eventually I plan to switch to this cross-platform installation method from a 32-bit WinPE with MDT2012 instead of having both an x64 and x86 boot image (it’s just the scripts of MDT2010 that didn’t contain the logic for this). There are a few pro’s and only one con I can think of with this new “feature”.


  • Both x86 and x64 architecture task sequences are available from 1 WinPE boot image.
  • It’s possible to use BGinfo along with x64 installations (since you’re running from a x86 environment)
  • Since Trace64.exe isn’t available via an official download, you can use Trace32.exe for local logfile reading without needing to download Trace64.exe from a possible unsafe source.


  • Since both x86 and x64 task sequences are available in the task sequence list, and depending on how many task sequences you have, you might be presented with a huge list of task sequences to choose from. Now for this part I’m actually writing this post.

You might have noticed that task sequences and applications when placed in folders, these folders will (for most users) open by default in expanded mode. At first I didn’t know where to look for a feature or function to leave the folders collapsed by default. There’s no option for that, at least not a “clickable” one. One method would be to change the MDT scripts, which I personally rather leave as they are, but the method I’ll describe here is far easier.

The default behaviour of MDT is to show task sequences/applications in the root (obviously) and if you create one folder and place either ts’s or apps in there, this folder will be expanded to show the contents of it. However, if you create another folder inside these tier 1 folders, then these tier 2 folders will stay collapsed when the wizard prompts you to select a task sequence or application. To visualize this a bit more I’ll place a screenshot below; this is actually a screenshot of the MDT2012 Beta to show you that within a 32-bit Windows PE, now both my x86 and x64 task sequences are shown. Note: On the screenshot, I have not manually expanded any folder, the way it’s shown is how MDT will expand/collapse folders by default.

MDT 2012 Beta TS selection

Knowing this, should help you prevent enormously large lists of task sequences and applications you need to scroll through. But what now if you actually would want to sort these? Keith Garner from XtremeDeployments created two tools to help you manually sort task sequences and applications using a simple UI. I encourage you to read his post at for the working of the applications and their limitations. I noticed that the task sequence sorting tool link does not work anymore, however you can get both of the tools from his skydrive. While these tools have been written for mdt 2010, they work without problems on the mdt 2012 beta, my hopes are that they will not break with the final release :).

Note: Another usefull thing to know is when you change the order that Applications are listed, that’ll be the order that the applications will be installed. Normally you can only arrange the installation order of Applications by creating an application bundle.

I hope you enjoyed the read, if you have any comments about my writing style just drop a line; afterall I’m new to all this :).

Kind regards,


Be the first to comment