When we on the product team create an integration pack for a product, whether it’s for System Center or another Microsoft products, or even a 3rd-party product, our goal is not to try and replicate everything that product does in the form of runbook activities. First of all, not everything a product does makes sense to try and automate because they might only be done once or twice in the lifetime of the installation. What we do is try to cover core scenarios with activities that help accomplish what data center admins need to do on a regular basis.
The second reason why we don’t do that is scalability. When our runbook activities are a combination of multiple actions on the target product, it requires new effort to develop and release each additional activity, and we simply cannot scale to provide quality integration packs that contain 50 or 100 activities, let alone cover the 466 PowerShell cmdlets available in the latest release of VMM.
This is why, in the integration packs for System Center 2012 Data Protection manager and Virtual Machine Manager, we include new activities for running free-form PowerShell scripts. These activities are designed to allow you the flexibility to do use any of the PowerShell cmdlets exposed by the product in a way that’s much easier to use than the Run .NET Script activity. These activities, “Run DPM PowerShell Script” and “Run VMM PowerShell Script” take advantage of their integration with the DPM and VMM IPs to offer some benefits over Run .NET Script:
- They re-use the connection configuration you’ve already specified for DPM or VMM, so you don’t have to expose any server names or credentials in a script.
- They automatically handle running the commands locally or remotely, depending on where your admin console is installed and specified in the connection settings
- When possible, they re-use existing PowerShell runspaces and connections to remote computers, improving performance and reducing the amount of connections into your remote computers.
- They allow up to 20 output variables to be published to the data bus simply by specifying the variable name on the properties page.
Using the activity is pretty simple. Just put your PowerShell script in the “PowerShell Script” property (I know, it seems obvious). Your script can be a single line command or it can be a full script. Hint – since the view limits you to a single line, you should always right-click and select Expand to get a bigger window to enter your script.
In this simple script, I’m just getting a VMM Server object and returning the Port property from it into a new variable called $portnumber. Then I just put portnumber as an output variable to enable publishing that value to the data bus.
Note: you can use “portnumber” or “$portnumber” and either one will work.
When I run the activity in the Runbook tester, I can see the property value is output to published data:
Wasn’t that simple? No longer will you have to create PSCredential objects and set up remote sessions and Invoke-Command. It’s all taken care of for you behind the scenes!
So when you’re using the DPM or VMM IPs and you need to do something that the IP doesn’t provide a discrete activity for, think of the PowerShell script activities in the IP and how those could be used to fill those gaps.