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 (http://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 (http://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
thank you for the post.
In a previous post , I described the first of two methods on how to drastically reduce the time (and
Often the simplest tips are the best ones, so here is one I have been using pretty much ever since I started working with MDT.
When working as part of a team in the same MDT environment, you can often run into issues when various people are modifying the task sequence, or debugging a process that is part of it. My own method to mitigate this issue is to fork the "official" task sequence, creating my own one, in order to separately realise testing or to simply try something out, before feeding changes back into the main task sequence.
The downside to this method is that, by forking the task sequence, the new forked one also appears in the list of task sequences and thus allows somebody to accidentally run it, possibly causing undesired results to their computer (such as formatting it!). Therefore, in order to prevent this situation, I always introduce some simple validation tasks into the task sequence, typically right at the start. These validation steps perform a simple query to check if a computer is "authorised" to run the task sequence or not. My authorisation method is usually based on the MAC address of the computer, but it really can be any value that you like.
The best thing about this tip is it's simplicity. As you can see in the screenshot below, it only consists of two tasks (the Gather task is actually only required if you have not already run a previous Gather task), and a Run Command Line task. You'll notice that the command line is incorrect. This is intentional and not an error, and if MDT attempts to run this command line it will fail the task sequence execution.
Here are the steps I use to implement this:
Create a new Task Sequence Group called "Authorised Computer Verification".
Add a Gather task (if necessary).
Add a Run Command Line task, with a command line like the one shown above.
On this same task, switch to the "Options" Tab. On this screen you can add your own personalised conditions, or use the same MAC address conditions that I have used, as shown below.
Notice that the condition is actually a negative . Consequently, when a computer runs the task sequence, this task will only execute if the MAC address of the computer does not match one that is in the list. And because the command line of the task is erroneous, MDT will fail at this point, thus preventing the unknown, or unauthorised, computer from continuing.
When working with MDT and Configuration Manager, you could restrict use of a task sequence by only advertising it to a collection built using direct membership. However, there might be situations where you can't or don't want to use this collection method. This tip works equally well in a ZTI environment if you wish to use it that way, however you might need to add an additional "Use Toolkit Package" task before the Gather step.
Finally, there are other methods to achieve the same result, such as using the CustomSettings.ini file; the reason I do it this way is because its implementation is so quick and simple.
This post was contributed by Daniel Oxley , a Senior Consultant with Microsoft Services UK
Great post over on The Deployment Guys by Daniel Oxley. Read the full post here. This post was contributed