Add an optional option to provide new source location path for each package, application, ... when importing a Task Sequence that has been exported with content and references. Imagine you have 2 ConfigMgr environment a Test and a Production environment completely isolated from each other and you want an easy way to sync. A cool thing would be to only export "Metadata" of the Task Sequence and all References (Applications, Packages, ...). At the target site you have the same folder structure for content source for example \sccmsources\share\Applications,\sccmsources\share\Packages, ... and so on. If you start the import, you will be asked the same way like now for location. The wizard will detect that the folder structure is identical and ask if you want to use it or otherwise change it manually for each reference if needed. Currently the only option is to import everything and change the folder structure in a scripted way, which causes all references to regenerate Hash code, adding a new revision which can be avoided easily.

It would be really helpful to have the possibility to generate a Status Message with a custom Message ID from within a tasksequence. Maybe as a seperate step, maybe as an checkmark under the "Options" tab.

This message ID could be used to trigger a Status Filter Rule more granular to improve overall Status Filter Rule performance.

Example: A company with 20k Clients deploys Operating Systems and Software via task sequences, the result ist that there are hundreds of thousands of 11171 events. When we are able to set a Message ID 65000 in the OSD Task Aequence, we are able to trigger OSD TS actions only on real OSD task sequences and not on all of them.

Scenario: You create a Boot Media or Prestaged Media. Current behaviour is that as long as the boot image version from creation date matches the version inside the infrastructure everything is fine. System is starting Windows PE and executes the Task Sequence. If you add for example a new driver now to the boot image the new version causes Configuration Manager to download the boot image inside Windows PE and another restart into the updated version of the boot image. In case of a Prestaged Media scenario this painful, as UEFI systems might no longer work.

Possible SOLUTION: Add a variable SMSTSPreventRedownloadBootImage and SMSTSBootImageMinumVersion to stich with the boot image currently used.

Purpose of SMSTSBootImageMinumVersion (enforce only if present and boot image ID matches Boot Image ID used in Task Sequence) would be to have still version control.
I think this would enable additional deployment options

It would be really useful if the SMSTSPreferredAdvertID feature would work without every CM Client (known or unknown) needing to have the policy for the hidden deployment. This is usually set using a front end menu by a technician or end user driven deployment. If there are multiple task sequence deployments that need to be available, this could result in a large amount of unnecessary policies. The other option is to have a webservice drop a system in a collection prior to kicking off the task sequence engine, however this has drawl backs and can result in a delay in kicking off the job.

It would be nice if the SMSTSPreferredAdvertID worked like the (dynamic) Install Application step ("Allow this application to be installed from the Install Application task sequence action without being deployed") or the (dynamic) install Package step ("Allow this program to be installed from the Install Package task sequence without being deployed") so that systems can just run a task sequence deployment without having a direct deployment. This will speed up the OSD process, minimize the number of unnecessary policies and allow a user to pick a task sequence (via a predefined menu) and go.

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