A new task sequence step was introduced in ConfigMgr 1710 that allows you to call one task sequence from another task sequence. This has been referred to as nested task sequences, parent-child task sequences, and several other names. This process creates a link to between the task sequences, and gives you the ability to create more modular task sequences. It also helps if you have a large number of task sequences that contain the same steps, such as driver packages, a common set of applications, or even the step that installs the ConfigMgr client. All of these can be broken out into child sequences, then reused across the rest of your sequences.
Considerations
There’s one item in particular that you need to watch out for. Any task sequence (the “child”) that is called by another sequence (the “parent”) cannot have a boot image assigned. If you assign a boot image, the task sequence will not show in the selection box for the “Run Task Sequence” step.
Next, the SMSTS.log will show when a child task sequence is executed, but the task sequence reports in your SQL Server Reporting Services instance will not. You should be able to find the entries in SMSTS.log pretty easily by searching for the name of your child sequence. The reports in your SSRS instance do not acknowledge the fact that a child sequence was called. The reports look like all of the steps were in one big sequence.
Adding the Child Sequence
Adding the child sequence to your parent sequence is straightforward. The step is under Add > General, then “Run Task Sequence”.
After adding the step, name it and select the child sequence using the “Browse” button.
In this step, I’m calling my child sequence that contains my common applications.
Child Sequence Use Cases
When do I use a child sequence? I use a child sequence pretty much whenever the same sequence of steps needs to be repeated across multiple task sequences. This can be common applications, as I demonstrated above, driver packages, etc. I even have my “Setup Windows and Configuration Manager” step as a child sequence. If I need to change the command that installs the ConfigMgr client, or the package, I only have one place to change it instead of in all of my task sequences.
Other examples of where a child sequence would be useful is driver packages. Adding all of your driver packages to one sequence and then calling it from other sequences would make your job a lot easier when you get that new model of computer that you have to support. Even the “Install Operating System” folder could be a child sequence if the base operating system, Windows settings, and network settings are the same across all of your sequences.
Here’s a screenshot of one of my parent task sequences:
Basically, a step that is not a device restart is in a child sequence. All of the lines starting with “TS -” call another sequence. I elected to keep restarts in the parent sequence so that I know exactly where they are in the process. I also elected to keep the standard task sequence folder structure, but that was only because that’s how I’m used to looking at it. There’s no technical reason to do so.
Using child sequences gives you the opportunity to lesson some of your management workload by offering you the ability to change commonly-used sets of steps across multiple sequences. I would encourage any ConfigMgr administrator to check it out.
Disclaimer
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.
