Skip to main content

PowerShell + SCCM 2012 : Get Started with CM Cmdlets

This post will quickly cover on how to start using PowerShell with ConfigMgr. It's good to see that ConfigMgr Admins are finally embracing the Shell :) 

Planning to have one of these getting started hangouts for PowerShell Bangalore User Group (@PSBUG) in near future.

There are essentially two routes:
  1. Using ConfigurationManager Cmdlets
  2. Using WMI/CIM (next post probably)

Using ConfigurationManager Cmdlets

ConfigMgr starting from 2012 SP1 has got the official PowerShell support, which means when you install the ConfigMgr console on a machine then you will get a PowerShell Module along with it in the below location :

<drive>\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin

Don't worry you don't have to remember this. There is an environment variable SMS_ADMIN_UI_PATH which holds this piece of information for you (Note the path we need is till bin folder only ) 

The best way to get the CM cmdlets (the cmdlets are prefixed with CM) is to open the the ConfigMgr Console and click on the top left "Connect via Windows PowerShell"

After that you should get a prompt like below if you are doing this the first time:

Select "A" (Always Run) to trust the MSFT Code Signing Cert for the User. 

Accepting the above creates MRU key for the User , see below is the MRU key created for me :

After the first run (trusting the Code Signing Cert from MSFT) one can use the normal PowerShell console to load the Module in below way :

#Load the ConfigurationManager Module
Import-Module -Name "$(split-path $Env:SMS_ADMIN_UI_PATH)\ConfigurationManager.psd1"

Now this has been fixed in ConfigMgr 2012 R2 CU1 . Read this question at Technet for more details.

One can also install the certificate for the local machine (for different Automation scenarios) using the below PowerShell function by Tore Groneng

function Import-SCCMmoduleCert
   Imports the signed certificate used in the SCCM module into the certificate store on the local computer
   Requires administrative privileges to run. Run the function as the user that will have the cert
   imported. The function accepts no parameters and does not return any output.
    Created by Tore Groneng @ToreGroneng



    Write-verbose "Start $($MyInvocation.MyCommand.Name)"
    $sccmModulePath = "$(Split-Path $env:SMS_ADMIN_UI_PATH -Parent)\ConfigurationManager.psd1"

    Write-Verbose "Module path is $sccmModulePath, getting cert"
    $cert = Get-AuthenticodeSignature -FilePath "$sccmModulePath" -ErrorAction SilentlyContinue

    Write-Verbose "Creating a store object for LocalMachine\TrustedPublisher"
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("TrustedPublisher","LocalMachine")

    Write-Verbose "Adding cert to store"

    Write-Verbose "Done"

Now the whole CM Cmdlets are there for you to explore. All the PowerShell concepts apply here with only gotcha --> one has to Set the present location to the CMSite Drive before using the CM cmdlets .

In the next post will cover on how to use PowerShell & WMI  (ConfigMgr Context)

Below is an animated GIF to show this in action:

Resources :

ConfigMgr Scripting With PowerShell Module - Tore Groneng

How to Use Scripts with ConfigMgr PowerShell cmdlets - David O'Brien

Popular posts from this blog

PowerShell + .psd1 files - decouple environment configuration data from code

What is environment configuration data?
Well, you might have heard the term 'configuration data' in usage with PowerShell DSC. The case for using configuration data is wherein all the input arguments are abstracted from the code being written so that this configuration data can be generated on the fly and passed to the underlying scripts or framework like DSC.

For some of our solutions being deployed at the customer site, we require a lot of input parameters e.g. different network subnets for management and storage networks, AD/DNS information etc.

Adding all these parameters to our input argument collector script was an error prone and tedious task since there were far too many input arguments. So instead of having a file to specify all input arguments was the preferred method.

This also helped us while troubleshooting the deployments since a local copy of the input arguments always persisted.

PowerShell + SCCM : WMI Scripting

Why should I use WMI, when there is a PowerShell module available for Configuration Manager (CM Module) already?

Well the cmdlets behind the scene interact with the WMI layer and if you know which WMI classes the corresponding cmdlet work with , it can be of help in future by :

Switching to native WMI calls when the CM cmdlets fail for some reason (probably bug in the CM Module).Making your scripts more efficient by optimizing the WMI (WQL query) calls, the cmdlet will query all the properties for an Object (select *) you can select only ones you need. Lastly no dependency on the CM Module, you can run these automation scripts from a machine not having the CM console installed (needed for CM module).Moreover ConfigMgr uses WMI extensively, you already have this knowledge leveraging it with PowerShell shouldn't surprise you. This post assumes you have been working with CM cmdlets (you already are versed with PowerShell), know where the WMI namespace for ConfigMgr resides and the basi…

Az.ResourceGraph - Search across all Subscriptions

Azure Resource Graph is an amazing tool in the belt of Az Ops team. It allows to quickly search across all your subscriptions (does it?).

Started using Az Resource graph with that pretext that the queries I ran will be run against all the subscriptions I have read access to, Yes it will but there is a catch here!

I mostly use Az.ResourceGraph PowerShell module (Why? another post)

Found the solution by digging into the source code for the Search-AzGraph cmdlet, if the subscriptions are not specified explicitly then the cmdlet uses a method named GetSubscriptions()

Below is a snippet of the method def:

The catch is that if no subscriptions are supplied it defaults to subscriptions in the default context. I am not really sure but some of the subscriptions which I can see when running Get-AzSubscription were missing when I ran the below:


So, the trick is to set the PSDefaultParameterValues for the Search-AzGraph cmdlet to include all the s…