Monthly Archives: November 2014

MDT – Versioning made easy (powershell = king)

Published / by Rens Hollanders / Leave a Comment

The great thing I like about doing projects with customers, is that each and every customer has it’s own challenges. And I think it is safe to say, that challenges brings out the best of all of us IT Pro’s.

In this particular post, I want to talk about the Microsoft Deployment Toolkit, versioning mechanism: ..MDT has no versioning mechanism 🙁

Wouldn’t it be nice to just have an option to duplicate a task sequence, like MDT’s big brother Microsoft System Center Configuration Manager?

Well that day has come my friends 🙂

Currently I’m working on reverse engineering a Citrix XenApp 6.5 environment which needs to be rebuild from the ground up with MDT. And after it has been built, it needs to be managed, improved, extended further when necessary.

Now it is perfectly possible to duplicate task sequences manually. Just create a new task sequence with the wizard within MDT, and copy the ts.xml and optionally the unattend.xml from your control\<tsid> folder to the new control\<newtsid> folder, and voilá your task sequence is duplicated. But wouldn’t it be nice to do this automatically?

Depending on the tools that are present in any particular organization, since MDT is free, and tools such as RES Automation Manager and System Center Config. Mgr. cost money (..and particularly Config. Mgr. costs lots of it too) I wanted to create a solution for having some kind of versioning system in MDT.

Since I’m getting more and more familiarized with PowerShell, I can kick in the open door by saying what we all know: PowerShell is truly King. Although I do not poses all the knowledge, luckily I have multiple colleagues who are willing to help me at any given time. This time I would like to thank Pascal Zeptner, for spending his free time with me 😀

Now before we are going to talk about the script, it is imperative that your Task Sequence ID is built up out of the following naming convention:

  • OSB001
  • OSD002

I maintain this convention at all of my MDT implementations. The abbreviation OSB stands for “Operating System Build“, while OSD stands for “Operating System Deployment“. The essential difference between the two is, that the first one is used for creating reference images for target machines. While the second is used for deploying the reference image that is created, to target machines.

And to have a complete MDT environment with an orderly created folder structure in less then 20 seconds, please visit this blog: MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Behold the script:


First of all, the script checks for elevation, if you do not run this script elevated it will not execute:

Secondly, the script needs certain variables made clear to work with. In this case the following static variables:

After these variables are filled in. The script will import the MDT PowerShell module, located at the default location where MDT normally is installed. If you have installed MDT elsewhere, you will receive notice that the MDT module was not found and the script will terminate.

Next, a new PowerShell drive will be created, so we can browse the MDT virtual folder structure:

After this, the real stuff begins: In the following lines of code, the properties of a task sequence will be queried. This happens with the “Out-Gridview” cmdlet, since this presents a nice selection dialog, to select the desired task sequence which we want to duplicate.

From this selected task sequence, we query it’s ID, and increase the number on the ID with +1 to create the new Task Sequence ID.

The same thing goes for the Task Sequence Version, which is also queried, and increased with +1. As soon as the version of the task sequence hits .9, it will increase the master version from 1.0 to 2.0.

Lastly the name of the task sequence is queried, and assuming we use a specific naming convention for our task sequences, which uses “v1.0” at the end. The last three characters are removed and replaced with the $NewTSVersion variable. This causes our newly created task sequence, to receive a name with the increased version number too!

Now all the information we need to know to duplicate our task sequence is known, we can actually create a new task sequence and copy the contents from our reference task sequence to the new task sequence:

As you can see, there are some checks built-in that verify if the new to be created task sequence does not already exist on physical folder level.

Now to underline all this, screenshots:

figure 1.1: Select designated task sequence for duplication


figure 1.2: Task Sequence duplicated


figure 1.3: Press F5 to refresh and see the new task sequence


figure 1.4: Perform duplication at v .9


figure 1.5: Version 2.0 created


figure 1.6: Press F5 to refresh and see the new task sequences


figure 1.7: *.xml files are copied from destination task sequence to new task sequence


..and that my padawan automaters, is how the cookie crumbles.

Comments, questions, improvements? Please let me know in the comment section. It’s as always much appreciated.

The script and images used in this blog can be downloaded here:


Cheers! -Rens