What is the issue?
Something I see fairly often is poor design of task sequences in an OSD environment. Do you need multiple task sequences for different driver sets? No. Do you need multiple task sequences for different application installs? No. Do you need different task sequences for different OS images? No.
This is not to say all problems can be solved with a single task sequence, but many technicians make their lives harder by having multiple task sequences. They could simply make a few steps more dynamic and save some headaches down the road.
It is understandable why it happens so often. Make a copy of your TS and add your new items, and you are done. This is great until it comes time to make a change across all your task sequences. You now have more than a few, sometimes dozens of task sequences to update. There is also no easily automated method to modify task sequence steps, but it has been requested. I have been there, it gets old pretty quick. You lose standardization, control, and each new task sequence is a new point of failure. You also need more time to update every task sequence, depending on the change you are performing. As an example, making a change across an environment of 30+ task sequences can take anywhere from 10 minutes to 2 hours, even using the quick copy and paste method. If you use the tools available, many of which are free, you can have a very dynamic OSD environment with as little as one task sequence.
How do you make it dynamic?
Having a successful dynamic OSD environment means leveraging the power of the task sequence, some back-end technologies, and some other automation methods such as MDT, PowerShell or System Center Orchestrator.
A lot of these topics have already been covered, so expect many links to external resources, no need to reinvent the wheel here.
If you are using ConfigMgr, the first thing you need is the Microsoft Deployment Toolkit. This toolkit allows you to dynamically control task sequence variables, utilize CustomSettings.ini with or without a backend database, leverage PowerShell and Orchestrator, and about 300+ more features. This is a must have.
Task sequence step conditions
Every step in a task sequence can have conditions set to evaluate if the step should be ran or not. This is the first item in making a dynamic task sequence because you can control which steps run and which do not based on machine information such as WMI, registry, or files and folders. You can also control steps based on task sequence variables or groups! The groups can even have conditions set.
TS Variables – TechNet: http://technet.microsoft.com/en-us/library/gg682064.aspx
TS Variables – Hayes Jupe: http://www.hayesjupe.com/sccm-osd-task-sequence-variables-a-beginners-guide
Populating Task Sequence Variables
Besides the example above using a task sequence step, you have many more options to populating task sequence variables. Some you may need to control before deployment, others you may need to be dynamic during the deployment or perhaps input via a prompt by the user?
Vbscript or PowerShell can do a lot of the work for you if the information you need is on the machine you are deploying. Query WMI, query an external resource, or anything else you need for your scenario. All you need to do is interact with the Microsoft.SMS.TSEnvironment COM object.
Sometimes you need to pre-populate the variables for a machine. One method to do this is to specify a collection variable on the collection you are deploying to. Your local technicians in a specific office may need special software installed or a custom configuration for the machine. You can use collection variables as a simple way to let the technicians drop devices into a collection to get the proper settings.
Benoit Lecours over at the SystemCenterDudes has a perfect post explaining this scenario, Collection variables to build dynamic Task Sequence.
In some scenarios you don’t know what settings are needed for the machine you are building, but your technician or user does! You need to prompt them for input to make sure the Windows deployment does exactly what they need. In this case you want a front-end.
The most basic of the front-ends is the User-Driven Installation (UDI) wizard which comes with MDT. This built-in wizard allows you to prompt for OS to install, domain join information, applications to install, and much more. Damon Johns has a very thorough post about it, Integrating UDI into your SCCM OSD Task Sequences. There are a handful of walkthrough videos on TechNet as well.
There are a lot of great front-ends that IT Pros have written over the years, far too many to actually name here. The best resource I have found to find them is the OS deployment section of the ConfigMgr 2012 Tools wiki page on TechNet. Google doesn’t do a bad job either. These custom solutions can either run as pre-start commands on your boot image or as steps in your task sequence, it all depends on your scenario and needs.
Using the methods listed above you can easily pre-populate or prompt for the proper OS image to install. Just add a new step or use CustomSettings.ini to apply the proper OS image.
Thanks to Dustin Hedges for the image.
Driver management in your task sequence is fairly straightforward, and most engineers use generally the same method to dynamically install drivers. It is simple, have a condition to query WMI for the machine type/model and apply the proper driver package. Johan Arwidmark has some nice examples in his post in step 4 as well as in an older post here.
If you want to further control your driver groups by hardware model, you can leverage CustomSettings.ini with MDT. Instead of having one step in your task sequence for each hardware model, you have all your hardware models listed in the .ini. Andrew Barnes has a good example here, and TechNet has a blog post with an example here.
The most common reason I see multiple task sequences being used is for application customization. This build needs software A, B, and C, but this build needs software C, D, and E, et cetera. These customizations can be populated from many of the methods listed above such as the MDT database, web services, Orchestrator, or more simple methods like populating from a front-end or collection variable.
The simplest method is using the build in Install Package or Install Application step with a dynamic variable list. This is a single step that lets you populate a variable list with the apps you need to install. See below for two examples.
David O’Brien – Application Base variables the easy way with PowerShell
If you need something a little more robust and powerful, you can utilize the MDT database or a web service. The power here lies in these external resources to do the heavy lifting for you.
Jarvis Davis has a great post for using the MDT database, Dynamic OSD using the MDT Database.
For a full length, no detail left out, set of instructions check out Jase T. Wolfe’s walkthrough, Automate “UDA Application” Installations During OSD.
A notable front-end with some unique capabilities is Jason Sandys’ UI++. It can do a lot more than dynamic application installs, but if you need something to prompt for apps/packages to install, you need to give it a look.
There are also some very unique solutions like Peter van der Woude’s solution and Nikolaj Andersen’s solution to install computer targeted applications during OSD using PowerShell. The possibilities are endless!
Paul Winstanley has a companion post to Peter’s with packages included! Great work!
Use your resources!
The best part about working with ConfigMgr and OSD is the abundance of resources from the community. There are multiple forums available to post in, email lists with thousands of subscribers, endless blogs such as mine, and community sites such as myITforum. Most of what you may need to build something dynamic and automated is available online, and if not, I’ll bet my bottom dollar it won’t be long before it is.
What other solutions have you found to help make your Windows deployments dynamic and automated?