Microsoft

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.

1,176 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    JerryJerry shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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

    34 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • DominikDominik commented  ·   ·  Flag as inappropriate

        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.

      • Daniel BoothDaniel Booth commented  ·   ·  Flag as inappropriate

        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.

      • JensJens commented  ·   ·  Flag as inappropriate

        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.

      • d4rkcelld4rkcell commented  ·   ·  Flag as inappropriate

        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.

      • Roth, ChaseRoth, Chase commented  ·   ·  Flag as inappropriate

        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.

      • Matt BlountMatt Blount commented  ·   ·  Flag as inappropriate

        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!

      • MarkMark commented  ·   ·  Flag as inappropriate

        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 CooperStephen Cooper commented  ·   ·  Flag as inappropriate

        hi sangeev, do you have any more information about which build this feature will become available in?

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 SteinDavid Stein commented  ·   ·  Flag as inappropriate

        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, ChaseRoth, Chase commented  ·   ·  Flag as inappropriate

        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?

      • dorobertdorobert commented  ·   ·  Flag as inappropriate

        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.....

      • HoustonAUHoustonAU commented  ·   ·  Flag as inappropriate

        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 MymrykJames Mymryk commented  ·   ·  Flag as inappropriate

        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.

      • BenBen commented  ·   ·  Flag as inappropriate

        Hi Sangeev,

        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.

      • SimonSimon commented  ·   ·  Flag as inappropriate

        Awesome. I can't tell you how many creative ways we're using to get around the lack of this feature ^^

      ← Previous 1

      Feedback and Knowledge Base