Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 400 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
Copying Updated WinAutomation Databases for RPA With Azure Custom Script Extensions
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.
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
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:
Copyright © 2022 Optiv Security Inc. All rights reserved.
No license, express or implied, to any intellectual property or other content is granted or intended hereby.
This blog is provided to you for information purposes only. While the information contained in this site has been obtained from sources believed to be reliable, Optiv disclaims all warranties as to the accuracy, completeness or adequacy of such information.
Links to third party sites are provided for your convenience and do not constitute an endorsement by Optiv. These sites may not have the same privacy, security or accessibility standards.
Complaints / questions should be directed to Legal@optiv.com
November 04, 2020
Part four in the series: setting up RPA with WinAutomation.
How to upload WinAutomation screenshots to Azure Container Storage using Invoke-AzVMRunCommand – part six in a series.
How to use Power Automate flows and Azure runbooks to tear down Azure resources and reply to emails – Dan Kiraly explains in part 7 of the series.
Let us know what you need, and we will have an Optiv professional contact you shortly.