tag:blogger.com,1999:blog-8210675588153120371.post4430861314514108596..comments2023-06-16T08:21:16.286-05:00Comments on A Cup of IT: SCCM Updates: Go for "Autopilot" not "Total Automation"ZeusABJhttp://www.blogger.com/profile/09421603730258946485noreply@blogger.comBlogger56125tag:blogger.com,1999:blog-8210675588153120371.post-36836556831793494342018-01-31T23:03:17.311-06:002018-01-31T23:03:17.311-06:00Question 1: Yes the names I give to my SUGs are ve...Question 1: Yes the names I give to my SUGs are very similar to the names I use for packages. Just remember though that (in reality) a SUG is just a grouping (or collection) of updates while packages contain the actual updates you have downloaded. You just use the SUGs as a way to organize those updates for deployment. Also you can have multiple SUGs that reference a single package, so you should name your packages in a somewhat abstract manner. For example, you could have a single package for your monthly delta updates named "Monthly Delta" that is then referenced by three SUGs named "Monthly Delta - Jan 2018", "Monthly Delta - Feb 2018" and ""Monthly Delta - Mar 2018".<br /><br />Question 2: My source folders are all contained on a network share named "UPD$" on a file server. I have a folder under there that corresponds to each package and (to keep network paths as short as possible) I give the underlying folders names that are a sort of abbreviated form of my package names with no spaces. So say I have a package named "Year 2017 Updates", the corresponding source folder would be "YR-2017".<br /><br />Question 3: Since I base all my update organization methodology on units of time (i.e. when the updates were released). I do not separate them by product. When I first started working with SCCM I tried organizing them by product name and quickly discovered that organizing them based on when they were released just made a lot more sense (for the big picture). That being said I do (occasionally) run into a special case that will lead me to segment an update off into a SUG by itself so I can deploy it to a specific subset of systems . A good example of this is the recently released .NET Framework 4.7. I have a few servers running mission critical apps that will break if .NET 4.7 is installed. So I created a separate SUG named "NET Framework Updates" for it and deploy it in a different manner from all my other updates, but it still references the Year 2018 Updates package. The only real reason to split up your packages is if you wind up with over 1000 updates in a package as (historically) this has caused performance issues with SCCM.ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-75803929692991911482018-01-31T08:57:04.289-06:002018-01-31T08:57:04.289-06:00Sorry to beat this questions down but I'm a li...Sorry to beat this questions down but I'm a little confused on the source for the files and deployment packages and how they relate to your SUG's.<br /><br />You mention to not have 1 deployment package for performance reasons. Are you creating a like deployment package named similar to your SUG. <br /><br />Example would be, 2003-2010 SUG corresponds to 2003-2010 Deployment Package?<br /><br />Also where are is your source folder for the files? Are you storing them all in one folder or do you have a folder that corresponds to the SUG and DP? Example from above would that location be server\sources\2003-2010 Updates? Or do you just have all updates for all products go into server\sources?<br /><br />We also release monthly Office updates along with the Windows updates. Should I break up these types of updates? Ex. have all Windows updates 2003-2010, 2011,2012, and then 3 deltas that are current or can I include all Office updates in there as well? Ex All updates 2003-201,2011, ect.?<br /><br />Thanks in advance!Anonymoushttps://www.blogger.com/profile/06619206233072079561noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-64735862236163786962018-01-23T08:52:47.555-06:002018-01-23T08:52:47.555-06:00super appreciate the speedy response. Thanks!super appreciate the speedy response. Thanks!Unknownhttps://www.blogger.com/profile/03559695149729037747noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-75452057255278278802018-01-23T08:47:23.860-06:002018-01-23T08:47:23.860-06:00Yes, Kent’s book is still relevant. I totally reco...Yes, Kent’s book is still relevant. I totally recommend it. Don’t be intimidated either, it does seem odd at first and my method is one that evolved over time to make sense for me. It was sort of funny to attend a Microsoft conference years later on software updates with SCCM where they described a method very similar to mine as a “best practice”. Point is, if you get in there and start playing around with it I think that (logically) you’ll arrive at a setup pretty similar to mine and at the end it will finally “click” and make sense.<br /><br />Good luck!ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-61385176513447071282018-01-23T08:07:36.172-06:002018-01-23T08:07:36.172-06:00Hi! I've recently started a new job at a local...Hi! I've recently started a new job at a local Hospital management company and have been tasked with coming up with a patching solution that will handle 5 hospitals. I am totally new to patching and have been reading as much as I can. <br /><br />I read your blogs and have no clue on what you're talking about(expected) but am sure once I have the basics down I can come back and it will all make sense. <br /><br />here in this particular blog you've mentioned a book (https://www.amazon.com/Kent-Agerlund/e/B008A01KS8)that will help with the basic understandings. Kent's latest publication is 2014. Do you still recommend this given the dated material or is there something out there better suited for a super "green" guy like myself when it comes to patching. I have a storage/systems/DR background so all of this is new to me. <br /><br />Any help is appreciated! Unknownhttps://www.blogger.com/profile/03559695149729037747noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-34676661029365962602017-10-23T08:26:00.879-05:002017-10-23T08:26:00.879-05:00Yeah, they still release a ton of separate updates...Yeah, they still release a ton of separate updates for office. Frankly it wouldn't surprise me to see them go the "cumulative update" route with Office as well at some point. From my perspective the CUs just make more sense logistically, but who knows for certain what they'll do right? Not sure why you are having the issues moving the updates between packages (sounds like you are targeting the same package every time by mistake or something) but remember, having one big package for all your updates is ill-advised. The whole reason you are supposed to break them up is because it is CPU intensive for your clients to sift through packages that contain more than 1000 updates (at least historically that has always been true and I have not heard of Microsoft doing anything to "fix" that in SCCM. You don’t want all your Windows Clients and Servers out there getting bogged down with a consistent 100% CPU utilization every time your Software Update Actions run. Again, the relationship between packages, SUGs and download locations cane be a bit confusing at first but I'd like to encourage you to keep experimenting. You'll get the hang of it.<br /><br />To your questions:<br /><br />1) No, I do not as Microsoft tends to supersede the CU’s for the prior month. Just back in September they actually went so far as to *expire*a Windows CU which (as you should know by now) makes it non-deployable. This actually presented a major issue for us as we typically wait one month out before we push an update to our servers. Because they expired the CU for the prior month I was unable to update my servers the following month (because I had nothing that was deployable for them!). If Microsoft continues this practice going forward we will have to totally rethink how and when we deploy updates to our servers, otherwise they will never update! Also as Microsoft continues to release these CUs they are also superseding and expiring older updates in my Year-based groups. This means the update count in those SUGs is decreasing and I’ve actually been able to consolidate a few of them while still keeping my count below the 1000 mark. So now I am winding up with a set of SUGs that are based on year *ranges* now (like “Years 2012-2014”, or “Years 2014-2016” the point is its always changing and evolving and you have to be ready to adjust with it (again proving my constant assertion of “Autopilot, not Automation”, you have to be ready to “adjust course” as needed).<br /><br />2) I’m not 100% sure on this but I do know they release separate .NET-related CUs, and I think these contain all the .NET updates. I just deploy those as well.<br /><br />Good luck!ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-926934716556468532017-10-23T01:54:27.835-05:002017-10-23T01:54:27.835-05:00Hi Zeus,
Thanks for that. At least I'm not g...Hi Zeus,<br /><br />Thanks for that. At least I'm not going crazy with the multiple languages. Seems Office updates are one of the main offenders for that. Bit of a waste of resources when you only use one language - but that's what MS has given us.<br /><br />It looks like I will have to download my patches again and build one large deployment package for all updates. I tried moving the updates on a couple and changing the package source. Initially it seemed to work, but subsequent attempts produce the error "The package source has already been used. Specify an alternate source directory". If I get all my updates in one package source location and just have my ADR add to that I should be good.<br /><br />I have a couple more quick queries when you have some time:<br /><br />1) Now that the Windows 10 has the monthly cumulative update that contains all prior months fixes, when you move these to your yearly SUG do keep each of the prior months versions as well or only the latest/ Just wondering, as each of those is over 1 GB in size and over time that will take a bit of storage, especially when we have the same for server OS's as well.<br /><br />2) Are the .Net security updates for Windows 10 included in the monthly cumulative update as well? I've been searching all updates until I'm blue in the face trying to find these as separate updates, but no joy. I can find them as separate updates for all my other OS's (7, 8, Win2K8, Win2K12), but not Windows 10.<br /><br />Many Thanks,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-70057789836856807122017-10-18T08:57:27.033-05:002017-10-18T08:57:27.033-05:00Yes I have witnessed this behavior as well and no ...Yes I have witnessed this behavior as well and no I wouldn't mess with them. I think some updates are just multilanguage no matter what you do. Don't go messing with those CAB files, trust WSUS to download the files it needs. The only time I poke around in there is if I want to get a copy of an update file to run manually somewhere and even then I usually just get it from the Microsoft Update Catalog website. ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-21307581172435766062017-10-18T08:54:29.709-05:002017-10-18T08:54:29.709-05:00Yes you can do that, although I usually just re-do...Yes you can do that, although I usually just re-download them. Also if you double-click the package in SCCM it will show you a listing of all the updates contained in it. If you right-click and delete an update in that view it should delete the corresponding file(s) on your share as well. Point being SCCM will clean those shares up for you as your ADRs run and remove old updates. Also if you move your package source to a new location and don't move the files you'll see a red "X" appear on the SUGS that reference those updates. Just go in the SUG, right-click and re-download them and the X will disappear. I had a storage guy change some drive letters on me once and all the X's freaked me out, then I realized I could just change my package location, re-download them and all was well.ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-3005300127346155572017-10-18T03:16:03.658-05:002017-10-18T03:16:03.658-05:00Hey Zeus - it's me again :)
Just one last it...Hey Zeus - it's me again :)<br /><br />Just one last item which I've just discovered while having a look at the content of my package source locations.<br /><br />While having a look through the folders, I'm seeing packages for languages other than English having been downloaded (I do also have the English ones so that bit is good). I could sort of tell by the name of the CAB files, but to prove it I opened a couple and extracted the XML file - sure enough I've got Thai, Russian and lots of others.<br /><br />I'm not sure how that has happened, as I only have one ADR and it is set to English only under the Language selection. I have done some manual deploys, so wondering if that has any relationship.<br /><br />Anything you have experienced, or can see in what I've explained that might show a reason for this?<br /><br />Looks like I'm going to have to rebuild those package source locations again anyway :-P I could just review and delete the non-english packages - there's only a couple of hundred, but not sure of any other impacts.<br /><br />Thx,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-40726324725399332152017-10-18T02:54:12.408-05:002017-10-18T02:54:12.408-05:00Hi Zeus,
Thanks for the update. Yes that makes m...Hi Zeus,<br /><br />Thanks for the update. Yes that makes much more sense now :)<br /><br />I wasn't sure whether to split them up so I don't have too many updates in the one location, but it sounds like only the SUG's having too many items causes performance issues.<br /><br />I had split them up into a couple of different package source locations (a couple for different yearly updates, and then a couple for different months). It sounds like I should combine them all (desktops and servers) into the one package source location.<br /><br />I'm wondering if I can create a new package source location for all required updates, copy the updates from the existing ones into the new one, and then go back and modify the Package source locations to point to the new one. Have you tried that, or know if it sound like it should work?<br /><br />If it does, then I can go back and remove the old package source locations from disk afterwards.<br /><br />Many Thanks,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-69236185794630792702017-10-13T10:54:11.207-05:002017-10-13T10:54:11.207-05:00Point #1:
It probably has less to do with your AD...Point #1: <br />It probably has less to do with your ADR than you think. Microsoft has started re-releasing some patches after their "patch Tuesday" debut, also they seem to have started releasing updates for Office later in the month (no idea why there). Plus, sometimes if a month runs 28 days instead of 31 or if Patch Tuesday falls really early in the month your ADR may create a SUG that contains updates that were released in the Patch Tuesday cycle for the prior month. Point is, I've seen this behavior too and it doesn't really matter IMO. Who cares if you redeploy September updates in your October SUG, you already deployed the previous month so it’s not like they will reinstall right? Also, the SUG just contains pointers to the same updates you downloaded in September and they should be contained in the same package (if you followed my guide) so it’s not like you are downloading duplicates. So that part is a non-issue.<br /><br />For me the only thing I do watch when that happens is any updates that Microsoft posts AFTER one patch Tuesday cycle but BEFORE the next cycle hits. Those are usually re-issues of previous updates but (sometimes) they are "preview" updates for the next cycle. You certainly don't want to deploy those to your production servers and clients so watch out for those. Who knows what sort of effect they could have on your environment. Also, that just serves to back up my "Autopilot" instead of "Automate" assertion. *Always* review those SUGs before you enable those update deployments. Never trust an ADR to be so well crafted it becomes “set it and forget it”. <br /><br />Point #2:<br />Yes, the “Packages/SUGS/Download Location” relationship be very confusing at first. The simplest explanation is that a package is simply a container in SCCM that lets you organize the updates you download. The SUGs can then be applied as “filters” or “masks” for the contents of these packages. The SUGs themselves don’t contain the update files, they just reference or “point” to them in the package. The packages then “obtain” or “pull in” the update files form your download location (usually a network share). So, packages are how you store and organize the update *files* in SCCM, SUGs are how you group and disseminate those files in SCCM. SO you could have a single package that contained updates for Windows and maybe an update for CRM that was referenced by two SUGS, one named “Standard Windows Client updates” and one named “CRM Windows Client updates”.<br /><br />When I set up SCCM from scratch I typically use software update searches to pre-create my packages, then I just “attach” my ADR to that package by choosing that select option. You don’t want to create a new package every time because (historically)having a lot of packages can be processor intensive for your clients. That’s why I advocate creating year-based packages for all prior years and a single delta package for your current year. When next year hits make your current delta year-based (for the year that just passed) and make a new delta for the new year. I know it’s a bit hard to explain but that’s the best way I can describe it. Point is my SUGs change all the time but my packages seldom do because they are just containers of my updates.<br /><br />Does that make any sense?ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-35027923107881203802017-10-13T02:48:47.922-05:002017-10-13T02:48:47.922-05:00Hi Zeus,
I have most of my SCCM patching now work...Hi Zeus,<br /><br />I have most of my SCCM patching now working the way I want, thanks to your help :) I do have one new issue:<br /><br />When my ADR ran and created my October SUG, it actually had September patches in it. I have a sneaking suspicion that it's to do with the Deployment Package part of the ADR.<br /><br />So my question is to do with the Deployment Package tab within the ADR. The two options are "Select a deployment package" or "Create a deployment package". If you select Create then you need to provide a Package source. I went back and had a look at the properties of my ADR and noticed that it was set to Select a deployment package and it was my September one - guessing this is related to my issue. I don't see a way to create a deployment package manually, so I'm guessing it can only be done via the ADR.<br /><br />So how do you configure this part of it? Do you "Select" or "Create" so that it works correctly for the automated monthly process, and do all updates go to the same deployment package each month?<br /><br />I've read quite a few documents regarding this, and they usually say you can do it this way, or that - but none seem to go into the detail of how to get this bit automating properly for the delivery of patches to my pilot group.<br /><br />Apart from the above issue, everything else is looking great.<br /><br />Many Thanks,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-25091549560742868642017-08-15T19:27:32.382-05:002017-08-15T19:27:32.382-05:00Awesome Louis! Glad this method works well for you...Awesome Louis! Glad this method works well for you!ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-29999818356751000672017-08-15T16:23:31.543-05:002017-08-15T16:23:31.543-05:00I've adopted this approach and find it works w...I've adopted this approach and find it works well.<br />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.<br />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.<br />Ocasionally, I have to go in and remove the expired, superseeded from the yearly SUGs. Works well.louishttps://www.blogger.com/profile/10177729785651258463noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-40185704313170068432017-08-15T05:45:30.166-05:002017-08-15T05:45:30.166-05:00Hi Steve,
I do rename the SUGs (once I'm sati...Hi Steve,<br /><br />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.ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-50943131110178876372017-08-15T01:32:52.413-05:002017-08-15T01:32:52.413-05:00Hi Zeus,
I've managed to get to a point where...Hi Zeus,<br /><br />I've managed to get to a point where I'm almost happy, thanks to your blog and additional tips :)<br /><br />In your screenshot of your SUG's, your monthly ones are for example - "Monthly Delta Updates December 2016". <br /><br />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".<br /><br />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.<br /><br />Many Thanks,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-33520742579752570122017-07-06T21:49:51.205-05:002017-07-06T21:49:51.205-05:00Yeah you got it in a nutshell, just keep your SUGs...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:<br /><br />- Updates released in the last day with Expired=No, Superseded=No, Title not Definition<br /><br />- Updates released in the last week with Expired=No, Superseded=No, Title not Definition<br /><br />- Updates released in the last month with Expired=No, Superseded=No, Title not Definition<br /><br />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. <br /><br />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...ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-52851567465221706502017-07-06T20:47:15.929-05:002017-07-06T20:47:15.929-05:00Hi Zeus,
Thanks for that - Awesome, gets me a lot...Hi Zeus,<br /><br />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:<br /><br />1) Create ADR's which includes ALL known OS's and Products (Server & Desktop) to be patched.<br />2) Run regular manual searches (with Expired=No, Superseded=No, Required >=1) to pick up missing updates and any newly installed products.<br /><br />And maybe a step 3 of going back and re-tweaking the ADR to include any new Products found in step 2.<br /><br />I like many on here owe you a beer (or maybe in your case a great cuppa' tea) :)<br /><br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-39728464530902103372017-07-05T19:54:37.128-05:002017-07-05T19:54:37.128-05:00Hi SMJ,
I put all my products (Office, Silverligh...Hi SMJ,<br /><br />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.<br /><br />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.<br /><br />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. ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-43674808591600452952017-07-05T02:15:40.319-05:002017-07-05T02:15:40.319-05:00Hi Zeus,
Great blog....I've been bashing my h...Hi Zeus,<br /><br />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:<br /><br />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.<br /><br />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?<br /><br />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.<br /><br />Many Thanks,<br />SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-25575189750703887432017-04-23T22:05:02.443-05:002017-04-23T22:05:02.443-05:00Yes I keep all my updates (regardless of product t...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. ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-34349684217755236972017-04-23T21:55:05.281-05:002017-04-23T21:55:05.281-05:00Hi,
Many thanks for your blog. I'm in the pr...Hi,<br /><br />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 :)<br /><br />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?<br /><br />Many Thanks, SteveSMJhttps://www.blogger.com/profile/11984212922281859040noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-86460773618553769082017-02-14T19:12:03.022-06:002017-02-14T19:12:03.022-06:00Create an ADR to download and deploy monthly "...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. <br /><br />Can't make it any simpler than that.ZeusABJhttps://www.blogger.com/profile/09421603730258946485noreply@blogger.comtag:blogger.com,1999:blog-8210675588153120371.post-22726678574211069262017-02-14T14:54:19.335-06:002017-02-14T14:54:19.335-06:00Hi, little confuse with setting up ADR for monthly...Hi, little confuse with setting up ADR for monthly patch tuesday.<br /><br />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.<br /><br />How do we archive these then Anonymoushttps://www.blogger.com/profile/05143791948383833093noreply@blogger.com