When creating Automatic Deployment rules, it would be useful to be able to configure multiple deployments.

You may for example want test, pilot and live deployments to different collections and possibly with different settings. It doesn't make sense to have to create different rules with the same updates criteria just for additional deployments.

The CM administrator may choose to have the additional deployments disabled to allow for testing, but enabling a deployment leaves less room for error, and is less administrative overhead than creating these additional deployments manually each time for pilot/live.

It would also be useful to have the option to set deployments as available rather than required too (as far as I remember you can't do this from an ADR).

It's quite frustrating to spend time logging bugs with ConfigMgr through Connect only to have bug submissions either incorrectly closed (i.e. closed as a duplicate but also closing the referenced bug - will it ever get looked at if all active bugs are closed!?) or being closed as fixed but not adding any information as to what the fix is or when the fix will be released.

Myself and colleagues spend the time and effort documenting these bugs with your products on behalf of customers so the very least that could be done in return is to let us know what is happening with them and ensure that this is communicated back to the person raising the bug.

Today, you can be running a console with one version, that is not in synch with what is running on the primary. The only way you'll know is if you are missing features added to a newer release or if troubleshooting leads you down that route. You have to check the about page in the console to verify version number and compare that against what is installed on the Primary site server to see if they match, what I'm proposing is an easy visual way in the console to inform you when your versions don't match, and to offer the ability to upgrade via a simple click,.

to repro:
Install Configuration Manager 2012 R2 CU3 on the primary, and on a computer that has the Configuration Manager 2012 R2 console installed, connect, you will not be informed of the version difference and will never know it was different unless you went and actively looked for the difference.

I use a LOT of PowerShell ... and the PowerShell modules in SCCM are ... well... bad.

Issue 1: I should not have to set my running location to a site to run a cmdlet. No one uses a set-location to make sure they are in the AD domain root before running a get-ADUser (unless they have a multi-domain environment and need to call something specifically), yet SCCM requires this to be true. It makes scripting needlessly complex.

Issue 2: there are a pointlessly large number of cmdlets. Do I really need a Get-CMDeviceCollection and a separate Get-CMUserCollection? Why can't I simply use "Get-CMCollection" with a -type switch that defaults to device? Once again: needless complexity when it comes to scripting because of this.

Issue 3: we need more cmdlets in general. There are good number cmdlets that have a "Get" without a corresponding "Set". That should just be a big NO NO, and I should reasonably expect to be able to set anything I get.

Improve App-V deployments to non-persistent VDI's. Currently if you App-V applications to users in non-persistent VDI environments, there is a long delay after the user logs on before the applications install.

If this could be changed so that applications are published significantly faster after a user logs in that would enable the use of SCCM to deploy applications to non-persistent environments. Currently this process is far too slow as users have to wait too long to get their applications.

This was meant to be addressed in SCCM 2012 R2 SP1 however I logged a call with Microsoft and they said this had now been removed from the SP1 release notes, pending further testing internally at Microsoft. I certainly haven't seen any improvements after installing the service pack.