vRealize Automation 8.1 – Using Custom Resources to Execute Scripts along with Deployments

Recently I published a blog about the Custom Resources feature within vRealize Automation, you can review that blog here.

Custom Resources was introduced in vRealize Automation 8.1 (it was in our SaaS version first, but we will focus on-prem version of vRealize Automation for now). This feature provides a method to expand the capabilities of a blueprint.

In this blog we will take the concept of Custom Resources up a notch (or two). If you read my previous blog you would know that Custom Resources call existing vRealize Orchestrator workflows and then you can drag those onto the blueprint canvas. This is a powerful method by which you can greatly customize your deployments because you will not be limited to the existing resource types (e.g. – cloud machines, networks, native cloud services).

However what if you wanted to not just use existing vRealize Orchestrator workflows but also run custom scripts as well and pass those to the virtual machine during deployment. What if those scripts could customize your OS, call a 3rd party system, or even deploy software on the machine via PowerShell or bash (and python!) during the deployment. Well it is possible, and in this blog I will show you how to do just that, deploy a machine and run custom scripts via the Custom Resource object.

Before we begin let’s go over some of the pre-requisites for using custom scripts with Custom Resources:

  1. vRealize Automation 8.1
  2. VMTools installed on the image
  3. vSphere Machines only (no multi-cloud at this time)
  4. Must download and import custom vRO Package (link is in the vRO section below)
  5. Working install of vRealize Lifecycle Configuration Manager (installs with vRealize Automation 8.1)
  6. Single Machine Deployment

Let’s dive in on how this works. First we need to configure vRealize Suite Lifecycle Configuration Manager to store template and vCenter credentials.

Note – if you need to see a larger version of the images below, just click on them and it will pop out. 

Configuring vRSLCM:

The current means to store passwords for vCenter and the images used for deployment is the Locker feature in vRSLCM. Since vRA 8 deployments contains vRSLCM it is an easy integration and logical choice for password store.

  • Log into vRSLCM instance that was deployed with vRA and click on the Locker section.



  • Navigate to Password section and click Add button.




You will need to add 3 entries:

  1. vCenter Credentials (if you have multiple target vCenters for deployments just add an entry for each vCenter).
  2. Windows Template Credentials (if you plan to use a Windows template)
  3. Linux Template Credentials (if you plan to use a Linux template)

vRealize Orchestrator Updates:


vRealize Orchestrator(vRO) plays an important role since Custom Resources relies on underlying vRO workflows and actions. First we need to import a package that contains the necessary actions and workflows needed to run the scripts on the deployed machine. The workflow does a number of tasks like wait for VMtools to load, authenticate to vCenter, run the software script, etc. The main wiki page has more detail on this workflow elements.

Before starting the procedures below, download the vRO Package.

*Update – I updated the vRO Package with the following:


  1. Modified the “run script” action to output verbose logging.
  2. Software-Install-Base workflow now has a variable called “sleepTime”, this variable is part of the “Improved Sleep” workflow that is part of the schema. This basically allows for a delay. By default the delay occurs before VMTools and may be useful with Windows machines which may need some extra time for VMTools to instantiate. However this could be moved around to other areas of the workflow.
    • If you want to make “sleep” an input (added to schema) so it can be changed in the vRealize Automation blueprint then that can be done. This allows you to modify the sleep time per blueprint, sometimes you may need a longer sleep time for certain situations.
    • To do this edit the “Software-Base-Install” workflow and delete the sleep variable from Variables tab.
    • Go to Inputs tab and add an input called “sleep” and type = number.
    • Click on the schema tab and click on the “Improved Sleep Workflow” and go to the inputs section on the right side. Set “delay” to “sleep” input you created.
    • Save the workflow

Now you will see a “sleep” property in the blueprint and can be modified with a sleep timer.

Configure vRealize Orchestrator:


Click on the vRealize Orchestrator tile on the main vRA page


  • Navigate to Assets > Packages > Import Package

Import the package that you downloaded.



  • Click the Trust button


  • Click the Import button


  • After the import go to Assets > Packages you will see the tile with the package name

  • Change to tree view if required and navigate to Workflows > Library > Dynamic Types > Configuration > Import Configuration from Package then click the Run button


  • From the Import Configuration from Package screen click Browse to find the package file you downloaded earlier (same package as step 2).


  • Click the Run button (The page may not update immediately after clicking Run)


