Back to basics #2 – 7 Things you shouldn’t do in a LiteTouch Deployment


The below list is a list of the most common mistakes made when creating a LiteTouch task sequence.  While not an exhaustive list, it might help to improve your deployment experience when using MDT to create LiteTouch deployments.

1.)  Hard-code paths to files/scripts in the task sequence, or inside a script, or referring to the distribution point as Z:\

I would say that this is the number one cause of errors that I see.  Because MDT always maps the distribution point to Z:, most assume that it is safe to use this to refer to a file during the deployment process.  99% of the time they are right and it will work fine.  However, there are some scenarios when this will generate a failure but it might not be immediately obvious as to why it has failed.  So, the solution is to not use Z:\ when specifying paths to files.  In the example in the below image, the variable %SCRIPTROOT% instead of Z:.  MDT will make sure that the value of this variable will always be to the distribution share, regardless of where it is.

image image

The most common scenario that I have seen this fail in, is when using a Media Deployment Point where the drive Z: does not exist, causing any custom script/processes to fail.

2.)  Use non-descriptive names for each task or script, and not fill in the comments field for each task in the task sequencer.

When adding tasks to the task sequencer a lot of people skip the Description box, and also often give the task a rather ambiguous name (plenty of times I have actually seen the task left with the default name i.e. “Run Command Line”).  This is not such a problem if it is you that will always administer the server, but when the day comes that someone else needs to look at the task sequence, it will be nigh on impossible for them to work out quickly what each task is doing.  So, what could be a simple quick fix will turn into something much longer because they will need to go through the sequencer to work out which is the task that they are looking for.

You can save a lot of work for everyone, including yourself, by filling in Description field for each task you add to the sequencer.  You can also later on use the content of this field to help with your documentation.

3.)  Use an account for connecting to the deployment share that has full administrative access over the server.

Often, during the development stage of any deployment, most people use the administrator account of the domain in the laboratory, or the local administrator account of the MDT server, as the user that connects to the deployment share during any deployment.  Although this works fine, from a security perspective it is pretty terrible, especially as you will often have to share the account credentials with anyone that wants to deploy a machine.  If you are using an administrative account in the laboratory, make sure that this practice does not get passed into the production environment at a later stage.

The ideal option is to create an account group (either local to the server or in the domain) that has access to the share, and then add the necessary users to this group.  That way they can use their own account credential for deploying a computer without compromising any security on the server.  You can also use the auditing options on the server if you want to find out the who, what and when for any computer that was deployed.

4.)  Create a LiteTouch task sequence that deploys a computer without any user intervention.

Although this might sound like a great idea as it provides an almost ZeroTouch deployment method, it is actually quite a bad thing to implement.  Imagine that you launch a deployment on a computer, no user input is required so the task sequence launches.  Just as the drives start to format themselves, you realise that you launched the deployment on the wrong computer.  Doh!

I have to confess that this has caught me out before, because of the use of several computers all connected to a keyboard/mouse/monitor switch box.  Consequently, I like to leave at least one user-required action at the start of any task sequence and before any ‘damage’ is done.  Even if it is just a simple “Welcome to the Windows Vista Deployment project – Press OK to continue” message.

5.) Don’t specify the scripting engine when launching a script file.

As you can see in the image below, MDT will launch a custom VBS script during a deployment cycle, the problem with this example is that the scripting engine has not been specified for launching this script.  So, by default, Windows will launch the script with WScript.exe rather than CScript.exe.  Most of the time this will be fine and give no problems, however, if you have a script that has the command WScript.echo “My message” in it somewhere then the script will pause, showing a window to the user, and it won’t continue until the user presses the OK button.

You may want this behaviour, i.e. introducing a user intervention at some point in the deployment, but if you don’t then just specify CScript.exe on the command line before the script file (as shown in the images at the top of this post).


  6.)  Don’t bother creating detailed documentation of the whole process.

Although this won’t break anything, and although it is an extremely dull task, documenting everything that you have done during the creation of your deployment is invaluable.  It will save you, and anyone else, a lot of time in the future when you need to make changes to anything on the server.

7.)  Create a media deployment point, and then test the super massive 8Gb ISO image with Virtual PC.

Although Virtual PC now has support for large ISO files, it still sometimes has a few ‘issues’ when the files are super big.  The issue never manifests itself with the same error message twice though.  Instead, you might start seeing problems booting from the ISO file, and then the next time you might get an inexplicable failure in a script.  The solution I have always found to work is to simply use the same ISO file with Virtual Server 2005 SP1, or better still, Hyper-V.

Without a doubt, there are plenty more do’s and don’t with MDT.  This is simply a consequence of the fact that MDT is so customisable, a sure sign that it is a powerful tool.  Feel free to comment on this post with any of your own suggestions that you want to share with everyone else!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Comments (7)

  1. Ben Hunter says:


    This is a default partition that is created by Windows 7 and Windows 2008 R2. It is so that you can have space to enable BitLocker at a later time.

    To disable funjctionality this you can add the following line to the customsettings.ini file:




  2. Anonymous says:

    Thanks all y’all – for the whole thing.  I have learned more useful and applicable information from this one blog than from all the docs and other TechNet articles on MDT combined.  Go get yourselves a pay raise!

  3. Atolica says:

    Hi Ben

    I looked over ztidiskpart.wsf script and found two lines that run the "clean" command. If I delete those two lines, as I don’t want my disks wiped out, the install breaks.

    I don’t see any advantages in using the script for what I need. I’ll stick to diskpart.exe /s diskpart.txt.

    Thank you.


  4. Atolica says:

    Hi Ben

    I wrote you in another post about a sysprep error. Can you tell me what’s wrong?

    "Windows could not finish configuring the system. To attempt to resume configuration restart computer".

    That comes up after I run sysprep /generalize /quiet /oobe, and restart the pc in oobe mode.

    I’m running sysprep manually because it won’t run automatically from the task sequence(after installing applications). The process stops entirely.

    Thank you.



  5. AD says:

    I would like to use The BBD Database to prestage my pc and then have the build read the information the dadabase, to check assettag serialnumber, Build Ou, Image version and last think ig it is allowed to build or not. I know it is possible but how do i get it to work.. please help.



  6. Atolica says:

    Hi guys

    sorry to write my problem here but I can’t find an old thread

    I am trying to build a master image using MDT beta 2

    I "successfully" wiped an entire drive using diskpart.wsf diskpart.txt routine.

    my diskpart.txt should’ve just formatthe first partition on disk 0 and not wipe it clean.

    diskpart.txt looks like this

    select disk 0

    select partition 1

    format fs=ntfs

    assign letter=c


    Instead the disk was cleaned and two partitons were created, one OSdisk and one 300 mb in size. What is wrong here?

    Also the applications sequence task didn’t run at all. I don’t think the sysprep / generalize ran at all because the installation stopped with the Administrator account logged on.

    I am going nuts.


  7. Roy says:

    In section three you don’t mention anything about sorting out access to the MDT database.

    I’ve just started to use SQL2008 Express and I noticed it installs one less group than 2005 Express installed.  The group that is missing was the group I added users to to enable access to the DB.  What’s the easiest way of allowing a group/user read access to the MDT DB?

Skip to main content