Friday, January 17, 2014

SCCM Updates: Go for "Autopilot" not "Total Automation"

I've been getting lot of questions on a previous post regarding my approach to software update structure with SCCM. I replied to a few and this generated even more questions so I felt the need to do a more lengthy response about why I do things the way I do them and what led to my approach and that led to this post. I'll start by answering the last question posted there. Yes, I clean up superseded and expired updates by hand (for now at least) and there are a few very good reasons why I do it that way. When I was first attempting to implement software updates with SCCM I feel that my big initial mistake was to chase after a strategy that focused on "total automation". During my that first approach I literally created an ADR and package for every individual product that I wanted to patch. The ADRs ran monthly and cleaned out the expired and superseded stuff automatically. Sounds great right? In practice what I actually discovered was this approach works great for something simple like a daily Endpoint Protection update (because in that scenario you really only have to consider about 3-4 small patches a day tops). You try to do that with all the security, critical, service pack, etc. updates for multiple Windows versions going back to say 2003 and you run into several problems.

First you have a *lot* more patches to deal with in your software update group(s). Every time your SCCM clients kick off a software update evaluation cycle they have to look through all those updates and determine if any apply to the device upon which they are running. At a Microsoft conference last year I learned that this can cause high CPU utilization on your target machines. Still that’s not too bad because it only has to run once against the software update group provided the update group doe not change after that initial run. Ah but there’s the rub, I also learned that every time the ADR runs it automatically changes the content in your software update group! Do that every Patch Tuesday and your clients have to once again parse or scan that update group which (again) can hit your CPUs pretty hard. To put it in perspective, think about how many times we hear users complain about "slow computers" in our line of work. You don’t want to introduce something hat will hammer CPU utilization on your Servers or User PC multiple times a month.

Second by having a bunch of ADRs (I had a total of 12) that were constantly changing and updating the content in my software update groups I discovered I was putting a lot of load on my primary SCCM server in the weeks following patch Tuesday. The reason there should be obvious as it was constantly downloading patches and cleaning up software update groups based on those ADRs. So by chasing total automation I was (in fact) causing lot of performance issues on both my clients and my servers. Also it really made no sense to have ADRs that constantly ran against groups with updates that go way back in the past (they almost never change unless Microsoft expires or supersedes them). I came to realize that year-based static update groups with a single monthly ADR were the best choice for dealing with the performance and organizational issues I was facing. The reason being is I typically only have to change the older groups once a quarter (sometimes longer).  So (usually) I only have to worry about the updates in my most recent year-based group or my monthly groups (I usually keep monthly groups up to three months in the past before moving the updates from the oldest group into a year-based group).

Finally I learned another valuable lesson about the ADRs. No matter how well you craft your download rules they will inevitably screw something up. Either they will download something you don't want or remove something you want to keep. Its much better to have your monthly ADRs downloading updates into a test group and then (once you've verified what it downloaded) you can then move the contents of that test group into your static update group that targets production machines. Coincidentally this solves the "Expired and Superseded" issue through attrition as it forces you to do a "monthly visual audit" on your update groups when you open the console up after patch Tuesday to see what your ADR downloaded. If your static groups contain superseded or expired updates you'll see that the icon next to their names has changed to reflect that. At that point its child's play to just open the group and remove the older updates by editing their membership.


So that’s a pretty big reply to the questions I was being asked and (honestly) a lot of it is just what I’ve discovered through using SCCM 2012 in the past year. There may be a better way to do it, but this one works for me. I really struggled a lot with this at first and I hope I'm posting this big response in an effort to help others avoid some of my own pain. SCCM is a really complicated animal and I just think its a bad idea to go into it "set it and forget it approach". If it were really that easy we wouldn't need SCCM admins right? The main point I’d like to get across though is sometimes a 100% automated solution just doesn't make sense. SCCM can automate a lot of things for you but even with the advent of the autopilot feature on an airplane we still need pilots at the helm. Focus on design paradigms that automate the most time consuming, tedious or repetitive steps. Then if you find yourself still stuck with a manual step, try to make it something you can do very quickly (like at the touch of a button). I hope that makes sense and that others find it helpful. If there are any counterpoints to this philosophy or if anyone just has better ways of approaching this I'd love to hear about it in the comments section.

UPDATE: Someone requested a screenshot of my SUGs. I've added it below. Like I said we roll about 2-3 months in the past on our monthly deltas and once we achieve around 90% I move those to a year-based group. I've highlighted the delta and year-based groups in the screenshot. The other groups listed there are "special case" groups:


