Archive for the MDT 2010 Category

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

Since I recently posted pretty much everything that needed to be done to get this working properly on TechNet forums, I figured I might as well write a proper guide for it now.
I can imagine that some are like “why would you even want to?” well, it’s rather simple… there are still end-users who use this OS. And some of them can’t install Windows themselves, so they bring their pc to a local pc store, or any other pc system builder (with the exception of the “A”-brand OEM’s). Depending on the size of these companies, some might actually still do everything manually when it comes to installing Windows. Some might still keep a Win2003 server with RIS around for Windows XP installs. When I was setting up our deployment server, we already had a running deployment solution with RIS/WDS running on a server 2003 in hybrid mode. Windows Vista and Windows 7 installs were very slow due to the slower network stack and larger file sizes of the images to deploy. At first I created a new server to install just the Vista/Win7 with WDS, and soon thereafter using MDT as well (MDT had some limitations for me at that time which I first needed to work around creating scripts). But I was still stuck with an old RIS server for Windows XP installs, and really wanted to stop using 2 virtual servers for the deployments so it’s less management. Windows XP Professional was all very easy to do on MDT, however Windows XP Home Edition causes me a few errors down the road. I’ll describe the error’s you’ll run into when trying to deploy windows XP Home Edition with MDT 2010 and how to fix them.
First off, when you try to Import a new OS from source files and select a Windows XP Home disk, you will get an error saying:

Import Error

To fix this error, you will need to fool MDT thinking that the OS you’re trying to import is Windows XP Professional. To do this, you will need to rename a file in the root directory of the XP Home source files. One of the files below will suffice, however you can change them all if you want, the “highest” SP level that is changed from IC to IP will be the one that MDT will detect as an XP Professional source file directory.
• Win51IC > Win51IP (changing only this file, will make MDT recognize the imported OS as Windows XP Professional)
• Win51IC.SP2 > Win51IP.SP2 (changing only this file, will make MDT recognize the imported OS as Windows XP Professional SP2)
• Win51IC.SP3 > Win51IP.SP3 (changing only this file, will make MDT recognize the imported OS as Windows XP Professional SP3)

XP Home detected as Professional SKU

Above is an example where I only changed Win51IC.SP3 to Win51IP.SP3, notice how the default name MDT suggests is Windows XP Professional SP3?
Now you can continue to import the OS into the workbench.
The next error that you will run into is that MDT will try to auto-logon as the built-in Administrator account, named “Administrator”. While this account is actually marked as active, it’s not possible to log into this account unless booting from safe mode. Sometimes you might not actually see there is an error happening at this point and you will simply see this screen:

Windows XP Home logon screen

However, if you look closer and ALT-Tab you’ll see the following error:

Windows XP Home logon error

To resolve this, you will need to change the auto-logon settings.

Update: 04/11/2012;

To simplify the auto-logon fix discard my previously written explanation as the following method is far easier. You need to edit the Unattend.txt file of existing task sequences and change the following value as displayed below. Alternatively you can enter the same value (Computer’s Owner) during the creation of a task sequence in the screen that asks for Owner (this is the field you need to fill in with this value), Company name and website.
Note: Despite this value is written in English, it will translate correctly to all other languages of Windows XP Home you will install. I have verified this with multiple different language editions of XP Home, and the Autologon works correctly.

FullName=”Computer’s Owner”


We will need to edit the file “unattend.txt”, you can easily edit this file if you open the properties of the Windows XP Home task sequence (I presume you already created one after importing the OS, if you didn’t yet you will need to create one first) and go to the OS Info tab. From there click Edit Unattend.txt
The part we’re looking for is this;

“cscript.exe C:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe D:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe E:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe F:\MININT\Scripts\LiteTouch.wsf /start”

We’ll add a command in here that will change the Auto-logon value to the correct username. For the English version of Windows XP Home, it will be “Owner”, you will have to find the correct username if you use a different language. This is the default account created by the setup.

“regedit /s C:\MININT\Autologon.reg”
“cscript.exe C:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe D:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe E:\MININT\Scripts\LiteTouch.wsf /start”
“cscript.exe F:\MININT\Scripts\LiteTouch.wsf /start”

Now, create a new text file, and make sure to include the following text. Then save it as Autologon.reg (or name it differently if you want, but then adjust the filename again in the GuiRunOnce section of the Unattend.txt

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

At last you need to ensure that this file will be present on every single Windows XP Home installation. There are several ways you can achieve this, for example creating a new task in one of the early TS stages. The method I used, was making use of the $OEM$ folder within DeploymentShare\Operating Systems\{OS Name}. An example of this is shown in the picture below.

Windows XP Home $OEM$ folders

Now that the autologon will work again, the task sequencer can continue just like a normal Windows XP Professional installation. I hope this information was helpful to those few people who might actually need to deploy Windows XP Home edition for whatever reason, and couldn’t get it to work with MDT and for that reason were still stuck with RIS. If you happen to run into an issue, feel free to leave a message or contact me.


Be the first to comment