We do something similar. We have a monthly SUG, then 1 SUG for each year. Each month I move last month’s updates into our current year SUG and add the current updates to the monthly. If we get too close to the 1,00 update limit, we can always create a second yearly one.
I go through each SUG and remove any superseded/expired updates as well. We have a server task that runs through and deletes old update content so we’re not using extra drive space. Mike From: [email protected] [mailto:[email protected]] On Behalf Of Chad Simmons Sent: Thursday, August 13, 2015 3:24 AM To: [email protected] Subject: RE: [mssms] Rolling up monthly SUGs into yearly SUGs As far as the network traffic and/or processing on the clients, that's not something I've ever been concerned about, but perhaps I should. Since it is just policy, not content, and your clients are already (most likely) already scanning against dozens of SUGs I would not expect even a blip to show up on any monitor when you reorganize the SUG. For one customer I used the following process to keep things "cleaned up". Each month had its own SUG and was kept throughout an SLA (Service Level Agreement) reporting timeframe. After that the non-expired Updates in a monthly SUG were moved to one of two cumulative SUGs 1) SUG #1: Security Updates - Cumulative 2) SUG #1: non-Security Updates - Cumulative This meant that at any one time we typically had 5 SUGs (2 cumulative and 3 monthly). Splitting the historical Updates between 2 SUGs accomplished several goals: 1) Forced a cleanup of expired updates 2) Kept the number of Updates under the 1000 hard limit 3) Provided an easy / additional reporting method for the most important updates (security) versus other updates (critical, recommended, etc.) I didn't organize SUGs by timeframe because I really don't care when an Update was released after the initial rollout. I just want to easily deploy and report on what is really important (security updates) versus what is nice to have (everything else). If you implement the same or improve upon it let me know. Thanks Chad Simmons | Microsoft System Center Configuration Manager Consultant | linkedin.com/in/chadsimmons From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sean Pomeroy Sent: Wednesday, August 12, 2015 11:20 PM To: [email protected]<mailto:[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.
