vRealize Automation – vCAC 6.2 – Pre-Req Automation Script

Are you getting ready for the pending release of vRealize Automation 6.2 next week?  If so you’ll want to make your first stop GitHub to download Brian Graf’svCAC62-PreReq-Automation.ps1 script.  If you are not familiar with Brian’s PreREq automation scrip, it is a script that configures all of the needed requirements ion your Windows IaaS server prior to installing vCAC.  Brian did a fantastic job with the creation of this, it is a must have if you are installing vCAC from scratch.

In this version he updated the script to account for vCAC 6.2 Pre-Requisites so head on over to https://github.com/vtagion/Scripts/blob/master/vCAC62-PreReq-Automation.ps1 to download the script and get familiar with it to be prepared for the pendinf release.

vRealize Automation – vCAC 6.1 – Custom Property Toolkit for vCO

For those of you who have not seen this yet, it is a must have for anyone writing vCO workflows for vCAC.  VMware’s own Dan Linsey build a set of pre-built workflows to help aid you in your own development efforts.  The toolkit includes workflows for performing Create, Read, Update, & Delete Operations for vCAC custom properties for more than just virtual machine objects.  IT includes support for the following:


  • Blueprints
  • Build Profiles
  • Business Groups
  • Endpoints
  • Property Dictionary
  • Virtual Machines
  • and more

Top check out this incredibly useful toolkit head over to the VMware Communities and download it.

vRealize Automation – vCAC 6.x – Removing workflow revisions from Design Center

CloudUtil is a vRA(vCAC) repository management tool that is part of the vRA Designer.  It actually is what you are launching when you run the designer.  When run without parameters it launches the GUI Designer.  It however has other functions that can prove useful from time to time.

For starters if you don’t have the Designer Installed you can get it by going to https://FQDNofvCACAppliance:5480 –> IaaS Install –> vCloud Automation Center Designer.  When you install it make sure you put in the IaaS host, NOT the vCAC appliance hostname.

I frequently get asked how can workflow revisions be removed from the designer.  The answer is they can, but you need a Development Kit license to do so with CloudUtil.  Working in the designer you will come to find out that the revisions add up fast and before you know it you could have hundreds.  I’m going to walk you through a way to remove the revisions without a Development License for CloudUtil.

[Read more…]

vRealize Automation – vCAC 6.1 – Building vCO workflows for Multi-Machine Blueprints

It seem that there is a bit of confusion around using vCO workflows with multi-machine blueprints.  Before I discuss how to build vCO workflows for multi-machine blueprints I want to discuss the differences between single machine and multi-machine blueprints and how they relate to each other.

Single Machine Blueprints

Single machine blueprints are pretty straight forward.  When a custom property is defined on a single machine blueprint it only affects that machine.  Makes sense right?  When we trigger a vCO workflow to run during a state transition of a single machine it interacts with only that machine.  It is important to be mind full of the vCO workflows that are assigned to single machine blueprints that may be used as a component machine of a multi-machine blueprint.

Multi-Machine Blueprints

Multi-Machine blueprints are extremely versatile allowing single machine blueprints to be grouped together for and requested in a single deployment.  They are so versatile that you can add single machine blueprints of different types that are possible deployed to different types of Endpoint and across geographies.  This however also makes them somewhat complex requiring you to be careful and thoughtful as to how you structure custom properties and the vCO workflows that you may choose to run on them.

Custom properties that are defined at the Multi-Machine blueprint are passed down to the component virtual machines that are a part of them.  This can be very useful, but can also be a bit dangerous.  Take the hostname property.  If we define a hostname using this property at the Multi-Machine level it will cause chaos during the deployment and cause the deployment to fail because all machine will inherit the property and the value and ultimately have the same name.

This is the case with any different properties when used at the multi-machine level.  You also need to be mindful of the effect of that property across different platform, provisioning types as well as geographies.  This becomes even more complicated when executing state transition workflows that run vCO workflows.  If you attach a workflow to the multi-machine it will in turn become attached to every component machine as well.  This can be very useful if you want to execute the workflow on every component machine, however if that workflow is utilizing an entity that doesn’t exists at the parent multi-machine level it will again cause chaos for your deployment.  The good news is it doesn’t have to as long as the vCO workflows are built to support the intended result.

In the following walk-through I will be using the Custom vCenter Folders Extension to demonstrate what you can do to account for the Multi-Machine and Single Machine aspects of vCO workflows.

[Read more…]

vRealize Automation – vCAC 6.1 – Custom vCenter Folder Extension


vCAC by default will place all provisioned machines into a vCenter folder named VRM.  You can override this using the custom property VMware.VirtualCenter.Folder to tell vCAC where to place the provisioned machine.  While this is great that you can tell vCAC where to place the provisioned machine it isn’t very flexible.  I built the Custom vCenter Folder Extension to fix that and make folder placement as flexible as you need it to be.  VM folder placement is just about organizing virtual machines.  It provides a way to control access to these machines through vCenter as well.  Many organizations control permissions to these environments using these folders and need to be able to place any machine where they need for these purposes.

Multi-Machine blueprints is another area where this extension adds value.  You can control placement of virtual machines by defining the VMware.VirtualCenter.Folder property on a Multi-Machine blueprint folder, but all VM’s for all Multi-Machine apps are placed in the same folder creating confusion as to which VM’s belong to which Multi-Machine application.  Now if you add NSX into the mix and you have Multi-Machine components spread all over the place with no way to easily determine which VM’s as well as NSX Edges go to which application.

When used with Multi-Machine blueprints the Custom vCEnter Folder Extension can place all component Virtual Machines as well as Deployed NSX Edge appliances in a folder named after the Multi-Machine application if you desire making it easy to identify related components of an application.  This also allows you to easily permission vCenter access to the components of the application if necessary.


  • Dynamic Folder Names based on custom naming scheme
  • Multi-Machine folder placement including NSX Edge applince
  • Automatic Multi-Machine folder removal when Multi-Machine app is destroyed

[Read more…]