I've found it manageable to use yearly SUGs and rolling monthly ADRs into them. It's faster and more efficient for me get it done each cycle than to wait multiple months with hundreds of updates. Like Jason recommends, I rename one ADR to be the SUG for that year (usually Jan), then roll each month up into it by changing the membership for the updates in subsequent ADRs and deleting those ADRs when the deadlines have passed. Keeps the SUG list neat and tidy. I also move deployed and irrelevant updates for products like SharePoint into folders so they're out of the All Software Updates list. The All Subfolders search seems to work well enough if I need to find any of them later.
-Russell ________________________________ From: [email protected] <[email protected]> on behalf of Jason Sandys <[email protected]> Sent: Thursday, August 13, 2015 8:37 AM To: [email protected] Subject: RE: [mssms] Rolling up monthly SUGs into yearly SUGs Update compliance scans are done against the entire catalog and have nothing to do with update groups. There is certainly some overhead with adding updates to new groups – mainly in policy -- but it’s not in terms of compliance scanning unless an update within a deployment has not been scanned for compliance previously. Instead of creating two new SUGs, you can save yourself a couple of steps and some overhead on the clients by renaming the most current update group that have that will be part of the consolidation and moving all of the other updates into this update group and then delete the others. SO if you have a monthly update group for Win 7 for example, rename to Dec 2014 update group to All Win 7 – 2014 (or something like that) and move all of the other Win 7 updates from 2014 into this update group – use a query to find them, don’t go to each update group, and then on the edit membership dialog remove the updates from the Jan-Nov 2014 update groups and add them all to the new All Win 7 2014 update group. Finally, delete the Jan-Nov Win 7 2014 update groups (which should all be empty). J From: [email protected] [mailto:[email protected]] On Behalf Of Sean Pomeroy Sent: Thursday, August 13, 2015 12:20 AM To: [email protected] Subject: Re: [mssms] Rolling up monthly SUGs into yearly SUGs 1,000 updates per deployed SUG. If you create a new one, they will have to scan against it. I've been pondering the same question. Interested in the feedback you receive. On Thu, Aug 13, 2015, 12:09 AM Corkill, Daniel <[email protected]<mailto:[email protected]>> wrote: Hi, I have a bunch of SUGs for monthly updates for the past 2 years that I’d like to roll up into two, yearly SUGs. Just curious what would be the safest way to approach this – I was thinking of creating two new SUGs and rolling all the updates into them and then deploying them with the Aug updates but I’m concerned this could create a lot of traffic as the clients process all the updates. Also I believe there’s a limit on the amount of updates that can be a SUG, or is that packages? Daniel. ********************************************************************* This email, including any attachment, is confidential to the intended recipient. It may also be privileged and may be subject to copyright. If you have received this email in error, please notify the sender immediately and delete all copies of the email. Any confidentiality or privilege is not waived. Neither the Council nor the sender warrant that this email does not contain any viruses or other unsolicited items. This email is an informal Council communication. The Council only accepts responsibility for information sent under official letterhead and duly signed by, or on behalf of, the Chief Executive Officer. Privacy Collection Notice Logan City Council may collect your personal information, e.g. name, residential address, phone number etc, in order to conduct its business and/or meet its statutory obligations. The information will only be accessed by employees and/or Councillors of Logan City Council for Council business related activities only. If your personal information will be passed onto a third party, Council will advise you of this disclosure, the purpose of the disclosure and reason why. Your information will not be given to any other person or agency unless you have given us permission or we are required by law.
