Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Improve the ADR engine

Improve the ADR engine

- Automate the cleanup of the previous software update groups created by the rules, i.e. before creating a new SUG it will check for older SUG members and based on criteria automatically manage updates that are member of a specific SUG. If updates are published or revised in 2016 then move the updates to our 2016 SUG, or previous month etc. Or, if they are superseeded or expired then remove the updates from the SUG...

- Allow to name the deployment create by the ADR, this will be useful for reporting purpose if you have more than one deployment for a rule.

- Allow to deploy updates manually, well as available rather than required. Well for this you can workaround with dealine... but it's not cleanest way.

- Add some criterias to avoid to redeploy some updates that are members of a previous SUG created by the rule and being sure that all the updates that are published or revised will be in the SUG.

- If your rules add the updates to an existing SUG, allow to delete all previous deployment created by the rules.

39 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Brouillard shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Noted  · 

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Mark A-G commented  ·   ·  Flag as inappropriate

        It would also be good to be able to create a firendly/alternate name for the rule failure alert so you know which rule failure you are subscribing to receive alerts for.

      • Simon Brouillard commented  ·   ·  Flag as inappropriate

        and would it be nice if the ADR only downloads the required updates for the targeted collections. i.e. Rule X create deployment Y & Z that trigger collection A & B, then only required updates for Collection Members A & B will be downloaded.

      • Ryan Davisson commented  ·   ·  Flag as inappropriate

        I'm not sure specifically of the ADR process, but it would also be important to make sure the ADR disables the Deployments it previously created before evaluating the updates/downloading/adding them to the SUG and resetting the deployment settings (ie. scheduling, enable/disable, etc.). We've had issues the past few months with SQL deadlocks during ADR processing that caused a failure, where an ADR had evaluated and pulled all of the updates in to the SUG and then updated the settings for some, but not all of the Deployments. This left us in a state where some old deployments were previously enabled and past-due on the deadline, but loaded with new updates. There wasn't a bug in that instance, but due to the manner in which the ADRs process through the steps, we had updates going out to our devices outside of the normal, expected schedule that the ADR was supposed to maintain. We now have to support a script on the site server that disables those deployments ahead of the ADR, just in case there are further errors during the ADR process. If the ADR were to disable previously created Deployments before doing anything else, that would build a fail-safe in the event of an error that disrupts the complete ADR process.

      • Simon Brouillard commented  ·   ·  Flag as inappropriate

        Also, I think it would be nice if we can add some filter lilke "deployed" to the Software update tab... then will be able to use ADR to deploy all required updates that are Not Deployed...

      • Ryan commented  ·   ·  Flag as inappropriate

        Please allow for ADRs to be security scoped as well. We can add a security scope to deployment packages and software update groups, why not ADRs?

      Feedback and Knowledge Base