Tag Archives: mdt

MDT – How I build my reference images (User Question)

Published / by Rens Hollanders / 15 Comments on MDT – How I build my reference images (User Question)

Based on my last post: “MDT – Post me your MDT Questions” I’ve received a question from mr. “Jones” who reached out to me with the following comment:


Great that Microsoft at last put an understandable Technet article on “Create a Windows 8.1 Reference Image”. Great comments by you aswell on clearing the event logs. I think Microsoft should put that as default in MDT.

Maybe there are some other small “tips” that you ALWAYS perform at every MDT installation you do that you can share with us?

So to put my words in action, this is how I build my reference images.

!Note: this post focusses on building a Windows 8.1 Enterprise image, but with some adjustments can well be used for a Windows 7 Enterprise deployment.

1. Use the ConfigureDeploymentShare script.

To get a headstart with configuring MDT, you can save a lot of time by using my powershell script. It will create and configure everything in your deploymentshare, based on a logical structure I’ve designed.

You can find the script and post about it, here: “MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

2. Create a build task sequence

Within MDT there are several templates available which set you up with a task sequence from where you should be able to do a deployment.

Now understand that there is no difference between a so called ‘build task sequence’ and a ‘deploy task sequence’, the differences are made by the person that’s responsible for the MDT environment.

To get started, I assume you have already imported the following sources:

  • Operating System source (like from a Microsoft ISO file)
  • Applications (like visual C++ redistributables, Office 2013 etc.)
  • Possible VMware drivers (if you are building your image on a VMware platform)
  • Packages containing Windows 8.1 update files
  • Language packs

Under the task sequences node, select the Build folder, which represents task sequences that are used for creating reference images:

figure 2.1: Task Sequence Node


and on the right side pane, click “New Task Sequence”

figure 2.2: New Task Sequence


From there a wizard will start, asking some basic information. This information is used to generate the unattended.xml which is used to deploy the operating system unattended with the information specified in the xml file.

figure 2.3: Task Sequence Wizard – General Settings


In the general settings, I always like to specify a build task sequence with OSB (derived from Operating System Build) followed with a unique number. If this is the first task sequence, call it OSB001

figure 2.4: Task Sequence Wizard – Select Template



Select the standard client task sequence if you want to deploy a client, select the standard server task sequence, if you want to deploy a server

figure 2.5: Task Sequence Wizard – Select OS


Select the base operating system image source

figure 2.6: Task Sequence Wizard – Specify Product Key


Normally for any deployment task sequence, you need to specify a product key. Since we are building an image here, this is not necessary. Presumably by the time you have reached the 180 day grace-period, your image must have been built 😉

figure 2.7: Task Sequence Wizard – OS Settings


The same goes for the OS Settings, why specify the company name during the build already, when the company information is only relevant during deployment. Using generic information, does not cloud your image with irrelevant information, and enables you the use the images for more then one company for instance.

figure 2.8 : Task Sequence Wizard – Admin Password


I always work with a specified admin password, nothing more to add here

figure 2.9: Task Sequence Wizard – Summary



The summary displays the information we have provided before the task sequence is created.

figure 2.10: Task Sequence Wizard – Confirmation


And lastly, the task sequence is created. And for the powershell fanatics among us, a script to perform these steps is provided:

Now that’s out of the way. Lets have a closer look at the Task Sequence properties.

3. Task Sequence Properties

Open up your task sequence, to modify the following settings:

!Note I will only describe the changes I’ve made to the default “standard client task sequence”

First: create the following Task Sequence Variables, stored in a group called Task Sequence Variables, prior to the “Initialize” step:

  • TSVAR: WindowsSource
  • VALUE: %DeployRoot%\Operating Systems\Windows_8.1_Enterprise_x64\sources\sxs
  • TSVAR: DoCapture
  • TSVAR: ComputerBackupLocation
  • VALUE: %DEPLOYROOT%\Captures
  • TSVAR: BackupFile
  • Value: W81ENTx64.wim
  • TSVAR: FinishAction

