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
@d4rkcell Microsoft have previously explained this, although I unfortunately can't find the article to link to :(
Basically, UserVoice is a platform for requesting features, not tracking development or logging bugs. Once a feature has reached preview status and is available for people to try out, the assumption is there is no longer a need to track user enthusiasm for the feature, so they Complete the request in UV primarily to give people their votes back to reuse on other feature requests.
As the last comment specifically says "As always we appreciate any and all feedback, try it out and let us know what you think" I would say this is the appropriate place to make comments. Alternatively, you could see if this is open as a bug on Connect.
"I'm sure there is. It is still in the Pre-Release phase."
if that's the case then why is this item flagged as completed? It seems to me like it is in a targeted release stage, what we want is a broad release. Would an "Update References" button that forces all parent and child task sequence references to be re-evaluated and corrected if a change is detected not be a good option? Should we create a new suggestion to fix this or post on this suggestion?
Adam Fletcher commented
“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)”
One of the best use cases that I have found for this new feature is to create a single TS that has software common to all departments and reference it from each department OSD TS. This saves me updating lots of different department TS’s with the same change if new software needs to be added to or removed from, TS deployment.
I have found that the parent TS references don't always update when new packages are added to the child TS and never update when packages are removed from the child TS. Whilst editing the parent TS and clicking apply will force a refresh of the parent references as described above by djam, I am struggling to see the point of this feature in its current state. If I still have to edit all parent TS's to ensure their references update, I might just as well not bother with the chain in the first place and instead just add all software directly to the parent TS like we always have done in the past. This would be very disappointing as I have been hoping to see this feature for many years as it could be a big time saver.
Will MS be fixing this issue so that updates to the child TS will always reflect in the parent without the need to edit them as well? If so do we have any idea of time scale for this? I would very much like to adopt this new feature as I migrate my production platform from 2012R2 to 1710 during 2018.
Adam Juelich commented
I'm sure there is. It is still in the Pre-Release phase.
"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)"
Are there any plans to fix this?
@Dan Isaksson Nice; 14 votes already. I'm afraid I'm all out of votes at the moment, otherwise I'd add.
@Richard Archer. I created it as an idea here: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/32956096-check-referenced-packages-of-child-task-sequence-o
@Dan Isaksson Ah, I wasn't aware of the pre-cache feature. It does looks like it only applies to Operating System upgrades though. I think the pre-cache evaluation part actually makes use of the architecture and language settings on the Data Source of the upgrade package. The WMI Query is still just evaluated at run time to determine whether to run the step.
I'd speculate that if you didn't correctly match your package settings to your WMI query, you'd end up either pre-caching content you don't need, or failing to pre-cache content that you do need. Although having said that, the User Experience section of that page contradicts my speculation, so maybe I'm wrong. It happens ;)
Agreed, it's not clear if that applies to applications, but my interpretation is that is doesn't.
Good point about the UDI wizard package - we actually don't use the UDI wizard for our frontend and this is one of the reasons!
@Richard Archer this was the pre cache feature i am talking about. It is pretty new. I am not sure if it is only supposed to work on a upgrade TS step or on all steps. https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-a-task-sequence-to-upgrade-an-operating-system
Regarding the package i was thinking about when you use the UDI wizard to make it possible to select addition application. If you use that solution you need to update the UDI wizard package all the time.
Thanks for your feedback.
@Dan Isaksson I'm not sure what you mean by pre cache functionality? If you mean saving the XML on the target machine at the beginning... as far as I'm aware, it just saves the whole XML with all the branch logic and conditional steps stored in there. Evaluation of each condition still happens AS the step runs, not at the beginning of the TS. Even WMI queries can have dynamic results. The engine would have to make a decision about whether the WMI query looks like the results are fixed (like a hardware model number) or variable (like disk space) which seems a little unpredictable. I can't see that working for most cases.
I'm also not sure what you mean by needing a list of applications that is updated as a package? You have your applications, you have a step that sets the variable list and a step that installs the applications from that list. To change the list of applications, you update the variable list setting step. No need to update DPs. You could still do this in a child TS if you want to be able to be able to run them standalone, post-build.
All that said, your point about running actions before and after individual application installs is true. Dynamic installations prevent that (and, to be honest, is actually a challenge for some of our installs). The only way you're going to resolve that is with the suggestion you made - to have a "Check references" tick box on the Run Task Sequence action. Not a bad idea so you should probably create a new Idea for that right here in User Voice :)
@Richard Archer isnt the pre cache functionality of TS already doing this? I understand using TS variable populated by script would not work in this way but WMI query should work. It can be evaluated in a "dry run".
Another way of doing this would have a tick box called something like "check references" on the TS step.
The nice thing about having the roles in TS is that you can run things before and after each step, or have options on the steps. Also it is easy to run the roles after a computer is deployed.
The issue with having the dynamic variable is that you need a list of applications that is updated as a package. In other words you need to update a DP each time. This would not be needed with using TS for roles.
@Dan, I'm not sure that would be feasible as conditions are evaluated as the action is about to run, whereas content availability is evaluated at the very beginning of the task sequence. There's no way the TS can know, at the very beginning, what groups and actions it might take based on conditions.
Even if they changed the way the content check works (perhaps do a dry-run of the TS to work out which actions will actually be executed) how do you handle more dynamic conditions?
We, for example, have groups and actions that might be skipped based on variable set by choices made in a frontend interface - there's no way to that can be evaluated in advance.
One option you have would be to use dynamic installations. This would be similar to the MDT approach you're currently taking, where the TS installs apps based on a dynamic variable list, but rather than using MDT roles to populate that variable list, you could use a Set Dynamic Variables action. That type of action would allow you to move all your logic out of the MDT DB into a single TS action.
I have just tried this functionality and it is great but i would like to be able to control if the parent TS checks if the child ts packages are available on local DP. I would like to use this to run country specific applications in separate TS instead of using MDT roles. As this works now it will check that all packages/applications are available on local DP even though i set option on step with task sequence variable or wmi query that will cause a specific child ts to not run. This would mean i need to have all packages available on all DPs.
Joe Friedel commented
Thanks. I did create a bug on Connect this morning. I agree that this is related to, but not exactly the same as the item mentioned by djam. I just want to make sure the Apply Driver Package steps don't get overlooked, especially since the comment from Bob Mac Neill below indicates that adding applications or packages to the child are detected by the parent. This is an example of an addition to a child that is not detected by the parent.
Can't edit comments so I've had to delete my old comment and retype it. I realised I misread the two issues and incorrectly conflated them.
@Joe Friedel This seems related to the known issue djam mentions above ["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)"] but isn't quite the same so it could be a differnet issue.
Bugs are logged and tracked through MS Connect: https://connect.microsoft.com/ConfigurationManagervnext
Joe Friedel commented
What is the best way to report bugs regarding this feature?
I have a child task sequence for OSD driver deployment. I recently added a new step with a new driver package. The computer running the task sequence picked up the additional step but was unable to find the package on any DP. Looking at the references tab for the parent task sequence, the new driver package was not shown until I opened it for editing and made a change to allow me to click Apply. Based on the previous comment, adding applications or packages to a child task sequence should be detected by the parent, but in this case, the step was detected without the content.
Hi. Is this a pre-release feature in CB 1710? Or is it officially production. Reason I am asking is that in the setup wizard for CB1710 it lists as pre-release, yet in the official documentation for CB1710 there is no mention of it being pre-release
Roth, Chase commented
This is great news. We like most have a few task sequences with a good part of the sections, like drivers or applications, that are the same between them. This lessens the administrative burden when updating something that would have to be updated multiple places.
Russell Garrett-Martin commented
I would just like to say thank you very much for taking the time to add this feature. I feel enormously proud to see it added to the latest version :) So thank you
RE: "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)"
Does this mean if a Child Task has a package/application changed/added/deleted, the Parent Task must be re-created?
If Applications or Packages are added the change is detected.
If any are deleted they are not detected. You do not have to re-create the Parent, just make an edit e.g. update a description field and then save. That action will pick up the changes made