PowerShell cmdlets need to be cleaned up
I use a LOT of PowerShell ... and the PowerShell modules in SCCM are ... well... bad.
Issue 1: I should not have to set my running location to a site to run a cmdlet. No one uses a set-location to make sure they are in the AD domain root before running a get-ADUser (unless they have a multi-domain environment and need to call something specifically), yet SCCM requires this to be true. It makes scripting needlessly complex.
Issue 2: there are a pointlessly large number of cmdlets. Do I really need a Get-CMDeviceCollection and a separate Get-CMUserCollection? Why can't I simply use "Get-CMCollection" with a -type switch that defaults to device? Once again: needless complexity when it comes to scripting because of this.
Issue 3: we need more cmdlets in general. There are good number cmdlets that have a "Get" without a corresponding "Set". That should just be a big NO NO, and I should reasonably expect to be able to set anything I get.
Justin King
shared this idea
Marking as completed per Adam’s detailed comments. File #3 issues specifically, we will fix.
7 comments
-
Anonymous
commented
They are still pathetic and broken since your post in June.
-
Stephen Owen
commented
@AdamMeltzer, do you have a list of what's changed in the new ConfigMgr cmdlets?
-
Matthew
commented
Issue 1 also causes problems for automating SCCM with service accounts, because the PSDrive provider does not create drives for SCCM sites until the service account has connected to the site with the Admin Console from the location where the scripts are running. That means that we must temporarily give the service accounts permissions to login to our site servers. Once it's setup, we limit the service accounts to login with PS remoting only.
It's a needlessly complex setup process just to run some PowerShell scripts as a service account.
-
Matthew
commented
Issue 1 really is clunky. I believe a better solution would have been to have a New-CMConnection cmdlet. Then you could do something like this:
$MyCMConnection = New-CMConnection -SiteServerFQDN 'sccmsite1.contoso.com'
Get-CMDevice -Name 'TestPC' -CMConnection $MyCMConnectionThat is pretty much how the SDK works today. There are enough gaps in the SCCM PowerShell cmdlets that I often have to use the SDK instead.
It would be nice if you could use the SCCM PowerShell cmdlets independently of the SCCM Admin Console.
-
Steven John Cuthill commented
Issue 1 is a pain, always thaught it was some legacy design issues.
Would like to see a lot more PS Client commands, to invoke any actions required needless complicated WMI scripts, would be nice to see pending advertisements all via native PS
-
Justin King
commented
Thank you Adam for your response here. I'll have to download the latest cmdlet library and see how things have improved.
I write a lot of DSC modules for SCCM to help regulate/control my collections and during that process have run into the list above, so it will be interesting to see how things line up (and if any native cmdlets have been introduced so I can simplify my own WMI calls).
Ill move further discussion over to connect as requested.
-
Thanks for the feedback. We're working hard to improve the cmdlets and if you haven't downloaded the latest version of the Cmdlet Library I would encourage you to do so. We plan to release regular updates to address the great feedback we've been receiving.
Your 3 concerns are probably better served as Connect feedback (as that ends up directly in our bug database and makes it easier to track requests like this) but I'll also try to address them here to close the loop.
Issue #1: Yes, this is unfortunate. It's basically the same in concept as how the admin console needs to be connected to a specific site rather than being able to perform "global" actions. It's definitely clunky but there's numerous technical reasons behind the current design and it's not something I see us changing any time soon. We do have work items to improve the PSDrive provider to make it much more functional than it is today.
Issue #2: We've been working on cleaning up and consolidating cmdlets where it makes sense. In our most recent release of the Cmdlets Library there is now Get-CMCollection and Remove-CMCollection that's meant to obsolete the User/Device-specific versions of those cmdlets (and in the spirit of Issue #3, we should probably also create a Set-CMCollection cmdlet as there's really no functional difference between Set-CMUserCollection and Set-CMDeviceCollection).
If you have ideas for cmdlets that can be consolidated -- or even cmdlets that should be split up as some can be way complicated I would strongly encourage you to leave this feedback on Connect.
Issue #3: I agree that this is wrong, and should never be the case. If are aware of specific examples of "Get" cmdlets that don't have a corresponding "Set", this should be raised on Connect so we can address it in a future release. There may be a case or two where a Get- cmdlet has no Set- companion because there's literally nothing to set and the Get cmdlet is used for pipeline purposes but this should not be a common scenario so I'm very interested in better understanding where these gaps are.
Thanks again for your feedback.
