System Center Configuration Manager Feedback

How can we improve Configuration Manager?

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.

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

This item is now planned for future release – we’ll update later which Tech Preview this feature will be available in.

RE: Ben – we have an open Doc. item for clarifying non-OSD task sequence use. I’ve added your comments to that item – thanks for passing them on

RE: David Stein – agreed – that’s something we want to avoid. After prototyping one of the first things we did was list all potential issues like this and create a test case for each – 50+ from that exercise and growing.

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.

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.

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.

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

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.

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.

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.

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.