Keeping it Real… (And Simple)
When we use task sequences in ConfigMgr it is generally to deploy operating systems. You can however use a task sequence to install more complex applications that require more configuration. This process gives us lots of power, especially when you tie in with MDT. Don’t forget though, keep it simple and keep it real!
As a consultant you always want to leave your customer with a fully working solution that you can leave with a set of documentation in order for them to operate their deployments without the need to contact you further and wait for you to get back to them. The same can be said for fulltime employees, what if you leave? What if you move jobs? The point here is the more complex things are the harder they are to understand.
I Still Don’t Follow
Take this example, you need a set of information to produce a task sequence due to network or environment differences over sites or even countries. You could easily combine all this information into one task sequence and use variables and conditions on actions to be able to decide which actions will run based on the value of a variable.
We apply the same logic for driver packages in operating system deployment when we apply driver packages for certain models to different models of hardware. However take this with all our location information and times that by 5 models of hardware and 5 locations, we can have a large amount of information per location, say 10 variables or actions. That means we have at least 50 items in our task sequence just for location specific settings.
What Can We Do?
The easiest thing to do is just sit back, look at your task sequence and ask yourself, “is this sequence too big?” If the answer is yes then see how you can break it down into multiple sequences. Maybe one sequence per location which will make it both easier to understand what is happening and reduces the complexity of the sequence making failure less likely.
From experience, we can make task sequences very very complex, but why bother? This just makes things more likely to go wrong. You can deliver the same solution by splitting the sequence, this makes more sense from an administrative overhead angle. The only thing to take away here is really just to think, do I need to be this complex, can I make better use of the built-in tools available to me?