Configure multiple deployments in One Software Update Group
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?
Jason Sandys commented
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.
Confirmed - one SUG with multiple deployments. Now, if only it was possible to create "Available" ADR deployments instead of them implicitly being "Required"...
it would be awesome if they have - I havent tried it again since my original post
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.
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.
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?
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
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...
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.