what would be great to see is a mechanism which would allow for the deployment of drivers to client computers post the OSD. ideally it would be fantastic if it can use the same driver package as is used in the OS Deployment to save the administrative overhead needing to have 2 different ways to deploy updated drivers like we need to today where we package the drivers for OS deployment, while to deploy to the existing hardware we need to depend upon the vendors installation package which in some cases don't allow silent installation so requires a large amount of effort to deploy.

It would be nice to have the ability to conditionally pre-cache all packages in Upgrade TS and not only OS Upgrade step.

To describe it in more details, in current design we are able to pre-cache only OS Upgrade step to computers based on conditions. This is not enough for companies with 20+ languages as best approach is to create en-us core image and then apply MUI on top of that. Doing this will cause system to report as e.g. de-de so we would need to download and distribute to 150+ DPs all supported Upgrade packages instead of distributing only en-us Upgrade package and them distribute much smaller MUIs.

As SCCM is currently supporting conditional pre-download in OS upgrade step so the function is already there, extending it to whole Upgrade TS will be a great benefit as we can then also put there e.g. Driver packs => so client will download only applicable driver pack, en-us Upgrade and appropriate MUI from one larger Upgrade TS. Right now we have to have 50 different Upgrade TSs to be able to support all languages in our company.

In SCCM 2007 we utilized package with multiple programs. One install program that was silent to be used in a task sequence. One with interaction (appdeploy toolkit e.g.) for distribution to existing PCs. Once we moved to application we created multiple deployment methods with the appropiate filters. However if one of the deployment methods does contain the 'allow interact' option the application can not be added to a task sequence even though there are deployment methods that would apply to a OSD situation were it would pick the non-interactive one. Would like to see a logic check in the task sequence editor or the option to force a specific deployment method(s).

Please make an easy way to query Driver Versions of all drivers on a system from SCCM Hardware inventory without creating a custom MOF or looking at registry files? I found a forum thread on TechNet a few years old that said Microsoft said that using WMI class win32_pnpsigneddriver was unreliable and is why it was not available in SCCM hardware inventory and they were considering removing the class entirely. However the class remains in win 10 and is still the only way to query driver version using a script. It would be really useful to be able to have SCCM compare driver versions on a system verses the drivers in a sccm driver pack so we can ensure systems are compliant.

Please create a function to enable task sequence versioning. This feature would be very helpful for reverting back to a previous task sequence as well as accountability for the last user that modified the task sequence.

We write a lot of WMI queries as well as set various task sequence variables. These settings change over time and it would be a great feature to look back on a previous version to view the changes as well as the last user modification.

We currently make copies of our task sequences for this archival purpose. This process works for us now, but we would definitely benefit if this feature existed.

Thank You,
Harry Caskey

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

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.