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.

Currently, there is no way to actually know when an update was deployed. Some/many organizations use new software update groups every month and this seemingly addresses this request; however, using new update groups every month creates clutter and is really unnecessary. It also doesn't truly address the need to track when an update was deployed because the membership of an update group can be changed after it is deployed. Having this tracking addresses this single shortfall in reusing update groups.

At the moment when creating a service plan in SCCM e.g. for Windows 10 Fall Creators Update (1709) there are several versions downloaded. Like the x86, x64, consumer and business files. So if you need the update only for Win 10 x64 Enterprise EN, you will still get all 4 versions: the x86, x64, consumer updates (Win 10 Home) and business updates. That results in pretty much wasted disk space which would not be necessary since the x64 business files would suffice.

It would be great if we can define the search better so you can choose what files will be downloaded/used for the service plan.
E.g. a checkbox for x64, business, all, and so on.

At the moment when creating a service plan in SCCM e.g. for Windows 10 Fall Creators Update (1709) there are several versions downloaded. Like the x86, x64, consumer and business files. So if you need the update only for Win 10 x64 Enterprise EN, you will still get all 4 versions: the x86, x64, consumer updates (Win 10 Home) and business updates. That results in pretty much wasted disk space which would not be necessary since the x64 business files would suffice.

It would be great if we can define the search better so you can choose what files will…

We are a school system with over 30K of 1:1 devices and counting and our networking team just watched 378 GB of downloads from dl.delivery.mp.microsoft...this morning. Turns out that this is Win10 Store apps updating. (Provisioned apps most likely as we use very few apps right now.) My boss was not too happy that this happened during testing.

We control our Windows updates with SCCM using a SUP and WSUS and everything is fine but we have no way to control store updates, frequency, caching on our DPs etc. Any chance of adding store updates to work like Windows updates do?

We are a school system with over 30K of 1:1 devices and counting and our networking team just watched 378 GB of downloads from dl.delivery.mp.microsoft...this morning. Turns out that this is Win10 Store apps updating. (Provisioned apps most likely as we use very few apps right now.) My boss was not too happy that this happened during testing.

We control our Windows updates with SCCM using a SUP and WSUS and everything is fine but we have no way to control store updates, frequency, caching on our DPs etc. Any chance of adding store updates to work like Windows updates…

The idea of leveraging a Windows 10 Servicing plan is great. It's a relatively simple process that can keep companies on a defined Windows 10 lifecycle. However, due to the nature of the upgrades and processes in which things get reset or reinstalled customers are forced to leverage task sequences. With the announcement of Windows 10 1803 pre/post configuration scripts, there now appears to be somewhat of an avenue where these items can start to be managed. However, when you look at our customers failure percentages for any deployment, you have to ask yourself, would a customer really want a 10% deviation from their standard after every upgrade? To enable more customers to leverage Servicing, it would be great if we had the ability to manage the pre/post scripts built into servicing. However this only address half of the problem. Customers are also dealing with application uninstalls/installs to support new versions of Windows 10. If we had the ability to tag SCCM Applications for uninstall and install, during the servicing process, it would provide a great deal of control where customers could start leveraging Servicing.

Attached is a simple flow diagram of the process I am proposing.

The idea of leveraging a Windows 10 Servicing plan is great. It's a relatively simple process that can keep companies on a defined Windows 10 lifecycle. However, due to the nature of the upgrades and processes in which things get reset or reinstalled customers are forced to leverage task sequences. With the announcement of Windows 10 1803 pre/post configuration scripts, there now appears to be somewhat of an avenue where these items can start to be managed. However, when you look at our customers failure percentages for any deployment, you have to ask yourself, would a customer really want a…

We create "year packages" for several products so older updates are in a "static software upgrade". But we still have to maintain these SUG periodically to remove superseeded updates.
An example:
I'd like to have an ADR which selects all updates from 2015 for all my server OS'es and checks this every month or quarter so expired updates are automatically removed and reinstated updates are added again.

In addition, I want my current ADR to select all updates from 1st of Januar till now. This is not possible at the moment because all moments are relative.

Why(?) this seems strange since the option "add to existing Software update group" the SUG cleans before adding the selected updates. This makes the "adding" variant obsolete, isn't it?

We create "year packages" for several products so older updates are in a "static software upgrade". But we still have to maintain these SUG periodically to remove superseeded updates.
An example:
I'd like to have an ADR which selects all updates from 2015 for all my server OS'es and checks this every month or quarter so expired updates are automatically removed and reinstated updates are added again.

In addition, I want my current ADR to select all updates from 1st of Januar till now. This is not possible at the moment because all moments are relative.

