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
Stephen Cooper commented
hi sangeev, do you have any more information about which build this feature will become available in?
Teppo Vanhatalo commented
This would be great feature. We have multiple task sequences (shared platform) and would like to use one TS for just drivers and link to it from actual OSD TS. Would be much simplier than editing 10+ OSD TS with latest drivers if you could only update one which is called from others.
David Stein commented
This could create some potential issues if controls aren't implemented to limit loops and nesting beyond a certain level. Imagine calling a TS from 3 levels down that refers back to a 1st level TS. Hyper-V nesting comes to mind.
dorobert, not sure about you're concern that client needs to be in the configmgr console. could you expand on that thought and specify how you see it being used? I didn't think client would need to be in configmgr console.
He is how I understand this to be used, I have for example maybe all my core programs that get installed on a task sequence that is separate from the main TS I launch. Then the main TS can call the other TS like a function to install all the core applications. This allows the core applications to be called in multiple TS's and only need to be edited in one place when an application change comes along.
How do you foresee it this being utilized differently?
With the BIOS to UEFI changes for Windows 10 that a lot of organizations are making. This becomes more and more necessary. I would believe the challenge here is a newly imaged system may not be in the console as ConfigMgr is still processing the client.....
Would also love to see this to break shared TS components out. We support 7, 8 and 10 and all three TS' get the same application installation steps in the TS, when I need to update those steps I have to update all of the TS' manually.
Would love to be able to break that out and simply update the one component TS.
James Mymryk commented
Keeping how this should work may be like application or CI's where daisy chained is called and a specific version or newer term is available. That way there is control for the scripts relying on another TS and are able to use the correct version.
to implement this feature will irritate the admins regarding the NON OSD strategy in my eyes. Currently we only have the statement that only "basic use" for non OSD TS is supported which mean in my eyes all and nothing (same for my customers). And now you plan to improve the TS functionality which by the way is a good thing from the technical point of view, but not for the application deployment point of view. Would be nice if we get clearer statements regarding the support level of using Non-OSD TS.
Awesome. I can't tell you how many creative ways we're using to get around the lack of this feature ^^
Stephen Cooper commented
The ability to define dependancies or call one task sequence from another would be amazing
Vegard Søbstad Alsli commented
Banhi you better not be trolling.
Would make our duplicated Tasks easier!
@Roth... Trust me on this
@Banhi, don't get my hopes up!
Will be available in a couple of months... Bits already in 1511...
This was one of the first things I wanted when I started using SCCM 2007. I have since started using some variables to allow most things to occur in one task sequence, but being able to insert groups and pieces of the tasks would be huge. Just like calling the same function in multiple scripts this would simplify administration and make it MUCH MUCH easier to follow then using variables. Having to change tabs to figure out which variables and where is something being used is a very long task sequence can be quite complex. This can help simplify that annoyance.
It sounds to me that users do not necessarily require the ability to daisy chain multiple task sequences, but what they require is the ability to re-use existing short sequences.
To this avail, perhaps being able to select certain task sequences/sections of task sequnces as templates for reuse via the Add button at the top of a TS?
This would be a vast improvement over the all too common process of: Open second TS, copy and paste into the open one (which causes a crash after cutting and pasting or dragging and dropping too many times).
Nathan McNulty commented
I currently have to use MDT integration with an Orchestrator runbook to pull this off, so something like this would be a welcome change. While it would be nice to be able to call one TS from another TS, the nesting could get quite complicated (similar to nesting collections in ConfigMgr 2007 allowed).
I like the concept and idea, but this definitely needs a lot of thought on how to implement. Another option would simply be to provide a nice PowerShell cmdlet to directly call task sequences that would be part of WinPE. Being able to run a task sequence and pass variables into it (that would tie into ts variables) via PowerShell would be awesome.
Jay Connor commented
Modular task sequence groups would be nice.
Brandon Penglase commented
Nested tasks would be awesome... would really help to reduce duplication between sequences.