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.
Updating status to started. The ability to call another task sequence from a task sequence is added in 1704 Tech Preview – see here https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1704 for more details
Please note this is an early release and there’s some limitations. We wanted to show you all our work in progress and gather some feedback such as nesting depth.
Currently a task sequence with any package references in child steps won’t resolve content when run in the full OS – we’ve a ton of work to do with policy to solve that. Good news is that the scenario will work when launched from WinPE (PXE/Media). Also, nesting will work in the full OS for any steps that don’t require content e.g. Run Command Line, Set Task Sequence Variable (variables are global to all steps!), Connect to UNC etc.
Import/Export doesn’t traverse all child task sequences
We block selecting the parent task sequence for one level only
Some actions like Distribute Content won’t see all references, same with the view
We’re really excited about this feature and appreciate any and all feedback
I really was hoping this feature comes with 1706, but its not even included as a pre release feature. Maintaining several task sequences is such a pain right now. Can someone please update the status of that? Thanks.
Not included in SCCM 1706 Upgrade :(, why?
Daniel Booth commented
Please make this happen asap, its the single most important feature that's missing, it would solve a lot of issues and time consuming tasks.
Please could someone from the team update on this. I have waited so long for this. Even if the update is that it is not happening.
I would love to be able to create a task sequence that simple has "install application steps in it. This TS could be called "Standard appset" and this would be in all our task sequences (we have a lot of different builds - its a university!). We wouldnt need to modify 30 task sequences to change the standard appset we just change the one ts which is referenced in all the others.
Any update on this?
Roth, Chase commented
Yes, but not everyone is integrating MDT and using that as it adds configuration that has to be done outside of SCCM. Including it in SCCM directly is the way to go. You can still use the other, but for those that don't use MDT it will still be available.
Sub Task Sequence can be done pretty easily in MDT with a little custom code:
Matt Blount commented
Having to update multiple task sequences for multiple domains when the join domain account credentials change is time consuming.
Would be good to create 'Join Domain Accounts' in SCCM and allow the domain join stages to reference these credentials in all task sequences - update credentials in one place!
This is a must have. Nesting TS's would be the best thing forward. But I would also like to see a dynamic task sequence step that can call up a Driver package, app package or nested TS from an established TS variable. Some dynamics around winpe x86 vs x64, Legacy vs UEFI, as well as pre OSD ts steps such as BIOS flash updates, vendor bios config tools and better zero touch management for clearing and re-enabling TPM and taking ownership for bitlocker activation. PE 1607 is giving us nightmares with this stuff at the moment
Stephen Cooper commented
hi sangeev, do you have any more information about which build this feature will become available in?
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.
Roth, Chase commented
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