The deployments created by ADR's base the available and deadline specific times on the point at which the new deployments get created and not when the ADR was started. This means we have to go and change the available and deadline times each time after the ADR's run.
i.e. ADR starts at 8am, deployment gets created at 8.30 by the currently running ADR, Deployment available and deadline specific times on the ADR deployment will be based off 8.30 instead of 8am.

Deployment Packages have nothing, zip, zero, nada to do with deployments so calling them deployment packages leads folks to the wrong conclusion about them and is inaccurate at best. These packages simply contain update binary files and should instead be called "update packages" or maybe even "update binary packages" to emphasize what they actually do.

When looking at an update either through All Software Updates or a SUG please make the statics node clickable. It would be beneficial from that node to be able to click on "required" or "unknown" to see the specific list of machines, similar how you can see the stats when looking at a deployment. Currently only real way to look up the stat is to write down the KB and then head over to monitoring and start running reports on the KBs.

Now that Microsoft has moved away from using the Bulletin IDs for some of the major updates, it will become very useful for us to be able to search the Software Updates using the CVE number (i.e. CVE-2017-0199: Microsoft Word HTA Handler Vulnerability). This will help us quickly look up patch status for those CVE identifiers.

Now that Surface drivers and firmware are available to download as software updates it would be great to be able to deploy them without worrying about Bitlocker and having our users locked out.

So far it seems that we have to do a lot of testing to see whether or not a driver or firmware will lockout bitlocker, and then give up and deploy them using a TS, so we can suspend Bitlocker, update, reboot and reenabled bitlocker.

Could all drivers/firmware from the Surface update category automatically have bitlocker suspended when deployed as an update? or give us a tick box in the deployment options to suspend for x number of reboots (some of the firmware reboots a few times).

Now that Surface drivers and firmware are available to download as software updates it would be great to be able to deploy them without worrying about Bitlocker and having our users locked out.

So far it seems that we have to do a lot of testing to see whether or not a driver or firmware will lockout bitlocker, and then give up and deploy them using a TS, so we can suspend Bitlocker, update, reboot and reenabled bitlocker.

Could all drivers/firmware from the Surface update category automatically have bitlocker suspended when deployed as an update? or give us a tick…

We have the ability to setup ADR's for O365 updates, but we need the ability to create O365 ADR's for downloads and deployments of the newest O365 Installers to new images that do not have O365 installed yet.

I am wondering if we can have an option in SCCM to force restart desktop endpoints after patch installation when no user logged in. This option certainly not useful for server endpoints but for desktop endpoints, it could be a blessing for work station admins those have to chase users to restart the VDI/desktop endpoints periodically to get patches installed in an environment where admins can't define any specific restart time due to nature of the job. Possible options/ features I see:
1. Define setting in machine collection/ deployment group that if no user logged in install the patches and force restart the endpoint.
2. If the user is logged in and restart is required, the SCCM client waits for the time when the machine has no user logged in to trigger force restart.
3. Option to configure this feature only for client OS to avoid human error to force the setting in server environment.

Hi There,

I am wondering if we can have an option in SCCM to force restart desktop endpoints after patch installation when no user logged in. This option certainly not useful for server endpoints but for desktop endpoints, it could be a blessing for work station admins those have to chase users to restart the VDI/desktop endpoints periodically to get patches installed in an environment where admins can't define any specific restart time due to nature of the job. Possible options/ features I see:
1. Define setting in machine collection/ deployment group that if no user logged in install the…

In SCCM console, Software Library --> Software Updates, I have never seen the 'Content Size (KB) column' ever populated with the size of an update, why is this? Would it be possible for this information be passed through? Individual patches have developed into becoming cumulative updates, rollups etc and are considerably larger in size e.g. over 1 Gb each. In some instances they fail to install on low spec servers because they are marked with what seems to be the standard 'Maximum Run Time' of 10 Min. Knowing the update size and the MTU set within the view of the SCCM console would be a step forward, without having the need to drill-down into each update. This would be very beneficial. Not all organizations have super computers.

In SCCM console, Software Library --> Software Updates, I have never seen the 'Content Size (KB) column' ever populated with the size of an update, why is this? Would it be possible for this information be passed through? Individual patches have developed into becoming cumulative updates, rollups etc and are considerably larger in size e.g. over 1 Gb each. In some instances they fail to install on low spec servers because they are marked with what seems to be the standard 'Maximum Run Time' of 10 Min. Knowing the update size and the MTU set within the view of the…

Since the deferred channel consists of multiple versions it would be great to select from those deferred channels as well. Customers that roll out on this channel only usually still have some kind of waves implemented regarding the different versions available on that channel. The name of the updates can only be filtered so much (see screenshot) before it becomes impossible to filter any further. Currently they need to change the version number every time within the ADR.