Running 2012 Configuration Manager SP1 PowerShell cmdlets from an Orchestrator Run .NET Script activity.

  • Article

Good day all – Quick blog here. With the recent release of 2012 Configuration Manager SP1 and the new Configuration Manager PowerShell cmdlets, the stage has been set for over the top Configuration Manager automation. This week I jumped on my first project involving the Configuration Manager PowerShell cmdlets and Orchestrator (Run .NET Script). All is well that ends well, however I ran into an issues when trying to execute 2012 Configuration Manager SP1 cmdlets from an Orchestrator Run .NET activity. Fortunately I've found some good resource that have help me get past this hurdle. In this blog posting I will be passing on these references, as well as extending on them just a bit.

Running 2012 Configuration Manager PowerShell cmdlets:

When running the 2012 Configuration Manager cmdlets from a new PowerShell session, two actions must first occur - the Configuration Manager module must be imported into the PowerShell session, and then the session must be changed to the Configuration Manager PSDrive.

  • To import the Module run the following – Import-Module <module path>\ ConfigurationManager.psd1
  • To change the PSDrive run the following – cd <Site Code>:
  • Finally we can run any one of the many Configuration Manager PowerShell cmdlets.

Each of these steps are demonstrated individually in the below screen shot.

Click Image for better view:

NOTE: For reference, run the cmdlet Get-PSDrive in order to see the PSDrive that was created when importing the Configuration Manager module.

Click Image for better view:

Now, if we would like to include any Configuration Manager automation into a larger script we can simply pile this together for execution. For example, the following script will distribute a package to a distribution point.

Click Image for better view:

This all works great from the native PowerShell environment. Unfortunately there is an issue when trying to run this same script, or any Configuration Manager cmdlet from the Orchestrator Run .NET Activity

The Issue and work around:

This issue with the Orchestrator Run .NET Script activity and the Configuration Manager PowerShell cmdlets has to do with the version of PowerShell that is being run. The Configuration Manager cmdlets require a PowerShell 3.0 environment while the Orchestrator Run .NET activity invokes a PowerShell 2.0 environment. When running a script from within an Orchestrator Run .NET Activity which includes the importing of the Configuration Manager PowerShell module, an error occurs.  

Click Image for better view:

Issue as seen from Runbook Tester (Click Image for better view):

Fortunately there is a very easy fix. The following two articles discuss the issue and fix in more depth.

Thanks to both Karl and Kwan for these posting.

Based on these two blogs we can see that basically the script need to be encapsulated with

$VAR = PowerShell {

<SCRITP GOES HERE>

}

For my example the fix would look like the following – sweet!!

Compare this screen shot to the one above (click Image for better view):

Preparing the Script for any Environment:

Finally to close this out and tighten it up a bit, the scripts that I have shown here have all used two pieces of content that will most likely differ from environment to environment. In order to make these scripts a bit more flexible / portable I would like to dynamically enumerate the location of the ConfigurationManager.psd1 module and also the PSDrive name.

For the module path we can use the SMS_ADMIN_UI_PATH environmental variables, making the import string as follows –

import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')

For the PSDrive we can use the following script. This script discovers the PSDrive created by the Configuration Manager module and then changes to that drive.

$PSD = Get-PSDrive -PSProvider CMSite

CD "$($PSD):"

The complete script in this example would end up looking like this:

Expanded View of the Run .NET Scrip properties (click image for better view):

And if we are being fair, the real brilliance of Orchestrator comes from storing and re-using data on the Orchestrator databus, so a more realistic view of what this script would look like as seen in the Run .NET Activity, would be the following. Here I am using published data which makes this particular script dynamic and re-useable.

Expanded View of the Run .NET Scrip properties (click image for better view):

Conclusion:

There is an amazing amount of automation possibilities between the 2012 Configuration Manager PowerShell cmdlets and System Center Orchestrator. Having the ability to execute these cmdlets natively in the Orchestrator Run .NET Script activity opens the door to this automation. As seen here, there is one gotcha when running scripts in the Orchestrator activity which requiring the importing of the Configuration Manager PowerShell module. However as can also be seen, there is a simple solution. Also seen in this blog, with the use an Environmental Variable and some additional simple scripting, we are in business with portable and reusable Configuration Manager automation.

I hope this post has been helpful – please check out my twitter feed for future updates to neilp: System Center PFE (Subscribe using the button found on this page).