I use software updates groups that encompass all non-superseded or non-expired updates per operating system no matter how old. My ADR’s every month reuse the same SUG so it cleans them up for me at the same time it adds the month’s new to each. They run once a month on Tuesdays staggered throughout the afternoon starting about 2pm CT. We use maintenance windows for just about everything, servers and desktops alike.
I use SUGs like this as catchup SUGs too. If anything new enters the environment, these SUGs apply all current updates. I have collections and queries that put machines into buckets based on OS and maintenance window or not, and these SUGs are deployed to those. I can see in ruleengine.log on the site server that when the SUG changes it also updates the deployment to include the new patches. I also have an ADR and SUG for SCEP definitions, so my client settings run SU re-evaluation a couple times a day to pick those up. If I run the MS updates ADR out-of-band, machines will pick up and install any new updates in the deployment according to their maintenance windows. I also use these same SUGs to evaluate compliance. Since the SUGs contain every non-expired, non-superseded update, compliance for a given computer against that SUG is always accurate. I kind of see it like running a computer against Microsoft Update, theoretically each should contain the same set of updates as Microsoft Update for that OS. I spot check now and then, and usually the only differences are those updates that aren’t released to WSUS customers and I look at what they are and if I need to (or can) download them from the catalog and include them or not. I haven’t had to do that in a while, though. Then, I have a custom report that rolls up all my different SUGs into one report and arranges them by compliance state and then I can click through to the built in report for any individual machines “Software Updates - A Compliance > Compliance 5 - Specific computer” This one shows compliance per update. An ‘*’ in the Approved column means that the update is in a deployment, an ‘*’ in Installed is, well, installed, and an ‘*’ in Is Required, means the update scanned as needed. I don’t typically have to do anything but watch the ADRs run themselves on Patch Tuesday, and look at my report as machines come and go in and out of their maintenance windows. Todd From: [email protected] [mailto:[email protected]] On Behalf Of Brian McDonald Sent: Friday, September 4, 2015 7:05 AM To: [email protected] Subject: Re: [mssms] Patching question Bump ;) Sent from my iPhone On Sep 3, 2015, at 4:25 PM, Brian McDonald <[email protected]<mailto:[email protected]>> wrote: Hello all, am using a Software Update Group that encompasses the entire year's updates. What is the best timing for managing this group? It seems like when we move expired/superseded updates out that SCCM is reapplying the update group again later and that there is a possibility that machines will reboot when we don't expect that to happen. If we have our software update group applied to all machines and then remove some expired/superseeded updates, will it try to reapply the software update group to all machines - at the same time? Also, when I review the compliance reports and see that not all machines in the group are in compliance, how do I determine which updates are causing the machines to not be in compliance? Thanks, Brian