43 comments:

  1. Thanks ZeusABJ

    I'm trying to get a handle on our SCCM, and it's been more difficult than I imagined.

    I've read several SCCM 2012 books, but I just don't seem to grok the logic...

    1) How do I consolidate old updates into a single (by year) update group?
    2) After that, what is the safe way to delete the old (randomly named) groups?

    ReplyDelete
  2. Just use "Edit Membership" to move the updates between groups. Delete your old groups once they are empty. Be aware that if you use edit membership and move the updates into a group that is associated with a different package you may have to re-download the updates into the package/folder combination for the software update group you have moved them into.

    ReplyDelete
  3. Again Thanks. Great articles, Thanks for sharing man.. It's like I understand how this works now. Can thank you enough.. Owe you another beer..

    If you have the time could you write about you're experience installing software updates during a Build and Capture for windows 7. I'm dealing with it as we speak, and my issue is that 190 updates or downloading and installing, but hangs after the last update is installed, Read a lot about similar issues, but didn't found a solution. yet..
    Trying to do it like this: http://www.toolzz.com/?p=1059
    Thanks

    ReplyDelete
  4. We are not using OSD, only MDT so our Build and Capture process happens outside of SCCM. Sorry no help there.

    ReplyDelete
  5. Great article. One of very few Software Update articles that makes sense and introduces simplicity. My question is regarding the ADR Deployment Package for the monthly update. How often do you remove the old updates from the Deployment Package? As each months updates will append to the previous months updates in that package. Thanks

    ReplyDelete
  6. Typically I remove expired updates right away. Superseded I may leave for a month or two.

    ReplyDelete
  7. I'm newer at SCCM and am having a lot of questions marks come up as I am trying to fine-tune my ADR package. Currently I only grab "Critical" and "Security" Updates for the "Last 1 Month" but I feel like I may be missing updates doing it this way. I know this differs between organizations but could you share your ADR - preferable with some explanations :-) - to give readers some ideas for crafting their own ADR?

    Thank you very much!

    ReplyDelete
  8. Hey Gswipe,

    I basically do what you outlined above only I also do update rollups as well. My advice to you is make sure you check your products under the software updates tab and make sure you have everything you want to support there. Honestly in my (experience) the ADRs will never be 100% accurate all the time. I just look at them as a way to automate Most of what I need. Often I find myself clicking the "All Software Updates" item in the left pane of the console and running a search with expired and superseded set to "no" and then sorting on the date column. I'll then give the list a visual inspection and add any updates the ADR may have missed.

    Beyond that once a year in January I’ll do a “year end review/cleanup” on my update groups (I’m actually doing for 2015 right now) where I create a new year-based update group for the previous year that has gone by. When I do this I do a search for all updates in the previous year (all 12 months) for any products we support. Re-download them manually and put them into productions during our regular monthly update deployment cycle (so January also becomes my “catch up month” for any updated that might have been missed the previous year. I think you’ll find thought that going monthly will work just fine (for the most part). Like any good pilot when you put something on autopilot you should always periodically check to make sure its working as expected from time to time and deal with any “drift” that moves you off course.

    ReplyDelete
  9. I too struggle with grasping the concepts. A consultant had helped us when we first started and we have 1 ADR that downloads updates on Patch Tuesday. This typically will create a few SUGs per month.
    Our current process is we right click on each SUG and deploy it to our production systems (workstations or Servers)
    Any given month there are a total of 3-5 SUGS for each month.

    Now what I am trying to do is move to a more monthly/yearly process, kinda like what your doing.

    So here is what I think you are doing:

    1. Create 1 ADR that is monthly (Patch Tuesday)
    2. That ADR creates SUGs that contain all the updates with the settings you set.
    3. You manually created a SUG that is named yearly
    4. You manually created a SUG that is broken up in 3 month chunks
    5. You take all the new updates from patch tuesday and change their membership to reflect the 3 Month SUG and this gets deployed to your production machines.
    6. After the 3 months you move those updates into the Yearly SUG.

    Does this make sense? Am i on the right path?

    I am thinking of creating an ADR for Servers and one for Workstations, and then have the corresponding SUGS (monthly and yearly) for each OS type for better clarity.
    I find when i have all of them mixed together it can be challenging going through each one to make sure everything is good.

    ReplyDelete
  10. Sort of, here is is in a nutshell:

    1. Create 1 ADR that is monthly (Patch Tuesday)
    2. That ADR creates a single SUG for the month the ADR runs.
    3. The monthly SUG contains all the updates with the settings set in the ADR.
    4. The monthly SUG is auto-deployed to a pilot group the moment it is created.
    5. Pilot machines are checked to verify nothing is broken by updates.
    6. Additional deployments for production machines are created on the verified monthly SUG.
    7. These deployments are created manually to ensure the update schedule is visually approved bu a person (i.e. not fully automatic).
    8. This process is repeated for two more months.
    9. When a SUG reaches 3 months of age we check for at least 85-90% compliance.
    10. If compliance requirements are met the updates are moved into a year-based that is in a constant state of deployment (like an "archive" for in production updates, this means any machines that get on the domain that are non-compliant will be brought up to compliance automatically and if a user removes a patch SCM will put it right back on there the next time it hits its polling interval).

    Thats our strategy. You may have a better one but this works for us.

    ReplyDelete
  11. Thank you for your great blog and replies.

    "Every time your SCCM clients kick off a software update evaluation cycle they have to look through all those updates and determine if any apply to the device upon which they are running. At a Microsoft conference last year I learned that this can cause high CPU utilization on your target machines."

    After step 10, it will change the year-based software group. I assume that your production SCCM's clients is your target of the year-based software group deployment.

    Do you face high CPU utilization on the production SCCM's clients every 3 months after step 10?

    ReplyDelete
  12. Not normally no. I hear it is possible though if you have more than 1000 updates in your update group. My team tracks this for me and keeps them under 1000 at all times. If we have to go over 1000 updates the plan is to split the group but (so far) we haven't had to do this.

    ReplyDelete
  13. Hi, I'm responsible for setting up Windows Updates for a hospital with 5000+ active clients. My idea was to create collections for each department in the hospital so we had more control of when updates were pushed out based on maintenance windows, etc..

    I really like your current strategy and I'm wondering if you'd see any issues with adopting it for our environment with that many collections/clients?

    ReplyDelete
  14. This comment has been removed by the author.

    ReplyDelete
  15. Hey Andrew,

    Wow 5000+ clients, thats pretty awesome! I'd love to have a set that large under my belt. Max I've done thus-far is about 2400 (not chicken feed but still less than half of what you've got). Anyway, thanks for the kind words, the best advice I can give you for a install base that large would be to consider multiple DPs for load balancing. I don't know how may of my other posts you've read but I recently learned at an Ignite conference that some of the "experts" are now recommending approaches very similar to the one I outlined here. I think this approach is just a good overall "best practice" and I'm still using it myself today.

    The only thing I'm doing differently is trying to find ways to use PowerShell to automate the manual step of creating the multiple deployments off the SUG that my ADR creates but even in that case I'm planning to run the script manually. I just think its a very good idea to put eyes on what you deploy first, rather than trust an automated process entirely. Remember you are the pilot, and autopilot is not infallible. It sup to you to make sure that plane does not crash. If you try it out and it works for you drop me another comment here. I'd like to know I helped contribute something to managing to a 5000+ client install base.

    ;)

    Good luck!

    ReplyDelete
  16. Thanks for the info. I realized after reading this post that I was applying ADR's wrong. What I was doing was right-clicking on the ADR itself and choosing Add Deployment. Then I would just pick another collection. Apparently that's the wrong way to do it!

    ReplyDelete
  17. Ah gotcha. If you are having trouble getting started Kent Agerlund has some great books to help:

    https://www.amazon.com/Kent-Agerlund/e/B008A01KS8

    I've attended a number of conferences where he spoke and he really helped me grasp the fundamentals of SCCM. Learning to think the "SCCM way" can be a bit challenging at first.

    ReplyDelete
  18. Do you set it up for all updates to go in one Deployment Package? Or are you creating a new deployment package every month?

    ReplyDelete
  19. Currently I have a new SUG created every month. I am looking at switching the old ones to go in yearly SUGs. Let me know if I'm doing this wrong:

    1. I view the members of an old SUG
    2. Highlight all updates
    3. Edit membership

    When I do this there are many older SUGs that are these updates belong to (they are checked when editing membership). At this point do I uncheck them all and then check the new yearly SUG?

    ReplyDelete
  20. Hi Tyler,

    Question #1:
    No I do not put all my updates in one package as that would cause performance issues. In most cases create a package for each SUG, but (occasionally) I do wind up with a few related SUGS that may only contain a few updates. When that happens I pay just put those in a single package. A great example of this is Adobe Flash and Reader updates. I put those in a single package called "Adobe Updates".

    Question #2:
    Yes, when you have updates that span multiple SUGs you edit membership uncheck any SUGs you don't want them to be in and only check the SUG that you do want them to be in. Be aware that if the SUG you move the updates to is associated with a separate package then you may se a red X by the updates after you move them. Don't panic, just highlight any update with an X and re-download them into he new package and you should be good to go. Also don't forget to clean up the UNC path to your old package file as you'll have some orphaned update files left over from the move.

    ReplyDelete
  21. Thanks ZeusABJ,

    I'm stumbling also with Updates, maybe any advice. I've created (based on readings) 4 SUG (>2013, 2013-2014, 2015 and 2016)

    I can create multiple deployments to different Collections with different installation deadlines)

    but do I need to deploy all updates also to the all systems collection as available? or to the all unknown computers collection, because all new Computers added to SCCM also need those updates (maybe when installing or when a new collection is created) I'm on the move from a manual environment to an automated installation adn reboot requirement.

    So I can manually create the deployments, no problem, but need a way to get and keep all machines up to date, including newly added machines.

    if anything is not clear please respond and I try to clarify

    Thanks in advance

    ReplyDelete
  22. Hi mate,

    Thanks for sharing your approach wit this, it is very similar to ours. One question I have for you is how you deal with picking up updates that may be missing from your baseline? For a simple example lets say that an admin installs a particular version of .NET on a server that has not been installed in your environment before. Updates for this version would have never been picked up before and placed in your baseline and will not be picked up in the future due to you limiting your monthly update ADR to Updates released/revised in the last month.

    ReplyDelete
  23. Hi Steve,

    I have a saved search that I run once per quarter with the criteria "Expired = No", "Superseded = No" and (this is the important bit) "Required is greater than or equal to 1". This search should return any updates that are "required" by a system in my environment that I may have missed. I then add them manually or tweak my ADR to account for them next time. Hope that helps.

    ReplyDelete
  24. could you send me a screen shot of a setup for software updates as explained to bfsteel@hotmail.com so I can get an idea of what you have explained. New to this software now. Thanks

    ReplyDelete
    Replies
    1. Hi BFSteel, I have posted a screenshot of our SUGs above. Hope that helps.

      Delete
  25. Hi,
    I really like this approach. I've had to read it a couple of times to get the gist of what you were trying to achieve and it does make sense by limiting the amount of client queries etc
    I'm still not 100% clear on how the yearly SUG's are applied after the monthly SUG's are moved into the yearly SUG's.
    I understand the monthly SUG's deployment etc and the once every 3 months moving all updates into the yearly SUG if compliance is deemed within your tolerances.
    The part I don't understand is "the yearly SUG's are in a constant state of deployment". Could you expand on that? ie what schedule are they set on?
    I like the concept that the current yearly SUG is only updated 4 times per year (once every 3 months) which thereby limits the client traffic to those 4 instances and most clients will have all those updates anyway. The yearly SUG is also a great catch all too with the previous years not changing at all, thereby limiting the traffic further.
    So, just curious how the yearly SUG's are scheduled or deployed.
    BTW, great post and we are going to implement this strategy and thank you for saving us this potential pain as we were heading down that same initial road.

    ReplyDelete
  26. Hi louis,

    I think you may be overthinking this. At its core this guide is just giving you a method for "organizing" updates you have already deployed. This "system" was my way of working around basic SUG limitations. The "Year" based SUGs really sort of serve as an "active" archive of updates you have previously deployed. When one of your delta SUGs reaches around 90% compliance you move those updates to a year based group and just deploy it. As the year progresses keep doing this as your subsequent deltas also reach 90%. Since the updates are already on 90% of your computers it does zero harm to leave them "constantly deployed" as they won't reinstall on computers where they are already installed.

    Doing this also lets you clean up all those monthly SUGs that get auto-generated by your ADRs and allows you to consolidate them by year. Leaving them constantly deployed enforces compliancy in your environment because if a user removes an update you previously deployed then SCCM will just reinstall it for you the next time the client runs its Software Update actions. You don't really have to organize them by year or month at all, I've just found that (in practice) going based on increments of time works best for me to keep our SUGs simple, organized and under the "1000 updates per SUG" limit recommended by Microsoft. If that limit were not a factor then you could just ditch the year-based structure, create one big SUG called "Updates we already deployed that we don't want people to uninstall" and deploy that with no end date at all to get the same result.

    In fact, something like that may be a possibility sooner rather than later. Microsoft's decision to switch to monthly cumulative update rollups (i.e. pseudo-service pack updates that contain the latest patch Tuesday updates with all previous updates rolled in as well) may actually make my year-based model obsolete 9as again the main goal was to create a system whereby my SUGs always had less than 1000 updates in them). Also you should make it a point to clean out old updates from the year-based groups as Microsoft expires or supersedes them. I actually had a case last year where three of my really old year-based SUGs wound up with less than 200 updates in each ot them due to expiration ans supersedence! So I took the updates in those three update groups and consolidated them into a new year-base group named 2010-2013 Updates and redeployed it.

    Again this is just a model for structuring updates you already deployed to ensure they stay deployed without blowing up the CPUs on your clients. I hope that makes sense.

    ReplyDelete
    Replies
    1. Hi, thanks for the quick reply. I was thinking about it again and it did make sense. My issue was that we hadn't deployed any updates at all with SCCM as we're only just putting it in. I've now created the groups and am in the process of deploying the SUG's.

      Delete
  27. Awesome Share , liked your approach , Kudos ! . If possible can you share whats criteria you set to create monthly update groups ?
    tx

    ReplyDelete
    Replies
    1. Hi Raheel,

      I feel like I already did that... can you be a little more specific as to what you want to see?

      Delete
    2. Hi, little confuse with setting up ADR for monthly patch tuesday.

      Is it like we create manually yearly SUG (All updates 2017), then we create ADR for monthly , that creates auto group ? What about the package created yearly how we keep that just one , trying to understand your way.

      How do we archive these then

      Delete
  28. Create an ADR to download and deploy monthly "patch Tuesday" updates. The ADR will generate your Monthly SUGs with the updates you have chosen. As the updates in the SUGs get to 80-90% compliance "age" them out of production by moving them to a manually created Year-based group. The year-based group should stay deployed all of the time (so your approved updates will always reinstall, even if someone tries to uninstall them - thats the "archive" bit). Occasionally Microsoft may expire or supersede updates in your year-based groups. When that happens, clean them out.

    Can't make it any simpler than that.

    ReplyDelete
  29. Hi,

    Many thanks for your blog. I'm in the process of switching from WSUS to SCCM, and it's certainly an interesting learning curve. Your blog has given me plenty of food for thought :)

    A couple of quick queries for you. In your screenshot of SUG's, I don't see a separation of Servers VS Workstations. Do you deploy both server and workstation updates via your Monthly Delta updates, and would there be a reason you wouldn't split them (other than trying to keep SUG's to a minimum)? Similar query also for Pilot/Test VS Production deployment - how do you deal with that?

    Many Thanks, Steve

    ReplyDelete
  30. Yes I keep all my updates (regardless of product type) in time-based SUGs. So all updates for Office, Windows, CRM, Visual Studio, etc. are all contained in the same SUG for the year (or delta month) in which they were released. I have some degrees of separation using different collections and deployment types (off the SUGs) but a Windows system running an SCCM Client is capable of sorting out and installing only the updates it needs from those contained a SUG.

    ReplyDelete
  31. Hi Zeus,

    Great blog....I've been bashing my head over SCCM and you given me some great insights :) I have a couple of queries I'm hoping you might be able to shed some light on:

    When creating ADR's and selecting the Product, how do you deal with the multiple products that might be on one device? As an example, I have devices with Windows 10 and Office 2010. If I add those to my Product selection it will show me the updates for those. But then it will not list things like Silverlight, MS_SQL and anything else not included in the product selection that may be installed. I know you said you don't do ADR's for all the different products, so what is your solution? I know I can just adjust the product selection to add the others, but I know something will get missed if a new piece of Microsoft software is installed on a device that I'm not aware of, so my ADR won't catch it.

    My other query relates to ADR's and how to pick up older updates. When you choose "Date Released or Revised", you can only select up to "Last 9 Months" as the maximum. I've been using MS's Baseline Analyzer to see what I'm missing and I can see a few updates (pretty much only Office 2010) which are much older than 9 months. Do you have any thoughts on how to grab those?

    The ADR search criteria seems to be fairly restricted - it would be good if it had the ability to build your own query, like you can in Device Collections.

    Many Thanks,
    Steve

    ReplyDelete
  32. Hi SMJ,

    I put all my products (Office, Silverlight, Windows, CRM, etc.) in 1 big "Patch Tuesday" ADR that downloads the updates, creates my SUGS, and creates my deployments to collections (but they are disabled). After the ADR runs I visually review the content of the SUG, remove any updates I don't want and add any updates the ADR may have missed (they are seldom perfect). Once satisfied with my update content I check the schedule for each auto-generated deployment under the SUG and tweak that (if needed). I then enable each deployment, kick back and watch them go. Once they reach 90% I move them to a year-based SUG that is always deployed. If a user uninstalls an update or if they install something new that needs patching the update just goes out when the SCM client runs a software updates evaluation cycle.

    For older updates I just created some custom search criteria that I run against all software updates a couple of times a month (mostly based on the "is required" option. If I see something got missed or some newly installed Microsoft product in the environment now requires patching I just download them manually and move them into the delta SUG for that month and they go our with the regular Patch Tuesday updates.

    Like I said, this is not full-auto, you are a pilot directing an automated system. Occasionally you'll have to take manual steps to "right the course" of the ship.

    ReplyDelete
  33. Hi Zeus,

    Thanks for that - Awesome, gets me a lot closer to where I need to be. I wasn't quite able to get my head around those last two points. SO now I'll end up with something like:

    1) Create ADR's which includes ALL known OS's and Products (Server & Desktop) to be patched.
    2) Run regular manual searches (with Expired=No, Superseded=No, Required >=1) to pick up missing updates and any newly installed products.

    And maybe a step 3 of going back and re-tweaking the ADR to include any new Products found in step 2.

    I like many on here owe you a beer (or maybe in your case a great cuppa' tea) :)

    Steve

    ReplyDelete
    Replies
    1. Yeah you got it in a nutshell, just keep your SUGs under 1000 updates (if possible). I also have a few extra tweaks to exclude some crap I know I'll never need (like itanium platform updates) Sometimes it takes a little trial and error but just keep tweaking and refining over time and You'll fall into a pattern that works for you. Also your search pattern is a decent start, but (honestly) the ones I seem to use the most are like so:

      - Updates released in the last day with Expired=No, Superseded=No, Title not Definition

      - Updates released in the last week with Expired=No, Superseded=No, Title not Definition

      - Updates released in the last month with Expired=No, Superseded=No, Title not Definition

      Then I sort on "Deployed=No" and just look at anything I don't have deployed. Those usually paint a very good picture of anything I may have missed.

      Ha, yeah I love my tea ... and beer ... and cocktails ... and I really need to update this blog. Life is busy when you are an SCCM admin! I'm currently in the thick of some major PowerShell scripting. Maybe when thats done I'll post some code...

      Delete
  34. Hi Zeus,

    I've managed to get to a point where I'm almost happy, thanks to your blog and additional tips :)

    In your screenshot of your SUG's, your monthly ones are for example - "Monthly Delta Updates December 2016".

    My ADR is called "Monthly Windows Updates", and when it automatically creates the SUG for my pilot users, the SUG ends up with a name like "Monthly Windows Updates 2017-08-11 16:02:51".

    I'm thinking that you are renaming the SUG to what you want it be after it is automatically created - is that correct? If I manually create a SUG, no problem's - but if it is automatically created then I have the date and time appended.

    Many Thanks,
    Steve

    ReplyDelete
  35. Hi Steve,

    I do rename the SUGs (once I'm satisfied with their content) but you don't have to. I also rename the deployments under he SUG as well. Its just my personal preference and it makes them easier to find when searching for them under the monitoring node in the console. It also makes them easier to distinguish when running SQL reports against them. Again though, the renaming is not required.

    ReplyDelete
  36. I've adopted this approach and find it works well.
    I have 3 ADRS, each about 4 days apart for test workstations/servers, then servers, then workstations. The test workstations servers are deployed to a week after the 3rd week of the month when the security quality roll ups are released. We don't bother with just the security only updates. Each ADR is set to a single SUG rather than a new SUG every time it runs as I'm told the ADR will automatically remove expired, superseeded etc when it runs and each ADR holds 3 months worth of updates.
    At the end of the year, I then create a yearly SUG that contains all of the years updates as recommended here, ensuring that they don't ever contain more than 1000 updates.
    Ocasionally, I have to go in and remove the expired, superseeded from the yearly SUGs. Works well.

    ReplyDelete
  37. Awesome Louis! Glad this method works well for you!

    ReplyDelete