Daisy chain Task Sequences (OSD and non-OSD)
I would like to see the ability to launch one task sequence from within another task sequence. For some processes, you run the same steps across multiple deployments. Today, you have to duplicate these steps across many task sequences. The ability to execute a task sequence from a task sequence would alleviate this need and reduce errors and inconsistencies for administrators.
This features is included in #ConfigMgr 1710 release.
The notes for the 1711 Tech Preview apply here too and we’ll continue to work on these
Console actions are fixed in many instances where we didn’t traverse the referenced packages/content
Export now exports child task sequence and referenced content – secrets are cleared from the referenced task sequences too
Task Sequence import now works and detects duplicates
Copy action copies parent and all reference to child task sequences
Delete action detects if there’s a parent child relationship and displays what’s affected
Similarly deleting packages that are in child task sequences is detected and shown in the delete package wizard
Initially we had limited to one level – now there’s no limit, but use that wisely
Related to the above, we do not permit a circular reference i.e. a parent cannot reference same parent, a parent cannot reference a child that references same parent – we traverse the entire chain
Create Prestage Content is updated to work for task sequences with multiple child references
Deployment Verification now detects when the child contains the ‘high-impact’ steps
Standalone media creation detects and adds all task sequence and content references and completes end-to-end
Things to note
We do not permit selecting a task sequence with a Boot Image reference, for any deployment that requires a boot image that reference has to be on the parent
Any chain containing a disabled task sequence will fail – the continue on error won’t work for that step
Criteria for popping the ‘high-impact’ warning are not detected in Software Center when the child contains the ‘high-impact’ steps, in this case our recommendation is to use the Task Sequence User Notification properties to force the ‘high-impact’ warning
If a child task sequence has a package reference removed the parent does not detect this. To workaround, make any edit to the parent (anything that activates Apply)
As always we appreciate any and all feedback, try it out and let us know what you think
Al Raymond commented
Our environment is currently very distributed, in that we have a lot of different folks working independently on the same site. Something like this -- maybe not daisy chained task sequence but groups that are external to a TS and referenced so any change to the group is reflected in every TS that uses -- would make sharing steps between groups a lot more user friendly.
give us the option to build a set of tasksequenceitems in a group, that you can link to any tasksequence. If you Change an item of this set, it should be changed in every tasksequence.
actually if you have many tasksequences you have to configure/update each when you build a new driverpackage, change standardsoftware and so on which belong to all of the tasksequences. this is costly and a big source of error if you forget just one (and a waste of time for the troubleshooting)
Robby Moeyaert commented
I second this.
Would also make OSD easier. You could split the "install and get Windows going" off from the task sequence that installs your software.
Drew Kirkman commented
A good example of this would be the steps for installing driver packages. When we begin purchasing a new model of computer, I have to add a step for that machine to all my OSD task sequences. If I could create one TS just for drivers and include that in all the others, it would save me a lot of time.