I have recently did this. I do have a separate SUG for each product. So I have 2014-Windows 7 Updates, 2014-Server 2008 R2, 2014-Office, etc. It is mainly so I don't send updates to site Distribution Points that do not need them. For example, a site that has server 2012 and not server 2008. I will keep 2015 monthly until the year is up. I did, however, change to using a single update package per product for the year that I just add updates to. I used to have monthly packages as well.
Nick Gailfus Computer Technician p. 602.953.2933 f. 602.953.0831 [email protected] <[email protected]>| www.leonagroup.com On Thu, Aug 13, 2015 at 3:24 AM, Chad Simmons <[email protected]> wrote: > 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]] *On Behalf Of *Sean Pomeroy > *Sent:* Wednesday, August 12, 2015 11:20 PM > *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]> 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. > > > > > > > > > >
