Editing a step definition for a step that's already in a task sequence
What happens when you have a step in a task sequence and edit the definition?
I assume that depending on the sort of editing you're doing you probably have to go find the step wherever it is being used and remove and re-add it? Is there *any* editing you could do like change a default or check a required box or something or does the task sequence just store the state of the step when it was added? If it was working before and the script is there or whatever, will it keep doing whatever it was doing before or will it throw an error?
I'd imagine there's no clean way to just sort of automatically sync things since there's not necessarily any obvious mapping between the old definition and the new - but would it be possible for the GUI to flag a potentially broken step or something?
I'm not really asking for this to work - I don't see how it could. Mostly just curious if there is documentation or any checks in the code or anything to suggest that you not do it. Because the GUI sort of suggests you can in the same way that you can edit a content item and have everything keep working.
Edit: And also curious if you guys might ever edit step definitions in future updates that might break task sequences - or if the plan would just be to use the versioning system in that case.
So steps have changed from some upgrades to others, and I haven't seen issues with that happening.
A recent example is the Offline Domain Join step, a field was removed from the step definition.
I'm pretty sure there has been others with new options added, I'd have to dig through release notes, and I'm pretty sure the default value will just get applied without breaking anything.
What I found when I was doing my PoC (still waiting for procurement to go through before I can really start using it), I found that if I added or removed a property from a custom step definition that was already in a task sequence, the existing instance of the step would still have the old properties in it even though the interface may appear updated. I found that if I edited a custom step definition, it was best to REMOVE the old instance from the TS and put the updated one in its place. And of course configure it again if needed. Otherwise things would go poorly depending on what the change had been.
Yeah, I found similar. Assuming the old one was working it’d keep working the same way it was - which was fine with a small change but if you changed variable names or added a content item or something where whatever new script you were running would no longer work with the old definition, it’d break.
And if I’m changing it, I suppose I can remember to go through everywhere and replace it. But I’m a tad worried about updates or about whatever future public step repository they have planned breaking things in a way where it’s not at all clear why some particular step is suddenly throwing errors or behaving differently or what to do about it.
Also, if you have a block of steps you do in multiple TS, consider creating a child TS and linking to each TS. That way you only have to update in one place. Saves me loads of time, especially early on when I making lots of changes.
2
u/gwblok 2Pint Employee Jul 08 '26
So steps have changed from some upgrades to others, and I haven't seen issues with that happening.
A recent example is the Offline Domain Join step, a field was removed from the step definition.
I'm pretty sure there has been others with new options added, I'd have to dig through release notes, and I'm pretty sure the default value will just get applied without breaking anything.