System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

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.

Please do not use UserVoice to report product bugs or for assisted support.
If you believe you have found a product bug, please send us a bug report through the Configuration Manager Console (1806 and newer). To do this, press the 🙂 button in the top right corner and choose “Send a Frown”. For more details, see https://docs.microsoft.com/en-us/sccm/core/understand/find-help.

Standard Disclaimer – our lawyers made us put this here ;-)
We have partnered with UserVoice, a third-party service, so you can give us feedback. Please note that the System Center Configuration Manager feedback site is moderated and is a voluntary participation-based project. Please send only feature suggestions and ideas to improve Microsoft Configuration Manager. Do not send any novel or patentable ideas, copyrighted materials, samples or demos. Your use of the portal and your submission is subject to the UserVoice Terms of Service & Privacy Policy, including the license terms.

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.

The supersedence behavior is misleading and poorly documented. If you select the months to wait to expire an update and select 1, it is in effect the same result as immediately expiring any updates they are superdeded. The reality is that if you want to keep a patch for a month after it is superseded, you need this value to be 2.

With the new Cluster Aware patching in TP3, I would like to see dynamic variables that you can call into your pre and post scripts that would tell you which machines are currently getting patched, and which machines are currently up. This would allow admins to write a more simplistic script where it queries a variable instead of having to build a script that test connections and make sure its not installing software updates. Example scenario would be patching Hyper-V clusters, where you need to keep all VM's up and running. We could query the variable, to move the VMs to a host that is not currently getting patched, then move back the VMs to its original host post software updates.

With the new Cluster Aware patching in TP3, I would like to see dynamic variables that you can call into your pre and post scripts that would tell you which machines are currently getting patched, and which machines are currently up. This would allow admins to write a more simplistic script where it queries a variable instead of having to build a script that test connections and make sure its not installing software updates. Example scenario would be patching Hyper-V clusters, where you need to keep all VM's up and running. We could query the variable, to move the VMs…

Currently we have an available time and a deadline time, it would be great if we could also have a time where all the updates that could be downloaded to a client and then install all of the ones that it can until a reboot is needed, and then still wait until the deadline fore that reboot.

we give our users 2 weeks t o download and install, but even after communicating with them that installing will no force the reboot until the 2 weeks are up, the majority still insist on not installing until the deadline, and of course that means on the deadline date, all the machines on that local subnet are trying to update at the same time, with the common complaints.

Currently we have an available time and a deadline time, it would be great if we could also have a time where all the updates that could be downloaded to a client and then install all of the ones that it can until a reboot is needed, and then still wait until the deadline fore that reboot.

we give our users 2 weeks t o download and install, but even after communicating with them that installing will no force the reboot until the 2 weeks are up, the majority still insist on not installing until the deadline, and of course…

I think the title says it all:
During the last months 5 (!) WUA updates came down, and AFAIK at NONE of the KBs it was written what had been changed!
So at least for the customer one cannot react porperly in case of issues.

The Deployment Scheduling "Software available time" is a one-time setting. Any newly imaged workstations built after that time will receive software update packages at any time during the business day. Unlike Collection maintenance windows, which only apply to the execution time for the software packages, there is no way (that I know of) currently to control the time of the download of the packages.

Either/or
1) Provide a daily "Software available time" start time
2) Tie the software available time to a Collection's maintenance window
3) Define a maintenance window for "Software available for downloading".

today if you select the option to allow the client to download the content from a DP, it can go to Microsoft. This is great, but I would like to have an option to allow this to happen only after x number of hours or maybe x number of retries, allowing the DP to get the content (in case of a admin forgot to add this to the DP, maybe slow link and need to copy content manually)

Sometimes, a software update needs to be copied or moved from one deployment package to another. This is especially useful for keeping deployment packages smaller and more efficient when using Automatic Deployment Rules (ADR). Currently, updates always need to be re-downloaded from the internet or a source location. This is inefficient and can be time consuming as well.

