Running Powershell scripts in Azure Logic Apps workflows.

Few days ago the Azure Logic Apps team publicly released the preview of the inline PowerShell action, that permits you to embed PowerShell scripts directly into your Azure Logic Apps Standard workflows:

The new action allows you to write and execute scripts within the workflow designer, eliminating the need for additional services. The action supports dynamic content from previous steps and returns the results from your PowerShell code for use in subsequent actions.

This new action is helpful for automating tasks in Azure when different events occurs in other applications or services (for example when an event occurs in an Azure resource, in a business application like Dynamics 365 Business Central) or simply for executing scripts in a scheduled time.

Using the new Inline Powershell action with Azure resources is not an immediate task (I’ve spent quite a bit of time troubleshooting errors in this preview phase) and with this post I want to prevent you from having the same problems I had in being able to successfully execute a script inside an Azure Logic Apps workflow.

When you add the new Inline Powershell action in your workflow designer, it asks for a Powershell script:

In the code window you can paste your Powershell script to execute.

In this example, I want to automate the creation of a blob container in a given storage account, so I’ve used the following Powershell script I have in my personal gallery:

$resourceGroupName="YOUR_RESOURCE_GROUP"  
$storageAccountName="YOUR_STORAGE_ACCOUNT"  
$storageContainerName="YOUR_CONTAINER_NAME"      
 
## Function to create the storage container  
Function CreateStorageContainer  
{  
    Write-Host "Creating storage container.."  
    ## Get the storage account in which container has to be created  
    $storageAccount=Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName      
    ## Get the storage account context  
    $ctx=$storageAccount.Context      
 
    ## Check if the storage container exists  
    if(Get-AzStorageContainer -Name $storageContainerName -Context $ctx -ErrorAction SilentlyContinue)  
    {  
        Write-Host $storageContainerName "- container already exists."  
    }  
    else  
    {  
       Write-Host $storageContainerName "- container does not exist."   
       ## Create a new Azure Storage Account  
       New-AzStorageContainer -Name $storageContainerName -Context $ctx -Permission Container  
    }       
}   
  
CreateStorageContainer   

The Logic Apps workflow is designed as follows:

To be able to manage Azure resources by using a Powershell script, your Azure Logic Apps workflow must use a managed identity. With a managed identity, your logic app resource and workflow can authenticate and authorize access to any Azure service and resource that supports Microsoft Entra authentication without including credentials in your code.

In my case, the Azure Logic Apps must be able to access my storage account by using a managed identity. To do that, select the storage account (the Azure resource you want to manage), click on Access Control, then on Role Assignments and then add a new Role Assignment:

In the Add role assignment page, select a proper role (for example Contributor) and then on the Members tab select Managed Identity. Then in the Select members action, select All system assigned managed identities and then select your Azure Logic Apps instance:

Then to use the managed identity from your Powershell script code, include the following command at the beginning of your Powershell code in your Execute PowerShell Code action:

Connect-AzAccount -Identity

With this setup, your Powershell script is now able to use your Azure resources.

But despite after the managed identity setup, when I run the workflow for the first time it failed immediately with an Internal Server Error:

and it was quite tricky to discover what caused this problem (the workflow history gived no details on that). But going to the Azure Application Insights instance connected to this Azure Logic App, I discovered this:

Accordingly to the logged exception, it seems that the workflow is not able to execute the Azure Powershell cmdlets.

Why this?

A Standard logic app resource can support up to 10 public Powershell modules. To use any public module, you must enable this capability by going in your Azure Logic App resource and select Development Tools and then Advanced Tools.

On the Advanced Tools page, select Go. The Kudu Plus page will be opened. On the Kudu Plus toolbar, from the Debug console menu, select CMD:

Browse to your logic app’s root level at C:\home\site\wwwroot by using the directory structure or the command line and open the file named requirements.psd1:

In this file you need to include the name and version for the module that you want by using the following syntax: MajorNumber.* or the exact module version. In my case, I need to load the Microsoft Azure Powershell module (available here) and its latest version is 12.*, so I set the requirements.psd1 file as follows:

Please note that at the time of writing this post, managed dependencies currently don’t support modules that require you to accept a license, either by accepting the license interactively or by providing the -AcceptLicense option when you run Install-Module.

Now I’ve restarted the workflow and this is what happened:

The workflow now is in the Running state… and it remains in this state for quite a long time. Why?

Checking againg Application Insights, this is what is happening now:

The workflow is loading the Azure Powershell module for the first time… so it takes a bit of time.

You can see the loaded Powershell modules also in telemetry:

The first time the workflow is loading the Powershell modules, it takes minutes. But on the next runs, it takes only the needed time to provision the resources in the Powershell scripts (modules are not loaded anymore):

The Inline Powershell action now is executed successfully and at the end of the workflow execution I have my blob container provisioned as required:

The Inline Powershell action can retrieve parameters from the workflow trigger by using the Get-TriggerOutput command:

$triggerOutput = Get-TriggerOutput
$statusCode = $triggerOutput.status.ToString();

The action can also retrieve the output from another action in the workflow and returns an object named PowershellWorkflowOperationResult:

$action = Get-ActionOutput -ActionName <name of the action>
$actionOutput = $action.outputs['actionOutput'].ToString();

You can also use Write-Host, Write-Output or Write-Debug commands to log messages to Application Insights and you can also use the new Push-WorkflowOutput command to push outputs forward to subsequent actions. Here an example used in my workflow:

$customResponse = [PSCustomObject]@{

Message = "Container created successfully."

}

Push-WorkflowOutput -Output $customResponse

Hoping that this post will save you time on working with the new Inline Powershell action in Azure Logic Apps Standard. As said before, the action is currently in preview but executing Powershell in a Logic App workflow opens lots of interesting automation scenarios starting from now.

2 Comments

  1. Cannot tell you how much I appreciate this write up. I’ve been searching for days as to why all my Inline PowerShell scripts were failing at step 1 “Connect-AzAccount” with the same error as you, when it’s literally the first thing MS puts in their documentation to add at the beginning of your script so that your managed identity is configured before executing the rest of your script. My issue was the same as yours, where ‘Az’ = ’10.*’ was both commented out and on the wrong version number. After uncommenting and changing to 12 all of my scripts started executing properly. THANK YOU!

    Liked by 1 person

Leave a reply to demiliani Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.