Would be useful if you could create branching task sequences. Take for example you have a different build for a physical and virtual machines, however you have a common WIM base and a number of general tasks applicable to both. Rather than creating duplicate different steps for each type based on queries why not allow complete branching of a task sequences into two distinct paths. While this can be achieved with Child Sequences to some extent, being able to visualize the full build flow without having to create multiple nested task sequences is good from a simplicity post of view. Drag and Drop technology would also be useful here.

Running a step as a user prevents you from using the TSEnvironment in order to store any data returned.

The step could be anything, like getting a byte array of a certificate, ad-groups of the computer or primary user or as in this example, getting the TPM OwnerAuth from MBAM.

I would rather store it directly in the TSEnv instead of in a temporary file and run another script to read the file just to be able to use the password, as a variable, from a “Run commandline”-step.

The only other workaround I’ve found this far is running the step the normal way and supply the credentials in the command line or within the script it executes.
Storing a pw, even if encrypted, in a package which every user has default access to isn’t optimal and using a password, in clear text, in a run command line step has security impacts as well.

Suggestion: Add the possibility to store the output/data returned from a "run command line"-step as a task sequence variable, even if runasuser is chosen. (see pic)

When scheduling offline updates to OS images, make sure SCCM install the Servicing Stack Update before the Cumulative Update (or allow the users to determine which update has to be installed first).

For example, I had an issue when trying to install SSU KB4498947 and CU KB4494440. SCCM tried to apply the CU before its prerequisite SSU, resulting in the CU being absent from the image.

And the worst thing is that I cannot create another schedule for this CU as it is now missing from the list of available updates. As if SCCM permanently consider this CU as non applicable for this image.

We currently have possibility to create our custom UI-s using scripts. Would be great to have a possibility to choose, if you want to use native progress UI, or create custom one in TS properties for example. So every time native Progress UI would be shown, it would show custom UI instead. Current way to use custom scripts has a small drawback: to start it, you have to use task sequence step. Which means, if some step restarts computer(not task sequence restart steps), you have to wait until next step, until you can start your own custom UI again.

We had this scenario, a restart was made during one TS step and after that there was black screen, until the step, which restarted computer was finished. It was Install Updates builtin step, which made that restart, can't really control that restart either. Can of course make default progress UI visible, but that means, that there are times, when there are two different windows on screen, which show the same information.

Using custom UI currently using TS steps also means, that after every planned TS restart you have to manually start your UI. Which currently means our 80 step TS has 18 steps related to custom UI (variables, hide/show the native progress UI, run actual script etc), thats almost 1/4. Would be great to create your own UI for the task sequence and let task sequence manager control the UI.

PXE-Enabled DPs currently pass their Management Point List on to PXE Clients, as reflected in the "ManagementPoints" list in HKLM\SOFTWARE\Microsoft\SMS\DP; this seems to be an alphabetical list of MPs in the infrastructure which may not reflect the actual MP(s) the PXE client should communicate with.
On the PXE-Enabled DP, in HKLM\OSFTWARE\Microsoft\CCM, the AllowedMPs registry value can be created and populated. The PXE Responder will honor this list when setting up the PXE Client's environment.

A field should be added to the PXE settings of a DP to allow configuring of this setting, or to override the site's MP List that gets written to the MP and instead replace it with the administrator's defined list of MPs relevant for the given PXE-Enabled DP.

When you deploy an OSD TS as Available, you are prompted to "Press ENTER for network boot service." If you do not press enter it instead boots to the OS (if any). This does not occur when using a required deployment. It would be useful to bypass this for available deployments.

This behavior is documented by Microsoft.

https://docs.microsoft.com/en-us/sccm/osd/deploy-use/use-pxe-to-deploy-windows-over-the-network#BKMK_Deploy

There is a previous UV that mentions this from 2017, but it was declined. The reasoning does not pan out for me, though. It does not appear to be a hardware issue as it occurs on both physical and virtual workstations. It also only occurs on available deployments. It also does not occur when using WDS along with something like MDT on the same workstations.

https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/17778895-ability-to-skip-press-enter-for-uefi-wds-pxe-deplo

I think it is about time that we had the ability to use Powershell to query and set conditions within the task sequence. I.E. we currently use WMI queries to check bios versions to decide whether or not to upgrade the bios version similar to this …
"SELECT * FROM Win32_BIOS WHERE SMBIOSBIOSVersion < "1.9.3""
the problem with this is this is a string value so with POSh you could easily convert that to an integer and then use that as your condition.
What I would like to see is something similar to the new edit script interface in 1902 but for conditions as well.