PowerShell CmdLets: Improvement for Software Update Maintenance
Paging Adam Meltzer.
I’ve spent the last couple of weeks writing a PowerShell script to provide end-to-end maintenance of software updates. My goal was to use the CM cmdlets as much as possible. While I think I have everything working the experience leads me to make the suggestions below. In all honestly; maybe I’m just doing it wrong and there is a way to do the things I couldn’t figure out.
The documentation for Get-CMSoftwareUpdateDeploymentPackage says that it returns a CMSoftwareUpdateDeploymentPackage object but it’s actually returning WqlResultObjectBase. Maybe I’m just supposed to cast it but I failed trying.
I could not find a way to map a given update to the update groups (SUG) that it was a member of.
I could not find a way to map a given update to the deployment package that it was part of.
I could not find a way to map a given deployment package update to its subfolder in the source directory and had to rely on a WMI query on SMS_PackageToContent.
There appears to be no Remove-CMSoftwareUpdateFromDeploymentPackage cmdlet. So even if I could figure out what deployment package an update is in I’m not sure I could remove it.
It would be beneficial to have Remove-CMSoftwareUpdateFromGroup support an -All flag that intelligently removes all SUG memberships. Currently I forced wildcard handling and passed it ‘*’ for the SUG name. It works but is super inefficient as it tries to remove it from every SUG rather than just the ones it’s a member of. That’s a problem that scales by the number of SUGs. This would be alleviated if I could determine SUG membership and selectively remove.
Lastly, the Get-CMSoftwareUpdatePointComponent, Get-CMSoftwareUpdatePoint, and Get-CMSoftwareUpdatePointComponent cmdlets don’t have direct properties like their Set counterparts. You’re forced to parse a props array and figure out which of the value members.
Again, maybe I’m just doing it wrong in which case feel free to simply that out.
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.