These Task Sequence Variables are set with the task sequence, and define the following actions:

WindowsSource, points to the sources\sxs folder which is needed in some cases when you want to install the .NET FX role with your Windows 8.1 installation
DoCapture, sets the flag to yes, so that at the end of your deployment the machine will be captured to a wim file
ComputerBackupLocation, determines the location where the wim file will be stored
BackupFile, specifies the name of the wim file, which sometimes may differ from what you normally want to call it, due to testing purposes
FinishAction, specifies that when the machine is finished capturing the wim file it will shutdown automatically.

By now you should have a task sequence which looks like this:

figure 3.1: Task Sequence Variables at the beginning of your task sequence


this is also the moment to say: “I wish MDT Task Sequnces had a maximize button” – Which the MDT Team already came back to me explaining it’s a restriction of the current GUI / Console they are using 🙁

Next stop: Go to the Preinstall step, and select “Inject Drivers”. At this step, select the preconfigured selection profile: “Drivers_Virtual_VMware”

figure 3.2: Driver Selection Profile


Selecting a driver profile for injecting drivers, makes sure incorrect drivers are not injected during this phase, which can cause a lot of trouble at later stages during the deployment

Next, under the “Inject Drivers” step, you will find the “Apply Patches” step. From the preconfigured selection profile, select: “Packages_Windows_8.1_x64”

figure 3.3: Packages Selection Profile


Injecting packages upfront will shorten the time Windows Updates will run post-Operating System installation. This means that update files can be changed offline which is much faster then online update installation. Since there are no services running yet, no DLL’s registered, etc.

Next stop: “State Restore”, since the “Install” step only concerns applying the source wim file to the virtual machine and post install is setting up and configuring the machine for use. We can skip these steps and advance straightaway to the “State Restore” step.

Make sure to enable both “Windows Update” steps, if you want to service your image with the latest available updates! Besides this, remove the “Install Application step” and move the “Custom Tasks” step, inbetween the two Windows Update steps. Like this:

figure 3.4: State restore – Windows Updates and Custom Tasks


Underneath the “Custom Tasks” step, I’ve created the following steps:

  • Install Roles and Services – Windows 8.1 – .NET Framework 3.5 and 4.5
  • Restart computer
  • Install application – Windows 8.1 Language Pack
  • New group, called: “Install Visual C++ Redistributables”
  • Install application – Visual C++ 2005 up to 2013
  • New group, called: “Install Office Suite”
  • Install application – Office 2013, incl. language packs
figure 3.5: Install Roles and Features


figure 3.6: State Restore – Custom Tasks


Of course these steps can be altered and can be focused on the requirements of your own organization. This is not a best practice, this is just my way of building a corporate ready reference image.

Next stop, is the end of the task sequence, right before the machine will be sysprepped and captured into a wim file, I perform a cleanup of several things:

  • Temp files and temp directories, such as logfiles that have been left over from the Visual C++ installation, the “Perflogs” and “temp” directory etc.
  • Clean up logfiles, this makes sure your logfiles are clean and empty before the machine is being captured. This makes sure that newly deployed machines don’t have a logfile full of entries back at the day the reference image was created.
figure 3.7: Cleanup phase


The cleanup happens with a powershell script, which is located in the .\DeploymentShare\Scripts folder and called with a “PowerShell Script” step:

  • %ScriptRoot%\OSDCleanup.ps1

The contents of the script, are as following:

Log files can be easily cleaned by performing the following “Run Command Lines”:

  • – wevtutil cl application (for the application log)
  • – wevtutil cl security (for the security log)
  • – wevtutil cl system (for the system log)

And last but not least, before the sysprep and capture phase takes place, one final reboot of the machine to process system changes that otherwise may interfere with the sysprep process and may cause your entire task sequence to fail at this point.

