Day 5, we are getting there, 4 tips that totally blew your mind, so we're going to slow down a bit from the completely custom tips and talk about nested task sequences, child task sequences, task sequence modules, whatever you want to call it.
As of 1910, it's a standard feature and enabled by default, before this, you had to enable it in the feature area. If you never knew about it or enabled it before now, if you're updating to 1910, then you're all set. More info about the Run Task Sequence Step on the Docs Site. The Feature has been around since 1710, so we've had two years of this marvelous feature.
Why do I need this? What are some ways I can leverage this? Let me tell you.
Real world examples.. Debug Task Sequence. I've got a Small Task Sequence I use for Debugging, gathering variables, dumping variables, pausing the TS, grabbing logs. I can run it standalone, or run it inside another Task Sequence.
How I leverage them, for 1709, 1809, 1909, I have an upgrade TS, now they all share about 90% of the same steps, so using child task sequences allows me to share that 90%, and if I need to make a fix, it fixes it on all three. I then create a unique sub task sequence for each build to do anything unique that needs to be done.
Basically at the end of the day, it comes down to what works for you. Do you have to use them? No. Can they be hugely helpful, Yes. Can it add extra complexity and confusion, oh yeah!
So how does it work? Behind the scenes, ConfigMgr integrates the sub task sequences into the parent task sequence, and in policy looks like one giant task sequence. When you look through the SMSTS.log, each sub task sequence is represented as a group.
So today's tip, Run Task Sequence Step, it's one of my favorite features that has come about in the past couple years, opening up new ways to organize and think about how you build task sequences. To learn more about the available steps and what they do, check out the MS Docs. See you next time for another Task Sequence Tip.
See more tips: