Update 10/19/2015 – The below blog post says “Hybrid runbook worker support for PowerShell runbooks is coming soon.” This is now implemented. Native PowerShell runbooks can now be run on hybrid runbook workers!

 

If you’re familiar with the Azure Automation service, you know it’s a wonderful tool for reliably automating all the manual, long-running, error-prone, and frequently repeated tasks needed to keep your IT infrastructure in the cloud and on-premises up and running. But you’re probably also aware Azure Automation doesn’t actually execute pure PowerShell, it executes PowerShell Workflow.

There are a lot of benefits to PowerShell Workflow. In addition to allowing you to leverage the semantics, modules, knowledge, content, and community around PowerShell, it also gives you access to the power of Windows Workflow Foundation. With Windows Workflow Foundation you have the ability to checkpoint, suspend, and resume your runbooks to better handle logic, environment, or network failures, as well as the ability to easily execute things in parallel or serially.

But, like with most things in life, you don’t get the good without the bad! While PowerShell Workflow is very similar to regular PowerShell, it does have some differences and limitations to allow for some of the additional features it adds. For example, wouldn’t it be nice if we could just take things we’ve already written as PowerShell scripts, or use only our existing PowerShell knowledge, and with just that get up and running in Azure Automation?

Well, today’s your lucky day. Azure Automation now includes another runbook type besides PowerShell Workflow and Graph – PowerShell. PowerShell runbooks have the same lifecycle, capabilities and management as other runbook types, but allows you to run native PowerShell in Azure Automation.

To get started using native PowerShell runbooks in your Automation accounts, just go to the Azure preview portal, select an Automation account, click Runbooks > Add Runbook, then either create a new PowerShell runbook or import an existing PowerShell script.

 

Just like other runbook types, PowerShell runbooks can use Automation assets, be hooked up to schedules and webhooks, and call runbooks inline. Hybrid runbook worker support for PowerShell runbooks is coming soon. Right now, you can only invoke inline PowerShell runbooks from PowerShell runbooks, and PowerShell Workflow or Graph runbooks from PowerShell Workflow or Graph runbooks. This may change in the future. In addition, you can always use Start-AzureAutomationRunbook to start a runbook of any type from your runbook, it will just be started as a separate job.

Invoking a PowerShell runbook inline from another PowerShell runbook also has a slightly different syntax than you’d use in PowerShell Workflow runbooks. To match local PowerShell:

PowerShell Workflow runbook

MyChildPswfRunbook –Parameter1 “Value1”

PowerShell runbook

.MyChildPSRunbook.ps1 –Parameter1 “Value1”

Let’s take it for a spin, shall we? As you can see, PowerShell runbooks can be edited in Azure Automation (or locally), just like their PowerShell Workflow brethren.

 

And not only do they run, they run, fast! Unlike PowerShell Workflows, which have a compile step whose time-taken scales as the size of the runbook and number of inline runbooks grows, PowerShell runbooks have no compile step at all since they are PowerShell, not PowerShell Workflow. The execution below, for example, went from start-button-clicked to running in five seconds!

 

You may be asking yourself, “Why should I ever use PowerShell Workflow runbooks again?” Yes, I can read minds. But I can also give you some good advice – while PowerShell runbooks are simple and fast, they don’t give you the unique functionality of PowerShell Workflow (namely, parallel, checkpoints, and suspend/resume). Without parallel, this means PowerShell runbooks can only execute commands serially. And without checkpoints and suspend/resume-ability, PowerShell runbooks can’t resume from any point in the runbook other than the beginning if they hit a logic, environment, network failure, or our fair share limit. Also, graph runbooks created with Automation’s graphical editor, let you visualize your process automation as you create it, test, and run it.

The choice of what types of runbooks to use is yours. There are definitely scenarios where each type of runbook is useful, now you have the power to make that choice. I’m very excited to be able to introduce this feature, and hope you're excited to learn about it.

Until next time – keep calm and automate on – with PowerShell runbooks!

Just getting started with Azure Automation? Learn about the service here, and follow Azure Automation on Twitter.