Announcing PowerShell v5 support in Azure Automation

As you probably already know, PowerShell version 5 has been released, and with it, a number of new PowerShell features. Some of the most exciting features include:

• PowerShell classes
• PowerShell Workflow performance improvements
• PowerShell module side-by-side versioning
• A whole bunch of new cmdlets (ex. Convert-String)
• A whole bunch of PowerShell DSC improvements (ex. PSRunAsCredential)

And now, you can take advantage of these same great PowerShell v5 features in your runbooks and DSC configurations in Azure Automation!

There’s no work on your part to use PowerShell v5 features in Azure Automation – but if you use hybrid runbooks workers and want to take advantage of PowerShell v5 features in runbooks you run on them, make sure you install WMF5 on those hybrid worker machines.

Let’s walk through how you’d use some of the new PowerShell v5 features in Azure Automation.

PowerShell classes

PowerShell classes introduce object-oriented programming to PowerShell, making it easy to define new types of objects, instantiate them, and call methods on them.

Use of PowerShell classes in Azure Automation can now be done exactly like in PowerShell v5. Take this native PowerShell runbook for example:

class Coffee {
    # Property: Holds the current size of the coffee.
    [Uint32] $Size;
    
    # Property: Holds the name of the coffee's owner.
    [String] $Owner;

    # Constructor: Creates a new Coffee object, with the specified size and owner.
    Coffee([UInt32] $NewSize, [String] $NewOwner) {
        # Set the Coffee size
        $this.Size = $NewSize;
        
        # Set the Coffee name
        $this.Owner = $NewOwner;
    }

    # Method: Drink the specified amount of coffee.
    # Parameter: $Amount = The amount of coffee to drink.
    [void] Drink([UInt32] $Amount) {
        $this.Size = $this.Size - $Amount;
    }
}

# Create a new coffee object, with a size of 16 ounces, and 'Joe' as its owner
$MyCoffee = New-Object Coffee -ArgumentList 16, "Joe"

# Drink 10 ounces
$MyCoffee.Drink(10)

# Output the object
$MyCoffee 

Testing this in Azure Automation returns the following:

PowerShell classes can be used in PowerShell Workflow based runbooks as well, but only within an InlineScript block.

PowerShell module side-by-side versioning

PowerShell side-by-side module versioning allows you to use more than one version of a module within PowerShell. This can be useful if you have some older scripts that have been tested as working against a certain version of a PowerShell module, but other scripts that demand a newer version of the same PowerShell module.

Constructing PowerShell modules so they contain multiple versions is easy. You simply create the module folder as usual, and then create a folder within this module folder for each version of the module you want to be usable. Here’s an example of that for a module TestModule I just created. As you can see, it provides two versions, 1.0.0 and 2.0.0.

Within each of these “version folders,” you simply put the usual PowerShell PSM1, PSD1, and DLL files that make up a module. Here’s what it looks like for version 1.0.0 of the module I created.

Of course, if you’re going to use this module within Azure Automation, you need to zip it up in order to import it. More info on PowerShell module use in Azure Automation can be found here.

Once you’ve zipped up and imported the module, it will show up like any other module within Azure Automation:

Note: While Azure Automation will only show that the latest (highest version number) version of the module is imported, if the module package contained side by side versions of the module, they are indeed all usable within your runbooks. But the UI will not show earlier versions of the module in that same package, currently.

Note #2: While we do support modules containing side by side versions within the same package, we do not support using multiple versions of a module across module package imports.

For example, if you imported module A, containing versions 1 and 2 into Azure Automation, and then later module A, containing versions 3 and 4 into Azure Automation, only versions 3 and 4 will be usable within any runbooks of DSC configurations. If you wanted versions 1, 2, 3, and 4 to be usable, the package you import should contain versions 1, 2, 3, and 4.

Once the module containing side-by-side versions is imported, you can load a specific version as follows:

PowerShell script runbooks:

Import-Module –Name -RequiredVersion

PowerShell Workflow runbooks (within an InlineScript block):

Import-Module –Name -RequiredVersion

DSC configurations:

• DSC Resource use:

Import-DscResource -ModuleName -ModuleVersion

• Module use:

Import-Module –Name -RequiredVersion

Just like in the UI, by default the latest version of the module will be used at runtime. For example, my TestModule module contains a cmdlet called Get-MyVersion that outputs its module version. The following runbook:

Get-MyVersion

Will output:

But if I explicitly load version 1.0.0 of the module in my runbook:

Import-Module –Name TestModule -RequiredVersion 1.0.0

Get-MyVersion

It will output:

To be safe, if you’re going to use different versions of the same module between runbooks, you should always declare the version you want to use in your runbook via Import-Module. Even if the version you want to use is the latest version. This is because jobs of your runbooks may run in the same sandbox. If the sandbox has already explicitly loaded a module of a certain version number (because a previous job in that sandbox said to do so), future jobs in that sandbox will not automatically load the latest version of that module (because some version of it is already loaded).

Summary

As you can see, PowerShell v5 has many great new features. Now these features can be taken advantage of in Azure Automation!

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