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

  • Artykuł

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).

Comments

  • Anonymous
    January 01, 2003
    Pascal - thanks for the feedback and you are absolutely correct about the Configuration Manager and the Orchestrator runbook Server, in fact given the information here, the Configuration Manager console would need to be installed on each runbook server in the Orchestrator environment (in the recommended event that there are multiple runbook servers). I have since this post revised my strategy a bit and now use invoke-command or new-pssesson so that I can run the ConfigMGR cmdlets directly a site server or other machine which possess the Configuration Manager module, allowing me to work around the need of having the console loaded on all of my runbook servers. Thanks again neilp

  • Anonymous
    February 07, 2013
    Awesome blog!  Thank you for some excellent info.

  • Anonymous
    June 26, 2013
    Hi Neil, thanks for this great post! Maybe it is worth mentioning that you need to install the SCCM Console on the Orchestrator Server! Further: you should know, that when you have installed the Orchestrator Integration Pack for SCCM, the SCCM Console does not start up any more and the CMDLets won't work anymore. Which means: you need to choose if you use the Integration Pack or the PowerShell CMDlets (i would always go PowerShell regarding Performance) best regards, Pascal

  • Anonymous
    June 27, 2013
    Hej Neil, thanks for your fast response! Remote-PSSession was also my first thought and i also implemented it which worked fine from PowerShell ISE (x86) from the SCO Server. But in SCO .NET Activity it wouldn't work. I just thought maybe it is a limitation of the .NET Activity so I tried the way you described in this post which led me to my issue with the IntegrationPack/SCCM Console. Because of your post i investigated my Remote-PSSession solution further and found the solution why the import-module would create the virutal CMSite Drive... The thing is: you need to login to the SCCM Server with the SCO Service account and start the SCCM Console once. During the first start of the SCCM Console the RegKey ConfigMgr10 will be created underneath HKCUSoftwareMicrosoft After i started the SCCM Console with the SCO User on the SCCM Server everything went smooth :) I think these learnings scream for a new blog post describing the remote powershell solution its prerequisites and pitfalls. Also a comparison of the two strategies would be helpful for a lot of other System Center folks :) Cheers, Pascal

  • Anonymous
    September 23, 2013
    The comment has been removed

  • Anonymous
    September 23, 2013
    Thank Youuuuuuuuuuuuuuuuuuuuuuuuuuuuu.... VERY helpful.

  • Anonymous
    November 14, 2013
    Excellent Blog

  • Anonymous
    June 21, 2014
    Thanks!!!!

  • Anonymous
    October 20, 2014
    If the SCCM console is not installed on the Orchestrator servers, I found that as the modal you are importing (ConfigurationManager.psd1) is singed, I needed to install the certificate into the user account being used in the Power Shell script.