figure 3.8: Reboot -just to be sure-


And that is how I build my reference images mr. Jones 🙂

If there is any need to manually make changes before the machine is being captured, just insert the following “Run Command line” right after the Windows Updates (Post application installation) process: “cscript %ScriptRoot%\LTISuspend.wsf”

This will create a shortcut on the desktop, enabling you to make adjustments, restarting the computer and when finished making alterations, to continue the process of creating the reference image.

For more information about LTISuspend, please visit this great blog written by Michael Niehaus: “MDT 2010 New Feature #3: Suspend and resume a Lite Touch task sequence

This concludes my blog for this time. I felt I had to make it up to all of you, due to my absence the past couple of weeks 😀

I’ll leave you with the content for and from this blog, which contains the screenshots used in this blog. The scripts, and installation command’s of the applications used in this blog, like visual c++, Office 2013, language packs, and many more…


Untill next time my padawan automaters 😉


MDT – Post me your MDT Questions

Published / by Rens Hollanders / 209 Comments on MDT – Post me your MDT Questions

Hi guys and girls, it’s been a while since I’ve written an post related to MDT or anything other useful to contribute.

At this moment my inspiration for writing blogs is on the back-burner. This is also due to the fact that writing about MDT is related to the things I encounter in my day to day activities, which are going pretty solid at this moment.  (I’m mostly relaxing, watching the World Cup Soccer, and doing other things not work related)

The’re no issues I’d encounter and had to resolve, and unfortunately no new stuff I haven’t done. So if there’s is anything you would like to know or would like to have explained. Don’t hesitate and leave your comment or remarks in the comment section.

Cheers! 🙂

MDT – Microsoft releases advanced how-to MDT technet articles and more…

Published / by Rens Hollanders / Leave a Comment

Hi guys,

Long time since my previous post but I’m kinda in the middle of moving our stuff after we have sold our house, so I’ve been a little bit occupied at the moment. However there are some great things to report:

As you perhaps might know, TechEd North America has kicked off today, already with some fantastic new things and improvements to report.

One of them is regarding to Operating System Deployment with the Microsoft Deployment Toolkit.

As stated by other persons on the web busy with Operating System Deployment, Microsoft isn’t any longer showing how one can perform an Operating System Deployment with MDT, but it is exactly telling us what to do, and how it can be achieved.

Please see the following section on technet, and this link in particular: Create a Windows 8.1 Reference Image

Next thing is that deployment guru and MVP Johan Arwidmark known for his website: http://deploymentresearch.com now has released a weekly update for us “deployment geeks” called: “Deployment News”, you can check in on him every week on his youtube channel

I’ve taken the liberty to embed the first two episodes of Deployment News on this blog!

Deployment News – Episode 1

Deployment News – Episode 2

That I’ll be all for know, I’m working on a post regarding OS deployments with MDT on VMware, since I’ve noticed a big difference in performance between Intel E1000 and VMXNET3 NIC’s

Cheers and see you soon!

MDT – Automating IE Blocker for Windows

Published / by Rens Hollanders / Leave a Comment

Today I was at a client which had a question among others about blocking the automatic installation of Internet Explorer 11.0 on clients which needed to run on Internet Explorer 8.0 only.

I was there integrating some new things in MDT when the question came from the person responsible for deploying the machines at their site. Since the company was not running WSUS and had not configured GPO’s to regulate Windows Updates. I needed to find another solution to prevent the automatic installation of any Internet Explorer version higher then 8.0.

While already made a regshot of a machine where I chose to hide the installation of Internet Explorer 9.0, 10.0 and 11.0, I struck a Microsoft link which referred to: Toolkit to Disable Automatic Delivery of Internet Explorer ##

It appears Microsoft has a toolkit, or set of scripts and files to do just that! 😀

You can find the toolkits for each version here:

Internet Explorer 7.0
Internet Explorer 8.0
Internet Explorer 9.0
Internet Explorer 10.0
Internet Explorer 11.0

Basically each ‘Toolkit’, exists out of the following set of files:

  • IE##_Blocker.adm
    which holds the GPO template to regulate the exact same thing via GPO
  • IE##_Blocker.cmd
    which is an command line tool which writes specific values to the registry of the machine on which it is being executed
  • IE##_BlockerHelp.htm
    which is the help file where you may find usefull information on how to use this tool
figure 1.1: the containing files of the IE##_BlockerToolkit.exe


Now to prevent the installation of any unwanted version of Internet Explorer during your deployment process (when your machine is already running Windows and is connected to the internet, the polling for new updates starts right away). Just incorporate the IE##_Blocker.cmd as an application with source files into MDT.

figure 1.2: General application properties of the Microsoft Internet Explorer Blocker ##


figure 1.3: Detailed application properties of the Microsoft Internet Explorer Blocker ##


Basically all that needs to be specified in the command line is the following: cmd /c IE##_Blocker.cmd %OSDComputerName% /B

cmd /c makes sure, that a command line is executed, IE##_Blocker.cmd speaks for itself, and since the variable %OSDComputerName% is known for the length of the deployment it can be used instead of the real hostname, and the /B switch tells the CMD to make a registry key into the registry to block the automatic installation of Internet Explorer.

When the machine is finished, a simple verification if the tool has been executed correctly will suffice:

figure 1.4: Registry key written that blocks the automatic installation of Internet Explorer


As you can see for each version of Internet Explorer a DWORD “DoNotAllowIE##” will be written with a value of “1” under: HKLM:Software\Microsoft\Internet Explorer\Setup\##.#\

Alternatively you may choose to write this regkey yourself, automated via a script, command line etc. do it via GPO, or implement Windows Server Update Services.

Hope you find this blog usefull, and if there is anything that you would like to ask or contribute, as always don’t hesitate to leave something in the comment section. 🙂

Workshop – Migrating from Windows XP to Windows 7 or 8.1

Published / by Rens Hollanders / Leave a Comment

We all know (as good technicians) that the technical support for Windows XP is coming to its end at April 8th 2014. For some time now I have been writing about topics related to Operating System Deployment, Microsoft Deployment Toolkit and Windows 8.1. And as of June last year I’ve followed a didactic course to become an Microsoft Certified Trainer, because I believe that sharing my knowledge, passion and enthusiasm for the work that I do, and the products I work with, could inspire others to do the same.

To put this into reality, my employer has enabled me to develop a two day workshop about migrating from Windows XP to another operating system platform, which can be either Windows 7 or Windows 8.1. The focus of this workshop lies on migrating from an existing operating system to a new one, -but that isn’t entirely necessary-. If you are interested in working with the Microsoft Deployment Toolkit this workshop also applies to you!

The topics that will be discussed within these two days are the following:

  • Concept of Operating System Deployment
  • Installing and configuring a Microsoft Deployment Toolkit environment
  • Migration scenarios
  • First steps in creating and building a reference image
  • Driver management
  • Userdata
  • Troubleshooting
  • Licenses

Requirements for this training:

  • A laptop capable of running Hyper-V and two virtual machines
  • Windows 8.1 Enterprise

Who may attend:

  • Basically everyone who wants to learn something about Operating System Deployment, but the focus lies mostly on IT Pro’s, System or Infrastructure Engineers

Where will this workshop be held:

  • On my employers head office, located in Wijnandsrade, the Netherlands.
  • Possible this workshop will be recorded and made publicly afterwards.

Unfortunately, international followers cannot attend this course at this moment. But in case you could not wait or you prefer to have more detailed information, please do not hesitate to contact me. 

More information:

If you are interested in participating in this two-day workshop, please visit the following link: http://t.co/2SAa2kx6PT

Thanks for reading! 🙂