Microsoft Power Automate Flows, UI Flows, & Automation Runbooks: Part Five of a series

 

In part four of this series I touched on I touched on RPA with WinAutomation. In this post, I will explain how to use an Azure custom script extension to update a WinAutomation database on a newly provisioned virtual machine. As mentioned before, the flow action located in this blog proceeds the UI flow action mentioned in part four.

 

The last step in the creation of the test environment used for RPA is to copy a WinAutomation database file from an Azure blob to the newly provisioned virtual machine. WinAutomation keeps custom RPA processes within a local database on the machine where it was developed. This can be seen in the image below.

 

 

What would happen if I want to create new or update old processes? How would the newly created virtual machine know what the new instructions were? What would be an easy way to get them to the virtual machine that I wanted to execute my test automations against? Enter the Azure Custom Script Extension.

 

Custom script extensions are used to for post-deployment configuration of Azure virtual machines. There are a few different ways to create custom script extensions. When creating an Azure VM in the Azure console, the advanced tab allows the administrator to select a Microsoft-approved extension or select a custom extension.

 

 

 

In my case, I decided to write a custom script extension that used an Azure runbook under my automation account. Before I can write the custom extension, I need to store the supporting files in a blob container to be accessed by the virtual machine.

 

 

Under my storage account, I have a container designated for this project. I have uploaded the Processes.dat file, which is the WinAutomation database, as well as a PowerShell script named IWEX-ProcessesDat.ps1. The PowerShell script named IWEX-ProcessDat.ps1 performs a file download that overwrites the existing Processes.dat file on the virtual machine with the new one.

 

 

This is a private Azure container and each file request needs to be authenticated before a file read or download can be performed. To grant limited access to these files I created Shared Access Signatures (SAS) for each file. In order to create the signatures for each, I clicked on the file and then clicked Generate SAS.

 

 

I chose the appropriate start and end dates, times and the allowed IP. Each blob SAS URL was copied for later use.

 

 

The Blob SAS URL for the Processes.dat file was added to the PowerShell script that was stored in the container already. This can be seen in red in the command below. This will allow the virtual machine to download the Processes.dat file from the blob container. The downloaded .dat file will overwrite the existing file. This will allow me to run updated WinAutomation processes that were not created or previously stored on the new virtual machine.

 

 

With both files in the storage container and access allowed with SAS, I can write my custom script extension. I did this by going to my Azure automation account and creating a new runbook.

 

 

Below are the contents of the runbook. The first section contains the required parameters needed to authenticate as a service principal. The second section performs authentication via the Connect-AzAccount command. The final section contains the actual custom script extension. Parameters include, the resource group name, vm name, location, file URI, with any additional arguments and the name of the custom extension. The long file URI listed below is the blob container location of a PowerShell script named IWEX-ProcessDat.ps1. This can be seen in the first part of the URI. The second part of the string contains the SAS used for authentication, allowing the vm to download the PowerShell script. The -Run argument instructs the virtual machine to execute the script once it is downloaded from the container.

 

 

Below is an image of this custom script extension action being used in the flow as part of a condition. If the previous action was successful, then it will run the code above. If the condition is not matched, the original requestor will be notified, similar to the previous step.

 

 

When the runbook is executed, the custom script extension is executed and the virtual machine will execute the IEX-Process.ps1 file. This file will instruct the virtual machine to download the Processes.dat file from the storage container and overwrite the previous database file.

 

 

A virtual machine’s extensions can be found in the Azure console by drilling into in the extensions link on the left-hand column of a virtual machine. As seen below:

 

 

There are several ways to view Azure virtual machine extensions with Azure CLI or PowerShell. An example of using Get-AzVMExtension is listed below.

 

 

The output would be similar to what is show here.

 

 

It is worth mentioning that only one custom script extension can be applied to each virtual machine.

 

As a reminder, copying the updated WinAutomation database over to the virtual machines actually precedes the UI flow action outlined in part four of this blog series, but it is important to understand how WinAutomation works to understand why I needed to copy a new database file to the virtual machine.

 

 

 

 

As part of the robotic process automation performed by WinAutomation in part four of this series, screenshots were taken during workflow execution. In the next post, I will cover how I uploaded those screenshots to Azure container storage from a virtual machine that was created by an Azure Automation runbook without any human interaction.

 

---

Additional Information and Links:
Azure VM Custom Script Extension: https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows
Service Principal: https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Connect-AzAccount: https://docs.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-4.6.0
Shared Access Signatures: https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview#:~:text=%20You%20can%20sign%20a%20SAS%20token%20in,signed%20with%20the%20storage%20account%20key.%20More%20
Azure Automation Runbook: https://docs.microsoft.com/en-us/azure/automation/start-runbooks#:~:text=%20Start%20a%20runbook%20with%20the%20Azure%20portal,box%20for%20each%20parameter.%20For%20more...%20More%20

 

---

Here's a review of related posts on this series:

• Part 1: Using Microsoft Flows and UI Flows for Patch and Software Testing
• Part 2: Provisioning RPA Test Environments With Azure Automation Runbooks
• Part 3: Assigning Specific Public IP Addresses With Azure Automation Runbook
• Part 4: Robotic Process Automation with WinAutomation
• Part 5: Copying Updated WinAutomation Databases for RPA With Azure Custom Script Extensions
• Part 6: Uploading WinAutomation Screenshots to Azure Container Storage Using Invoke-AzVMRunCommand
• Part 7: Tearing Down Azure Resources and Replying to Emails Using Power Automate Flows and Azure Runbooks