ADRs currently appear to only fire from the primary site server. Unfortunately our primary doesn't have internet access and guess what? The ADR fails to download updates. I can't be the only one in this position. I would suggest a future release (or update) should include an option to specify a server from which the ADR should fire from (in our case and probably most cases, the SUP server).

ADR - Limit Package Size:
within the automatic deployment configuration enable an option to limit the size of the package and when reached create a new package automatically. the screnn should be able to provide a pattern for the packagename

It would be nice to be able to group a couple of Software Update Groups together and Deploy as a single Deployment, have had a couple of clients wanting Software Update Groups per Operating System and Office Application, however on the Reporting the want to see a single Deployment for Compliancy.

Since day and night we are having issues with the winsxs folder and larger and larger drives. Using SCCM it caches the windows updates but also windows is saving new and older updates in the winsxs folder. I can understeand it is needed for uninstall etc. All physical and virtual servers can then save a lot of drive space and more important we don't need to pro active expant drivers or even have crashed machines after the tuesday update round.

Have the statistics (Required, Installed, % Complete, etc) for updates displayed in the All Software Updates search results respect the current security scope of the user.

If you have an environment with 1500 servers and the current user is assigned a scope that limits their management to 75 servers; make the search results relevant to the user by showing statistics for only those 75 servers so they can use this view to assign updates directly to SUGs without having to use the web reports to identify applicable updates to their server environment.

Provide a means to do a pre-check for pending reboots
Notify owners of server/workstation of update cycle
Set a reboot order for collection so the server/workstation is booted in a predefined order
Run a post patch validation after patching
Give the ability to run a "script" to validate install applications are operating correctly.

With a standalone WSUS-Server deployed Windows Updates can be uninstalled/removed from clients. With SCCM SUP this is not possible,
Implement a function to remove installed Windows Updates from clients.

When doing a search in Software Updates, when filtering the search it would be excellent if one of the filter criteria were the ability to filter by the OS of the Client needing an update. I'm NOT speaking of the free text search of the OS'es the patch applies to, but rather the ability to look at the OS of the machines that need the patch and filter out the machines which are an OS we do not patch with SCCM. We only patch Client Os here and not servers Via SCCM. Therefore I'd like to be able to drop all SCCM clients running on server OS'es from the results.

When doing a search in Software Updates, when filtering the search it would be excellent if one of the filter criteria were the ability to filter by the OS of the Client needing an update. I'm NOT speaking of the free text search of the OS'es the patch applies to, but rather the ability to look at the OS of the machines that need the patch and filter out the machines which are an OS we do not patch with SCCM. We only patch Client Os here and not servers Via SCCM. Therefore I'd like to be able to drop…

When deploying Software Updates to your server farm, it would be great to have a centralized Dashboard or Web Interface that provides you real time statistics of the patch installation process. This would give you the ability to immediately see if a patch failed to install or a client failed to install a patch or, in the case of a few updates, that a reboot is required to the remaining patches can be installed. I know its kind of getting greedy but if this dashboard existed, and you could right click on a server and launch a remote version of Software Center and siimply initiate a retry from this Dashboard (rather then having to RDP into the server and do it manually), patching servers and workstations would be so much easier.

When deploying Software Updates to your server farm, it would be great to have a centralized Dashboard or Web Interface that provides you real time statistics of the patch installation process. This would give you the ability to immediately see if a patch failed to install or a client failed to install a patch or, in the case of a few updates, that a reboot is required to the remaining patches can be installed. I know its kind of getting greedy but if this dashboard existed, and you could right click on a server and launch a remote version of…

Report would be configurable to have date ranges, vender, security, updates, etc similiar to reports against a given machine. This would be able to be turned into a subscription that can be emailed after a WSUS update is performed. This way the admins can see what has been released since the last WSUS update or a given date for a specific list of update requirements. Never miss an out-of-band notice.