System Center Configuration Manager Feedback

Ideas

What features would you like to see?

All of the feedback that you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building System Center Configuration Manager, though we can’t promise to reply to all posts.

Standard Disclaimer – our lawyers made us put this here ;-) Please note that the System Center Configuration Manager feedback site is moderated and is a voluntary participation-based project. Please do not send any novel or patentable ideas, copyrighted materials, samples or demos which you do not want to grant a license to Microsoft. See the “User Voice Terms of Service” link below for more information.

How can we improve Configuration Manager?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Tell us your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

This is a buggy, Would we like the option to have ' Uninstall Application when Resource falls out of scope of this collection' when an application is deployed to a collection, this would save us having to create 2 collections ( install and uninstall) and to deployments. This would save SO much time and reduce the complicity of application management.

It would be nice to have the ability to adjust window sizes within the console. As an example, the Membership rule window in the collection properties only has enough room to show 2 lines. Being able to maximize or edit to a custom size and have the console remember these sizes would be great.

This could be incorporated into the fixes that are being introduced with the High DPI resolutions.

Doing this everywhere in the console would be expensive/difficult. Rather than wait to make any improvement until the time we can fix it all… I’m curious what the top 10 most important places to fix are. I’m thinking we fix those first, and then go from there.

Today it's only possible to orchestrate software updating based on a membership in collections.
This is however rarely enough for more complex setups where you might have back-, middle-, and front tiers in your setup.

Therefore I recommend adding a dependency system between computer objects, so that you can orchestrate at least the following:
1) Which tier of servers are patched first, second and third etc.
2) Reboot order between the different tiers which includes an accept of one tier being fully patched and rebooted before the next tier is begun updating.
3) Ability to choose between warning or rollback if a single server fails updating - however this should be possible to decide based on each tier. (you often care more that a database server is identical than a webfrontend).

Today it's only possible to orchestrate software updating based on a membership in collections.
This is however rarely enough for more complex setups where you might have back-, middle-, and front tiers in your setup.

Therefore I recommend adding a dependency system between computer objects, so that you can orchestrate at least the following:
1) Which tier of servers are patched first, second and third etc.
2) Reboot order between the different tiers which includes an accept of one tier being fully patched and rebooted before the next tier is begun updating.
3) Ability to choose between warning or rollback…

Trying to keep track of which topics in the Documentation Library have been changed and when is a nightmare.

Provide a notification mechanism such as a RSS feed for updates to the Documentation Library as they occur.

In an ideal world it would be great to be told WHAT the changes were (be good if there was a way of easily snapshotting the article before and after the changes with the changes highlighted), but not sure how easy that is.

With CM Current Branch implementations, customers will have more questions than ever about whether their clients are being upgraded to the proper version. There are ways to get at this data in the CM console, but sometimes there are gaps (hotfixes come to mind) and it would be great to have an authoritative resource to point customers to. This site (https://blogs.technet.microsoft.com/configmgrdogs/2014/02/07/configmgr-2012-version-numbers/) is great but it seems to be maintained by a field engineer. I think it would be more practical to make this data available on Technet or docs.microsoft.com. Also if it could have site version, build, and client version (with/without hotfixes) it would be a big help.

With CM Current Branch implementations, customers will have more questions than ever about whether their clients are being upgraded to the proper version. There are ways to get at this data in the CM console, but sometimes there are gaps (hotfixes come to mind) and it would be great to have an authoritative resource to point customers to. This site (https://blogs.technet.microsoft.com/configmgrdogs/2014/02/07/configmgr-2012-version-numbers/) is great but it seems to be maintained by a field engineer. I think it would be more practical to make this data available on Technet or docs.microsoft.com. Also if it could have site version, build, and…