It would be great if you could specify a Git Repository and Branch as the source of the contents of the Scripts Folder. This would allow the approvals to be managed in GitHub with all the abilities around code review and testing.
It could still require an admin approval in the console which Version of the script should be used. It would also make rollbacks to an earlier version very easy.
If you allow having "folders" in the Script folder, each of them could be a repository. You still should need to approve which version to run, but MVPs could create these repo's that others could include into their environment.

When creating stand-alone media you have the option to select which Applications,Packages and driver packages it should include onto the media or not. After clicking next on the summary page the process of starting the media launches. in the createTSMedia.log you can see that at some point the process starts to compute volume layout. It seems that the compute of the volume layout does take into account the software you selected to not be on the media. Therefore you might get the message that you do not have enough space on the USBFD media altough this is not trough. At this point the only solution is to create a copy of your task sequence and remove all tasks with content that you do not need for this specific offline deployment. IT would be nice if the compute volume layout step respects the packages/applications you selected to not be on the media.

When parameters are provided on a 'Run Powershell Script' in a task sequence, the SMSTS.log only logs the name of the script. It does not log the full command (including parameters) that are invoked.

For example: if I call Java.ps1 with parameters -level 1 -language eng the SMSTS.log only shows...

Running powershell script: 'Java.ps1'(PkgID: SCM00000) with execution policy 'Bypass'

This would be helpful in troubleshooting what parameters were actually passed to the script that is executing. Otherwise you have to track down the task sequence and assume everything entered is passed and run. Or you have to build your PS1 to output(Write-host) those parameter inputs to force them into the SMSTS.log

The docs that exist for the CM Messaging (note, the messaging SDK is not a part of the larger CM SDK docs here https://msdn.microsoft.com/en-us/library/hh442686(v=cmsdk.16).aspx) is currently a .chm Help file, which is lovably nostalgic.

However it doesn't do justice to the power of the SDK. For instance, Discovery and hardware inventory are barely covered in the SDK docs. I'm troubleshooting an issue now with the Messaging SDK in which a fake CM Client appears with Windows 6.2 NT Workstation, even though it is a fully patched Win10 machine. Weird stuff.

Anyway, it would be great if the docs were not a .chm file, but redone in the lovely style we have here: https://msdn.microsoft.com/en-us/library/hh442686(v=cmsdk.16).aspx

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.

Creating SCCM Collection Queries is an art, and like most art, some of us are more suited to stick-figures while others produce beautiful creations worthy of a place in the Louvre, featuring graceful sub-queries, artful tabbing and good code practices.

When creating a collection, it would be helpful to have an optional 'Community Collection Catalogue' to choose from, which could have a user-voice style 'Most useful' collections list.

Users could create collections here, possibly even having a community 'wish-list' area for those without skills to request from those who would like to share.

Contributions in the community catalog could be counted for MVP or other recognition, possibly displaying badges. Gamification elements could be added, including Facebook or Twitter links to individual contributions.

Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.

This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

Large Applications: There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.