Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Configure multiple deployments in One Software Update Group

Hi,

After the successful implementation of the following, https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/8386953-configure-multiple-deployments-in-an-automatic-dep, which is really nice. How about the possibility to extend this and instead of creating several SUGs with different deployments create one SUG with multiple deployments?

58 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Anderz Wedefelt shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

9 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Jason Sandys commented  ·   ·  Flag as inappropriate

    The recommended solution for available deployments is to use a required deployment with a deadline 12 months out -- I filed a DCR and this was the response I got. While I agree that just creating an available deployment would be better, this is pretty much the same thing.

  • Stephen Cooper commented  ·   ·  Flag as inappropriate

    Confirmed - one SUG with multiple deployments. Now, if only it was possible to create "Available" ADR deployments instead of them implicitly being "Required"...

  • kedia990 commented  ·   ·  Flag as inappropriate

    Did Microsoft "fix this"? I no longer notice this behavior in v1606 - there's now just one SUG, and multiple deployments of that SUG. Basically - Thank you! I just didn't notice a status update on this, so commenting to check in.

  • Anonymous commented  ·   ·  Flag as inappropriate

    We run SCCM in a large Enterprise environment with over 100,000 seats. Using ADRs would be nice, but so far we have stayed away from them as the patches Microsoft releases in a month are not necessarily the ones we will release to the entire Enterprise.

    For example, if Microsoft releases 10 updates including Windows and Office Updates, 1 or 2 of them may not apply to our environment or they may actually cause issues with an existing application (usually .NET). During our monthly approval process our Security Team creates a list of updates released by Microsoft and then provides us (SCCM team) with the list of updates to be deployed. Again, one or two (or more) may not make the final cut for release.

    Given this scenario, ADRs aren't a good choice as currently an ADR forces you to download the patches to a package and deploy it to a target Collection (I realize I can just point to an empty Collection or not enable the deployment - it's the package update and distribution that is the issue given that we have 2800+ Distribution Points). Instead it would be great if an ADR had the option to ONLY create a Software Update Group. This would allow us to automate the creation of the SUG but then modify the list based on our Security Team's list of updates to be deployed. Once the list is finalized, the Admin can then run through the Download/Deployment process and send the updates out.

  • kedia990 commented  ·   ·  Flag as inappropriate

    Wow, was just about to post the same idea and stumbled upon this (BTW, it looks like others have posted this as well - e.g. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/11121534-configure-multiple-deployments-in-one-software-upd - they should be merged and so should the vote count ;) ).

    Things did seem messy when an ADR which I multiple-deployed to 5 device collections ended up creating 5 different SUGs. It doesn't make a lot of sense because the ADR's Software Update criteria is a constant for all deployments, so the software update group which is generated as a result (based solely on that criteria and nothing else) must also be the same. It's also a little disappointing that the software update groups are differentiated by a mere integer suffix, which doesn't tell you anything until you actually examine the associated deployment to determine which collection it goes out to (<ADR Name> - <Collection Name> - <Timestamp> may have been better)?

    Would it be possible, say, to provide an option when configuring the additional deployment to use the "primary" SUG or spin off a "sibling" SUG?

  • Stephen Cooper commented  ·   ·  Flag as inappropriate

    Hi, thats rather the point - the additional deployments in the ADR generate additional SUGs - they dont use the same one. Does that not happen in your 1511 site?

  • Mirko Colemberg commented  ·   ·  Flag as inappropriate

    You can add additional deployments for one ADR, in 1511, that is your solution i think, and in the ADR set to uses the same SUG and it's easy work for your need...

  • Stephen Cooper commented  ·   ·  Flag as inappropriate

    My first post-1511 ADR just ran for Patch Tuesday updates and I have to say I'm a little disappointed. The rule created multiple Software Update Groups each with one deployment - I would prefer one SUG with multiple deployments.

    Currently I have an ADR which auto-deploys Patch Tuesday updates to my pilot group, I then manually create additional deployments of the same SUG to my "early adopters", "production - auto" and "production-manual" groups. A single SUG with multiple deployments offers a better user experience for me - I'd find 48 update groups (well, 36 actually isn’t it because you can’t create an "available" ADR deployment can you?) just for Patch Tuesday updates messy and counter-intuitive.

Feedback and Knowledge Base