Freigeben über

Splitting Task Sequences To Make Life Easier #1

  • Artikel

I don't know about you but it frustrates me that, to test certain parts of a task sequence, I have to run the entire task sequence from the very beginning, formatting the drive and installing the WIM image.  This can be a process that can take an hour just to reach the point I want to test, causing a lot of delays.  To help reduce this frustration I wrote the MDT Debugger (https://blogs.technet.com/b/deploymentguys/archive/2010/03/22/mdt-debugger.aspx) which works a treat but sometimes is not the right tool for the job.  What I'd really like to be able to do is jump straight to a specific point in a task sequence and run it from there.  Well, you can... (sort of) !

This is the first of two posts offering similar solutions to this frustration!  The concept for the idea explained in this post is actually very simple: break the task sequence down into smaller ones, each dealing with a specific phase of the deployment.  By doing this, it becomes unnecessary to run all the previous tasks that you know work in order to get to the ones you want to debug.  For example, below you can see a typical task sequence, this task sequence contains two main phases: the WinPE, disk partitioning and image install phase, and then the State Restore phase that is run inside your deployed OS (Windows 7 x64 I hope...).  It is in this later phase where most of your custom tasks and changes often go, and the one that usually needs debugging. 

 

In the below screenshot, you can see that I've created a completely blank Custom Task Sequence in MDT, and then used the new(ish) Copy/Paste feature in MDT 2010 to copy the tasks I want to debug over into my new custom task sequence, leaving me with only these  pasted tasks in the sequence.

 

Now, I can just run this new and reduced custom task sequence (by launching LiteTouch.vbs from the deployment share) as many times as I like without having to reinstall the Windows image each time, saving me plenty of time in my debugging process.  Once I am happy with the tasks in the custom task sequence and have everything working, I just delete the initial tasks from the original task sequence and Copy/Paste the debugged ones from my custom one back into it!

You'll need to include the "Gather" task as one of the first tasks in your custom sequence, and you will likely need to add various "Set Task Sequence Variable" tasks in order to give MDT any missing information it was expecting.  Examples of this could be where captured user data has been stored or perhaps the name of the WDS server you are using, but this all depends on what you are trying to do.  Also, you shouldn't split the task sequence just anywhere because of dependencies between the tasks that could just end up making things worse.  I recommend that you copy and paste tasks that appear within the State Restore group to your custom task sequence rather than anywhere before it as a starting point otherwise things might never work...

 

This great solution actually comes from some friends in Barcelona, Spain, so I can't confess to inventing it myself.  Moltes gràcies to Andres Villalobos Bernal and Vicenc Rovira Torrens for sharing this with me and changing my deployment labs with it!  Fellow Deployment Guy Ben Hunter blogged something along the lines of this some time ago for testing application installs (https://blogs.technet.com/b/benhunter/archive/2007/05/14/update-how-to-manually-use-a-bdd-task-sequence-to-test-application-installation.aspx) but it had never occured to me to completely split task sequences using the Copy/Paste feature to aid with debugging!

 

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

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

Comments

  • Anonymous
    January 01, 2003
    In a previous post , I described the first of two methods on how to drastically reduce the time (and

  • Anonymous
    January 01, 2003
    In a previous post , I described the first of two methods on how to drastically reduce the time (and

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Great post over on The Deployment Guys by Daniel Oxley. Read the full post here. This post was contributed

  • Anonymous
    February 09, 2011
    Hi, thank you for the post. -Villalobos