At the moment it is not easy to add requirements to an application deploymenttype with PowerShell. I think many of us would benefit if this would be simplified.

Now that we have the option to define both Distribution Points and Management Points as preferred, it'd be terrific if we could have the same option for Software Update Points. It would make a strong case when designing a flat hierarchy.

Currently Administrators have the ability to set Role Based Access to Collections but we do not have the ability to block access to specific folders. Currently in my environment we have many different departmental administrators who need to manage only their machines and their collections. each time we add collections we then need to grant them access. if the Role Based Administration gave the ability to grant access on the folder level it would reduce the complexity for area's that have a setup similar to mine.

I have attached a screenshot of how my setup looks.

Ability to change an approval requests that has already been approved to denied.

We would like to see a single web portal, preferably HTML-based, to marry the Software Center and Application Catalog. We deploy both types of offerings, and a single place for users to get new software would be great.

Currently if we add a new machine to sccm, and the OEM was lazy and reused a UUID builds won't start, and there seems to be no easy way aside from standalone build media to get around this.
since we have to provide a uuid and mac address when we create new machines, why is it not smart enough to use the mac with the generic uuid to identify the correct machine?

Add a retry count and delay between retry properties to at least the most critical task sequence steps, if not all, so that we can make task sequences more resilient when there are hiccups to servers or network.

Would be nice if the application approval request feature had built-in support for emailing.

Allow the groups in a Task Sequence to be collapsed allowing a better overall view.

The reboot settings only allow for the user to postpone a reboot for up to 24 hours. Why can't we expand that time or just keep reminding them forever until they reboot themselves? The longer that they have been pending a reboot, remind (pester) them more frequently. Or auto reboot if nobody is logged on.

Right now, if I need to run a PS script in a Task Sequence requires to use the Run Command Line item using PowerShell.exe. However, if I want to run a script with parameters, then I must use the -command option for PowerShell.exe, which has some odd parsing problems that can cause scripts to fail when run this way.

Many customers want to be able to force a reinstallation of an application. this deployment should ignore all detection rules and just install the application again.
At the moment this is not possible.

Everyone who knows WSUS misses the feature in ConfigMgr to allow the installation of software updates when the machine is shut down. This is being requested for a very long time now. For most businesses it's not the best approach to install updates only when a user is logged on. Of course the scenario changes with Windows 8 and 10, but it's still a valuable addition to the option a ConfigMgr admin should have.

The "More Details" right-click function in the Asset Details view under each monitored deployment currently does not allow you to highlight and copy any of the text. This might sometimes be handy while sending deployment information to colleagues or building hand-made lists of computers with a specific error status, etc.

It would be nice to be able to control the client cache size settings using the client settings policies. This way you have a simple way to increase it if you have a package which is larger than the initial deployed size.

At the minute have to completely restart the TS when a dependency is not found. Could we not introduce a retry option once the dependency issue is resolve. Similar to checking for installation pre-req's

better control weather I want a site to fallback to primary or not.
real bandwith limitation instead of current posibility. Control priority of metadata

How is this still a problem? Ask any MVP and they all agree: the built-in task sequence for patching during OSD doesn't work. It doesn't survive double reboots, it has a upper patch limit before it crashes ... it's basically garbage. I don't mind making golden images in MDT, but I shouldn't have to ... and yet I do. I makes SCCM feel less like a singular solution.