63 votesstarted · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center Configuration Manager) responded
This shipped in 1803 TP should be available in the next Current Branch release.
Thanks for the feedback
Rudy Bankson: Just confirmed that's still an issue in 1802.
Yes please, doubly so on servers that just don't reboot for weeks at a time by their very design. The agent will have the lights on (service shows running) but clearly no one's home (no log action, none of the scheduled actions kick off).
FWIW, this item is essentially a duplicate of this one: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/18966352-adr-new-search-criteria-deployed-yes-no
FWIW, you can achieve the same result using maintenance windows. Create a non-repeating MW that occurs in the past and apply it to the servers you wish to manually patch. Deploy updates to them and watch them never install until someone manually does so.
This is in 1806 TP
There's a whole bunch of stuff that needs to be done to keep WSUS afloat.
SQL maintenance for one. There's already discussion about handling that better for the CM DB so it seems logical to extend that to the WSUS DB(s) as well. Let's use the local admin and SA right for doing good. I imagine the WID use case is a complicating factor there.
Fixing ConfigMgr's use of the WSUS cleanup wizard is another. In every environment I've seen, the wizard as ran by ConfigMan doesn't seem to do anything. Despite ConfigMgr running the wizard for years simply running it manually has always cleaned out thousands of updates and computers. There's practically no logging so that would be an easy baby step ... put the results of the API call into the ConifgMgr logs to show what was done.
The most important thing though, the thing that's going to have the most impact, is actually declining updates in WSUS. It's the only way to decrease the number of updates in the catalog that WSUS has to generate and cache and that clients scan against. The WSUS cleanup wizard will _never_ decline updates because ConfigMgr never approves updates which is a documented requirement of the wizard. A pretty straight-forward first step would be to decline updates that ConfigMgr expires based on the supersedence rules. I already have a UV item for this here: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/19709440-when-expiring-updates-based-on-supersedence-rules. To really make a difference though you have to go beyond just superseded updates and decline updates you will never deploy. A bunch of ways to approach that. The simplest is to allow users to manually decline from the console. A simple automated solution could be to mimic the supersedence process but for updates that haven't been deployed in X months since their released/modified date. More complex could be a reverse ADR of sorts that lets you decline certain category of updates (ex. Itanium, x86, Security Only). Literally anything that declines updates in WSUS would be a huge step forward.
152 votesstarted · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center Configuration Manager) responded
First preview of the hub is available in 1807 Technical Preview.
I would think there's other opportunities for this kind of thing beyond collections. Task Sequences come to mind. I mean, as much as I love trolling Neihaus's Twitter feed to figure out how to make Win 10 enterprise ready I'd rather crowd source.
Yes please! Microsoft's 'best' practice which is widely used is to run ADRs monthly and create a new SUG. There's no way to filter out just the updates released since the last time the ADR ran. 'One month' simply subtracts from the date's month value causing it to miss updates. For example. Patch Tuesday was on the 14th in November 2017 so 'one month' would miss updates release between the previous Patch Tuesday (October 10) and October 14h.
Yes please! It just seems incongruent with the app model to just pick the first deployment type.
One other addition. It would appear that while you can set the software update deployment package when you create an ADR with New-CMSoftwareUpdateAutoDeploymentRule you don't get it as a property when you use Get-CMSoftwareUpdateAutoDeploymentRule (the package ID is buried in the ContentTemplate) nor can you change it with Set-CMSoftwareUpdateAutoDeploymentRule.
Hmm, so just tonight I found that Set-CMSoftwareUpdateGroup seemingly got updated with some undocumented switches that look mighty interesting: ClearExpiredSoftwareUpdate, ClearSoftwareUpdate, ClearSupersededSoftwareUpdate. If those do what I hope they do that's great. Since there's no documentation I can't tell but if ClearSupersededSoftwareUpdate removes superseded updates it would be great if that was either configurable to only clear/remove updates older than X months. Bonus points for defaulting to whatever is configured for the software update component.
What's odd to me is that the software updates nodes allow you to select 'Content Size (KB)' but that data isn't populated.
This can also be caused by A/V that has the files locked. In such cases it would be ideal that SCCM retries the hash attempt a few times with a small delay.