Microsoft

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.

If you require assisted support, please see https://aka.ms/cmcbsupport for more details.

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.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Install Servicing Stack Updates Before Other Updates

    Currently, when servicing stack updates and regular updates are deployed in the same software update group, the patches do not apply in a determinant order. This leads to cases where a cumulative update that requires a new servicing stack is installed before the servicing stack itself.

    While this can be worked around by separately deploying the servicing stack update before updates that require said servicing stack, it would be much more convenient if the update installation process checked if there are any servicing stack updates to be deployed and automatically installed them first

    1,241 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  22 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  2. Revamp ConfigMgr's cluster patching, and remove it from PreRelease

    Cluster patching feature was added in #SCCM CB 1602, but has been in prelease for a long time. It needs to:
    1) Have improved/revamped UI
    2) Remove dependency on collections
    3) Orchestrate patching for any machines, not just servers/clusters
    4) Remove the feature from prerelease

    647 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  30 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  3. Automatically Publish Full Content for Third Party Software Updates

    With the release of CB 1806 we are now able to publish third party updates using custom catalogs. Ideally, third party patches would function exactly like first party patches from an administration and automation perspective. Currently there's two main areas where this is not the case.

    Synchronization Schedule:
    I could be wrong on this but I believe that subscribed catalogs sync automatically every 24-hours. While that's nice, it would be great to simply integrate with the existing sync schedule. Sync the catalogs, publish relevant metadata to WSUS, then sync the SUP(s).

    Automatic Deployment Rules:
    Currently, only update metadata is published…

    334 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  15 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  4. ADR Available Deployments

    I would like to see ADR's support the creation of Available deployments in addition to Required deployments. We have some business cases where a certain subset of servers are aren't allowed to "push" software updates to until the server/app owners have verified the patches.

    The issue is that these servers don't have connectivity to the internet so we have to deliver them via ConfigMgr. By creating an Available update using an ADR, it streamlines our ability to "deliver" the updates to all systems, and allow the Patching Team, or App/Server owner to patch according to their own business schedules.

    238 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    22 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  5. 126 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →

    Updating status to planned, see https://docs.microsoft.com/en-us/sccm/core/understand/find-help#send-a-suggestion for an explanation of each status value.

    We’ve shipped fixes for a few scenarios that can cause this in 1902 but know there are some scenarios left.
    May we ask anyone still experiencing it on 1902 to gather verbose logs from the client and send a frown so we can troubleshoot additional scenarios that cause the error.

  6. Complex scheduling: Enable patch deployments to servers based on SDLC (Dev / QA / Prod / DR)

    Based on Patch Tuesday, allow application / business owners to select appropriate down time for the server as well as a sequenced order (e.g., Development servers during the first week after Patch Tuesday, QA on the second week after Patch Tuesday, Production servers on the third week after Patch Tuesday, et cetera). This allows the business owners to "own their own destiny" and get systems administrators out of the business of coordinating patching maintenance windows. In addition, the ability to insert "change freezes" that force the schedule to increment all downstream targets out by an additional week to compensate for…

    69 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  9 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  7. Request full control over allow/disallow force closing of Office 365 apps when installing updates instead of force closing Office apps

    In ConfigMgr 1610 Update Rollup 1 provided the change so Office 365 Updates did not force close any office applications when Office 365 patches were installed through ConfigMgr Software Center.
    https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-office-365-proplus-updates#restart-behavior-and-client-notifications-for-office-365-updates

    With ConfigMgr 1706 we require the option to disallow force closing of office 365 applications when patches are installed through the ConfigMgr Software Center.

    49 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  2 comments  ·  Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base