Designing dynamic OSD environments and task sequences

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.

Multiple task sequences, why not?

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.

MDT

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.

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?

Scripts

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.

Collection Variables

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.

Front-Ends

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.

Images

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.

Drivers

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.

Applications/Packages

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.

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.

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?

7 thoughts on “Designing dynamic OSD environments and task sequences”

Dean

Hi, Thanks for the post.

I have extensive knowledge building OSD task sequence and a few years ago we at Dimension Data built a solution that has some interesting task sequence flow management. Have a look at this, old but interesting, blog post of mine. http://www.labcontrol.blogspot.com.au/2008/07/advanced-task-sequencing.html I developed a process of creating linked task sequences that are compiled into new task sequences allowing other teams to manage their own sequences. I also built a version control process and other items such as cross-computer task sequence sync events. Check it out.

This eventually did make it to a full blown application and integration suite for SCCM. It stated on 2007 and was later ported to 2012. Unfortunately it remained a customer only tool despite my requests to open it up and make it available to the general populace. Anyway, I love designing task sequences and your post is great. I know if many new SCCM admins who don’t have the foggiest idea where to start.

Great Post! I’m guilty of having 2 task sequences for separate environments yet same OS.

I feel that the MDT UDI wizard front end is not appreciated/utilized enough. I find that it is a really clean solution that is easily customizable being able to add custom pages and an amazing pre-flight page.
They have been making it easier to use with each version, can’t wait for the next.

The UDI wizard is a nice addition, that I agree is underutilized. For us though, it doesn’t quite do everything we need, and I am not learning c# to code new pages and functionality. All PowerShell for me!

The c# pages are very hard to implement, they suck. Ended up with Microsoft helping us on one of them. Really hoping that it will be improved before we need any more custom pages for Looking up information. Simple pages to set variables with tick boxes, drop downs etc are easy.