Update 5 – 12/7/2015 – We have started shipping the Azure Resource Manager PowerShell modules out of the box in Azure Automation. This blog post is now out of date, please refer to this blog post instead.
Update 1: Currently there is a bug preventing authentication to Azure Resource Manager from Azure Automation runbooks using service principals. You can follow the bug status here, but in the mean time user principals should work fine.
Update 2: If you are having issues importing the ARM module from the Azure portal due to module size limits, the best workaround until we increase the limit is to remove folders from the module that correspond to services you aren’t going to use, until the module is small enough to import, and then to remove the references to these folders from the module’s .psd1 file. Update 3 – 10/13/2015 – This should now be fixed.
Update 4 – 10/13/2015 – The Azure PowerShell team has updated the Azure PowerShell modules to work side by side, allowing their use side by side in Azure Automation. We will soon ship the new Azure PowerShell modules out of the box as global modules in Azure Automation, but until then instead of following the directions in this blog post to set up a seperate Automation account for ARM cmdlet use, you can follow the directions here to use the Azure (Service Management) and Azure (Resource Manager) modules side by side in a single Automation account.
Due to the many exciting capabilities of Azure Resource Manager (ARM), many customers are asking how they can take advantage of ARM PowerShell cmdlets within Azure Automation runbooks.
Currently, the Azure (Service Management) PowerShell cmdlets and the ARM PowerShell cmdlets do not work side by side within an Azure Automation account. For this reason, the current best practice for using ARM cmdlets in Azure Automation is to set up separate Automation accounts, one for ARM and one for Azure PowerShell. When your processes involve both ARM functionality and Azure Service Management functionality, you can have runbooks in one Automation account start runbooks in the other Automation account using the Start-AzureAutomationRunbook cmdlet (available in both the Azure and ARM PowerShell modules).
Details on how to set up an Automation account to use the ARM PowerShell module instead of the Azure PowerShell module are below, but I want to also point out that this is just a temporary way to allow the use of both Azure Resource Manager and Azure Service Management functionality in Azure Automation. An easier, long-term solution where both modules can be used side by side in a single Automation account is coming – you can find the details on that proposal here. This proposal involves changes to the Azure PowerShell cmdlets, so please feel free to contribute to the discussion already started here if you have any feedback.
Now, on to the way to use Azure Resource Manager cmdlets in Azure Automation, today!
Setting up Azure Resource Manager in Azure Automation
Azure Automation does not currently ship with the ARM cmdlets by default, but you can easily import them yourself. In Azure Automation, your runbooks are run in secure sandboxes which differ from your local environment. Additionally, in order for a runbook to compile, all the modules must be loaded, and cannot be unloaded after compilation. Because of this, if you import the Azure Resource Manager module as is, both the Azure module and the Azure Resource Manager module will be loaded in every runbook job’s PowerShell session. For this reason, the Switch-AzureMode cmdlet is not needed in Azure Automation like it is in local PowerShell, and in fact, the cmdlet will not work.
The Azure module and the ARM module are currently not built to run in the same PowerShell session, and running them in the same session can cause conflicts and unexpected behavior. Therefore, the current best practice is to set up separate Automation accounts, one for ARM and one for Azure PowerShell. Here’s how:
After creating a separate Automation account meant for Azure Resource Manager functionality, you’ll need to import the Azure Resource Manager module in such a way that it will overwrite the global Azure module we ship in each Automation account by default.
- Install Microsoft Azure PowerShell on a local computer
- Navigate to the Azure PowerShell directory where the ARM PowerShell module has been installed – typically C:Program Files (x86)Microsoft SDKsAzurePowerShellResourceManager
- Copy the AzureResourceManager folder to your Desktop
- Rename the AzureResourceManager folder you just copied to “Azure”
- Rename the module manifest in this folder from “AzureResourceManager.psd1” to “Azure.psd1”
- Zip up the newly renamed Azure folder. It should have the name “Azure.zip” and contain a single folder named “Azure”
- In the Azure portal, import the zipped module into the Azure Automation account you want to use ARM (and not Azure Service Management) functionality from
- Navigate to Assets, then Modules, and then select “Import Module” (the button is instead called “Add a module” if you’re in the Azure preview portal)
- If prompted, override the existing Azure module by clicking “Yes”
- Give the module some time to import and get extracted.
- When you drill into the “Azure” module, you should now see that the module is no longer the global Azure (Service Management) module, but instead the Azure Resource Manager module!
Huzzah! Now that you have the Azure Resource Manager module imported into a new Azure Automation account, you can use any of the ARM cmdlets in your runbooks in the same way as you would use them in the PowerShell ISE (except you don’t need to use Switch-AzureMode). If you need to use ARM functionality from your Azure (Service Management) Automation account, simply use the Start-AzureAutomationRunbook cmdlet in the Azure module to start a runbook in your ARM Automation account. Similarly, if you need to use Azure Service Management functionality from your ARM Automation account, simply use the Start-AzureAutomationRunbook cmdlet in the ARM module to start a runbook in your Azure (Service Management) Automation account. Don’t forget, Azure Resource Manager doesn’t support certificate authentication like Azure Service Management does, so you’ll need to use an Azure AD user or service principal to authenticate to Azure Resource Manager.
Just getting started with Azure Automation? Learn about the service here, and follow Azure Automation on Twitter.
Want to get in contact with me, personally? Reach out via my blog or follow me on Twitter.