Systems Center 2012 Orchestrator and PowerShell: Part 5

Doctor Scripto

Summary: Learn about cmdlets developed by the community for Orchestrator.

 Hey, Scripting Guy!

I was looking, and I could not find any cmdlets to manage Orchestrator. Can you nudge me in the right direction?

—KC

 Hello KC,

Honorary Scripting Guy, Sean Kearney is here continuing to fill in for Ed while he pokes around a binary tree to see if its leaves have changed.

So although there are no built-in cmdlets for Orchestrator at this time, there is a powerful following in the community. On CodePlex, there is a module that was developed by a member of the community that addresses this issue by leveraging the supplied web service from Orchestrator: Community Project for System Center Orchestrator (SCORCH) Integration Packs and Utilities.

All we have to do is download the module, import it, and play with the cmdlets it offers. When you download the module, it will come out as a .zip file. You’ll need to extract it, of course. I extracted mine to a Folder called C:\Scorch:

After you extract the structure, you will find a Windows PowerShell script called Deploy.ps1. Run this script within Windows PowerShell to install the module in your system. You need Administrative credentials to use this feature.

The module is now installed and registered as an available module. If you need to reload it, simply run:

IMPORT-MODULE Scorch

To get a list of cmdlets that are available, we can run the following command:

GET-COMMAND –module Scorch

The author has provided us with nine new cmdlets to manage our Orchestrator environment from Windows PowerShell. If you check further, there are also some sample scripts that show how to leverage these cmdlets.

All of these cmdlets request the URL for the web service. Our good friend has been kind enough to save us the typing. Simply use this cmdlet with the name of the Orchestrator server (of course, replace MYORCHSERVER with the name of your Orchestrator server):

$OWS=New-ScoWebserverURL –servername MYORCHSERVER

You can now leverage Windows PowerShell to perform tasks like identifying your runbook server:

(GET-SCORunbookServer –WebServerUrl $OWS).Server.Name

Or possibly, you want to list all the runbooks that are available:

GET-SCOMonitorRunbook –WebServerUrl $OWS | format-table

You can now externally start a runbook manually (without launching the Orchestrator Runbook Designer interface or relying on the schedule within):

$rb=Get-SCOMonitorRunbook -webserverURL $web | where { $_.Name -eq ‘Monitor Email’ }

Start-SCORunbook -webserverURL $web -RunbookGuid $rb.Id

Or possibly, you want to stop one:

$rb=Get-SCOMonitorRunbook -webserverURL $web | where { $_.Name -eq ‘Monitor Email’ }

$list=GET-Scojob –webserverurl $ows –alljobs

$RBstop=$list.job | where { $_.Job.Status –eq ‘Running’ –and $_.Job.RunbookID –eq $rb.RunbookID }

$RBstop | STOP-SCOjob –webserverurl $ows

Much like Windows PowerShell, Orchestrator has a powerful community following that is helping to enhance and build the product.

So there you have it…many of the bits, pieces, and catch 22s I’ve picked up for Windows PowerShell and Orchestrator. Hopefully with what I’ve passed along, you have a little more time to yourself each day knowing how easy you can leverage these technologies together!

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Sean Kearney, Honorary Scripting Guy
Windows PowerShell MVP

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow