Copying Updated WinAutomation Databases for RPA With Azure Custom Script Extensions

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.

 

Microsoft Power Automate Flows_Part5_image 1

 

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.

 

Microsoft Power Automate Flows_Part5_image 2

 

Microsoft Power Automate Flows_Part5_image 3

 

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.

 

Microsoft Power Automate Flows_Part5_image 4

 

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.

 

Microsoft Power Automate Flows_Part5_image 5

 

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.

 

Microsoft Power Automate Flows_Part5_image 6

 

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

 

Microsoft Power Automate Flows_Part5_image 7

 

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.

 

Invoke-WebRequest
-uri "https://rpademoshare.blob.core.windows.net/rpa/Processes.dat?sp=r&st=2020-09-02T13:43:19Z&se=2021-07-21T21:43:19Z&spr=https&sv=2021-10-10&sr=b&sig= OOk3s%2FlR8UkyFoAzncJPTfpPiqOTTR9ev6vjsyJ2U%3D" -
outfile C:\Users\AzureUser\Documents\WinAutomation\Processes.Dat

 

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.

 

Microsoft Power Automate Flows_Part5_image 8

 

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.

 

#Service Principal Parameters
$Thumbprint = 'YOUR-THUMBPRINT-HERE'
$TenantId = 'YOUR-TENANTID-HERE'
$ApplicationId = 'YOUR-APPLICATIONID-HERE'

#Service Principal Authentication
Connect-AzAccount -CertificateThumbprint $Thumbprint -ApplicationId $ApplicationId -
Tenant $TenantId -ServicePrincipal

#Custom Script Extension with Storage SAS Authentication
Set-AzVMCustomScriptExtension -ResourceGroupName RPA-RG-Test -VMName RPA-TemplateVM -
Location centralus -FileUri 'https://rpademoblobshare.blob.core.windows.net/rpa/IWEX-ProcessDat.ps1?sp=r&st=2020-08-21T13:45:12Z&se=2021-08-21T21:45:12Z&spr=https&sv=2019-10-10&sr=b&sig=yoYwYJ0AdZOY%2B6%2Bm86K4Vdanvk6VMIsdeweusFsgWc%3D' -Run 'IWEX-ProcessDat.ps1' -
Name ProccessesDATExtension

 

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.

 

Microsoft Power Automate Flows_Part5_image 9

 

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.

 

Microsoft Power Automate Flows_Part5_image 10

 

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:

 

Microsoft Power Automate Flows_Part5_image 11

 

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

 

Get-AzVMExtension -ResourceGroupName "Resourcegroup" -VMName "VM"

 

The output would be similar to what is show here.

 

Microsoft Power Automate Flows_Part5_image 12

 

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.

 

Microsoft Power Automate Flows_Part5_image 13

 

Current Flow

 

Microsoft Power Automate Flows_Part5_image 14

 

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:

Dan Kiraly
Senior Research Analyst
Dan Kiraly is senior research analyst on Optiv’s partner research and strategy team. In this role he responsible for use case development and the vetting of security products for Optiv.