SCCM and PowerShell

Comments None

I remember when I first started using SCCM about four or five years ago, I was delighted to learn there was a built-in PowerShell module. But then the more I used it the more it left me wanting. It seemed that each time I searched for solutions to common tasks, most of them relied on WMI queries and didn’t even bother with the first-party module.

This would frustrate me to no end, as there was this massive first-party module available to admins, but all these scripts and functions people provided that boiled down to figuring out the best WQL queries (a simplified SQL syntax). Well, I’ve come around on my thinking on this for several reasons.

First, my initial hesitance was largely based on my past experiences using Get-WMIObject and Get-CIMInstance: it’s often really, really slow. When writing deployments with the App Deployment Toolkit, I would run Get-WMIObject Win32_Application and then lock my screen and go get a cup of tea. (Side note: the ADTK has a built-in function that looks in the registry which is much faster and more convenient.) But, as it turns out, WMI queries against SCCM are pretty fast, even if you’re pulling large sets. In fact, I need to search further, but I would not be surprised if the ConfigurationManager module itself heavily relies on WMI.

Second, I was just really annoyed that people were ignoring a perfectly good module that everybody has. This was my own lack of experience with working in enterprise IT. SCCM 2007 had no PowerShell support, and 2012 didn’t receive it until SP1. Since then, in current branch, the support has only been better. But… most admins don’t have the luxury of updating to the latest branch every time they feel like it. Changes come slowly, especially if everything currently works. We as admins always want to lay the foundation for a brighter, easier to administrate future, but there’s this thing called change management. The nice thing about the WMI scripts and utilities people have written is they tend to be pretty backward compatible, versus relying on CMDlets or features only available since, say, 1710.

Third, and finally, I didn’t realize that even hundreds of first-party CMDlets aren’t going to cover all of the bases. There are a lot of edge cases, that may be commonplace for some environments, that the official module can’t fully support. For instance, if you need to know the distribution status of all of the references for a task sequence, that’s going to require looking beyond the official module.

Once I got past these prejudices, as so often happens, I learned a lot about both WMI and SCCM, and gained competencies I probably wouldn’t have previously. And to be honest, that’s the most satisfying work for the scripting administrator, isn’t it? Work done; knowledge acquired.



There are currently no comments on this article.


Enter your comment below. Fields marked * are required. You must preview your comment before submitting it.

← Older Newer →