System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

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.

2 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
bdam shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • bdam commented  ·   ·  Flag as inappropriate

    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.

  • bdam commented  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base