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).

image 

  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