The next screen will show the progress of the Import Configuration From Package workflow run. Ensure you see a green Completed status at the top of the page.

  • Click Close button (lower left part of screen)



  • Navigate to Administration > Inventory in the Inventory pane select the twistie for Dynamic Types and then expand CustomScript > Scripts. – Verify that you see the Script entry. 





  • Navigate to Workflows > Remote-Exec and confirm that you see the Custom Script folder, Day2-Action-Example & Software-Install Base workflows. – Verify that you see the workflows.


  • Navigate to Assets > Configurations and check for a tile called CustomScripts.




  • Navigate to Workflows > Remote Exec > Custom Script > Software Install Base > Variables. Click the Edit button at the top of the page.
  • Click the Variables tab and edit the following variables by clicking on them:

                lcm_pass – lcm admin password

                lcm_user – lcm admin (might be admin@local which is default)

                lcmfqdn – FQDN of LCM instance


Creating the Custom Resource in vRA:

In this section we will configure the Custom Resource object in vRealize Automation Cloud Assembly section. The Custom Resource object will be used during the creation of the blueprint to allow us to input the script and then pass to vRO.

  • Navigate to Cloud Assembly


  1. Navigate to Design > Custom Resources and click the button New Custom Resource




  • Name: Provide a Name for the Custom Resource (display name only)
  • Resource Type: Enter a Resource Type name, this is a custom name that will identify the resource in the YAML code (display name only in YAML)        
  • External Type:  DynamicTypes:CustomScript.Script  (this must look exactly like it is posted here, or you will see “null” errors when deleting a deployment)
  • Activate: Click the slide button
  • Scope: Keep the Scope to default if you want the custom resource to be available to all Projects or you can limit the scope to a project
  • LifeCycle Actions:
    • Create Workflow should be “Software-Install-Base”
    • Do Not Enter a Update workflow at this time
    • Delete Workflow should be “Delete Custom Script”

You should now the see schema items in the upper right corner of the screen (e.g- reboot, scripts, vcfqdn etc.)

  •  Click Create




Creating a Linux Blueprint for a mySQL Deployment:


Within vRealize Automation Cloud Assembly you will need to create a blueprint that will deploy a vSphere Virtual Machine and then the Custom Resource object will need to be configured with the script that needs to run. In the examples below we will show how to install MySQL on a Linux machine and MSSQL on a Windows machine. First let’s explore the MySQL deployment.


  • For the MySQL example below we are using Ubuntu-18 that has cloudinit. We are using cloudinit in the blueprint not for the software deploy but to configure a username/password. CloudInit may cause the OS to stall or lock upon boot and the software script may not run, so we added a second custom resource object in the blueprint to do a “reboot” of the the OS before we run the software custom resource.


  • Go to Cloud Assembly in vRealize Automation
  • Navigate to Design > Blueprints and click the +New button to create a new Blueprint.


  • Name the New Blueprint and assign to a Project


  • Drag and Drop a vSphere Machine onto the Canvas, optional network.

You can use the YAML code in the example as a basis for your machine or modify it. You do not need to copy the code exactly for instance the network is optional since we are not pulling anything down from a repo. The script gets run directly on the machine.



  • Scroll down to the bottom of the Resource Type list on left hand side of canvas until you see Custom Resources. (You may need to refresh the list if the new custom resource doesn’t appear)


  • Drag and Drop the custom resource you created onto the canvas


Next lets review the Custom Resource object.

  • Click the Custom Resource > Properties > Show all Properties

Take note of the properties, these all need to be populated with some value.

  • See the Configure Properties section below for instructions on configuring the properties.



Configure Properties:

Count: 1

Reboot: If you need to reboot check the box, if you leave blank then this will not populate in the YAML code, so please enter the reboot property into the YAML code if you left it blank. Here is an example of the code:




Script: Copy / Paste Script (See instructions below on how to copy/paste script)

vcfqdn: Enter name of your vCenter

machinename: this will be the VM on the canvas (e.g. ${resource.MySQL_Server.resrourceName}

vc_cred_name: Locker Credentials that were created for vCenter authentication

template_locker_creds: Locker credentials that were created for the template

Instructions on how to copy/paste script.

Our script will be pasted into the Script section. But the first line needs to have a | symbol like we would see when we pipe code via the main YAML editor. Here is an example:




Just like in the main editor there two spaces on lines 2 – n, except where you may need additional indents for the code.

The code we are using to install mySQL is available in the column to the right if you are interested in using that.

Note: if you want to configure via the YAML code instead of Properties pane, then just delete the {} after properties under the custom resource. Then hit enter on the next line and you will see the dropdown with the properties that need to be configured.



Your screen may look something like that at this point:


For this example I am going to add another custom resource to the canvas simply to send a reboot to the OS before the other custom resource with the software script runs. You may nor may not need to do this depending on your image.

I am doing this because cloudinit seems to want to prevent another script from running. So a simple reboot fixes this and clears everything up. This is trivial with Linux because the reboots are quick. Keep in mind cloudinit is not necessary, we are just using cloudinit for another task on this image.

From the canvas do the following:

  • Drag another custom resource object onto the canvas (rename the object to RebootServer as an example)
  • Use your mouse and create a dependency between the new custom resource object and the Virtual Machine object
  • Then drag a dependency line from the Software Custom Resource object to the reboot custom resource object

  • Fill in the properties for the reboot custom resource, everything will be the same as you entered for the software custom resource except “reboot” and “script” properties. For “script” just enter something like echo “Do Nothing” and just make sure Reboot is checked.


Deploy the Blueprint from within the Cloud Assembly canvas:

  • Click Deploy at the bottom of the blueprint canvas

  • Provide a Deployment Name and choose Current Draft

  • Click Next
  • Provide a Name for the Virtual Machine

  • Click Deploy

Once you click Deploy from the Deploy Wizard you will be brought to the Deploy Screen and you can monitor the progress of the deployment.

You may want to verify that mySQL was installed.

  • SSH into the Linux machine and type: systemctl status mysql.service or systemctl status mysqld depending on OS. If you see MySQL is running then the script was successful and the software was installed.


If you ready to Destroy then go ahead and just run the Delete action against the deployment on the Deployments screen.

Ensure the entire deployment gets Deleted.

At this point another workflow called “Delete Custom Script” will run in vRO. See Appendix A for more information.



Below is a snippet of the code used to install mySQL if you need an example.


Link to full blueprint example here.


Configure Blueprint for Windows and MSSQL:



In addition to being able to deploy blueprints on Linux, we also support Window based blueprints as well. Since vRO 8.1 is a polygot system and support multiple coding languages we can take advantage of that to run PowerShell scripts.

The procedures for creating Custom Resource and vRO Workflows are the same for a PowerShell / Windows deployment, and you can use the same custom resource object for both Windows and Linux. So I will skip to the blueprint creation. If you have not created the Custom Resource object yet then please refer to the  Creating the Custom Resource in vRA section above.

Here is a sample blueprint for reference, this blueprint contains powershell code that will install MSSQL 2016 and SQL Server Management Studio.

In mssql blueprint I have inputs that get passed to the powershell code within the blueprint. For instance, $DIR=’$(input.dirpath) will be used to create a folder on the machine to store the extracted files from the mssql ISO. Your script will obviously be different and unique to your environment, but wanted to show an example of what is possible.

Below is a snippet of the code to install MSSQL if you need an example.

Link to the full blueprint here.


The ability to run a variety of script types along with deployments can greatly enhance your blueprints and provide more value for your teams. As we continue to enhance this feature I am sure our customers will use it quite often. Happy scripting!!


Check out these other blogs:


Self-Service Hybrid Cloud – Part 1 – Provide Self-Service Catalog for VMware Cloud on AWS using vRealize Automation
Approval Policies in vRealize Automation
Ansible Tower Integration with vRealize Automation




7 comments have been added so far

  1. Good timing. I just finished your “Introducing Custom Resources and Resource Actions in vRealize Automation!” post and was looking for more with custom resources. 🙂

    1. Hey Neil,

      Yes there are some methods to do that. Good timing on your question, I am repackaging the vRO workflow to include a sleep timer that can be configured, also more verbose logging. Stay tuned, I hope to have it up soon on the site.

      in the mean time there is a workflow called Improved Sleep, you may see that in your workflows. You could add that to the schema of Software-Install-Base workflow. Perhaps before “Waiting for VMTools”.


  2. Hey Vincent,

    Thank you for creating the package!

    Everything works great when creating deployments, but the delete custom script workflow fails when destroying a deployment;

    ch.dunes.model.type.TypeConverter$NullObject cannot be cast to com.vmware.o11n.plugin.dynamictypes.model.DynamicObject

    Any thoughts?

    1. Hello, please double check that the External Type is set to DynamicTypes:CustomScript.Script inside the Custom Resource. If this is not entered in this way you will get a “null” error when deleting deployments. Thanks.

  3. Hi Vincent Riccio

    I did upgrade vRA 8.1 to 8.2 and custom script do not work more, can you has any idea whats happening or Work around to do this it work again.

    Thanks a lot

Leave a Reply

Your email address will not be published. Required fields are marked *