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.

Problem:
• Current state of windows 10 servicing via upgrade sequence requires full media to take the client through setup.
o Full media is 2x the size of existing ESD (upgrade content)
o The Upgrade Operating System step does not allow the end user to defer the reboot nor does it warn the user of a reboot pending once setup has been kicked off

Change Request (Requirements)
I. The Upgrade Operating System step in the task sequence shall permit the administrator to reference windows 10 servicing content
II. The Upgrade Operating System step in the task sequence shall permit the administrator to define a notification to the end user
III. The Upgrade Operating System step in the task sequence shall permit the administrator to define if the user can defer the system reboot and for how long

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).

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 the interest in making my OS deployment task sequences as fast and as optimized as possible, I always optimize WIM files anytime they're updated or re-created.

In my build/capture task sequence, I add a step at the very end before capture to run DISM /StartComponentCleanup /ResetBase so that all of the superseded updates are removed from the base image before it is captured. This results in a smaller WIM file and obviously, faster deployment times.

With the built-in Offline Servicing option for OS images, once new updates are added, they remain in the component store of the image when the image is unmounted, and also, all of the deleted/superseded files still remain inside the [DELETED] folder in the root of the WIM database because the image is not exported once it is updated by Configuration Manager so the WIM file continues to grow larger and larger every time it is updated using Offline Servicing.

Presently, I have a script I've created, 'Optimize-WIMFile.ps1', that I run against the WIM file source after it is updated via Offline Servicing that does the following:
- Mounts the specified OS WIM
- Runs 'DISM /Image:Mount /StartComponentCleanup /ResetBase' if
the image supports it (i.e. OS version greater than Windows 7)
- Unmounts the WIM
- Exports the WIM file to remove all deleted or replaced data using
DISM module's Export-WindowsImage

Since Offline Servicing is already mounting the WIM for you on the server when updating it, there should be an option (a simple checkbox would suffice) to "Remove superseded updates" after the image is updated that essentially runs DISM /ResetBase against the WIM while it is still mounted before unmounting it.

After the WIM is updated and unmounted, it should then be exported to clean up the removed data - I'm not sure why this is not already a default. The WIM file will only grow in size with all of the old deleted junk every time you update it if it is not exported. You could even make an option for this as well with a drop-down menu that lets you choose the compression level on the WIM when exporting to the final image.

I've tried to automate this process completely by making a script that triggers the OfflineServicing schedule on all of my OS images in Configuration Manager and then calls my Optimize-WIMFile script, but the problem is that I can't find any way to track status of the offline servicing on each image to know when it's safe to begin optimizing the WIM, as Get-CMOperatingSystemImageUpdateSchedule is not returning anything when the schedule is created to run immediately so I have to wait for all of the servicing to complete, and then manually run the optimizations.

This would make sooo much more sense to have built-in to the OfflineServicing since it's literally two simple commands run against the WIM. Please take it into consideration!

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.

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.