{% raw %}

One of the common issues that we help our customers solve here at SovLabs is blueprint sprawl.  The more blueprints, the more complicated it is for both end users and admins. The fewer blueprints, the easier for both end users to make the right choices and admins to maintain the catalog. The path to fewer blueprints is created by making each blueprint as dynamic as possible: the fewer hardcoded values or options, the more use cases can be covered with one blueprint.

In this article, we’re going to look at how to include component profiles with a blueprint, while maintaining dynamic customization specifications selection.



Use Case

Two business groups have identical blueprint (and component profile) requirements, but different customization specifications. The goal is to have one blueprint and one component profile for the image selection, while ensuring the correct customization spec is used for each business group.

So we will need to set the _clonespec field with the appropriate name of the customization spec to use before the VM is created. However, component profiles in vRA do not allow custom properties, and the fields can’t be “templated” to work with SovLabs’  Template Engine.

While there are many different ways to solve this issue using the SovLabs Property Toolkit, this post will cover a very straight-forward method. I’ll do a follow-up post covering some of the more complex methods.


Two business groups: BusinessGroup01 and BusinessGroup02

Using Dynamic Elements with vRealize Automation Component Profiles 1

Each business group has a custom property of imp.bgcode with a value or either 01 or 02.  Note that, while we could build this imp.bgcode from the name of each group (since it ends in the same pattern), I’ll use a value as that concept works in more environments.    

Using Dynamic Elements with vRealize Automation Component Profiles 2

Two customization specifications with different keys and time zones:

BusinessGroup01_Win16 (Pacific),  BusinessGroup02_Win16 (Eastern)

Using Dynamic Elements with vRealize Automation Component Profiles 3

An Image Component Profile with a blank Customization Spec value.

Using Dynamic Elements with vRealize Automation Component Profiles 4

For our first example, we’ll use one Custom Property Group (SVL_Cust)  attached to the blueprint. SVL_Cust includes the __CloneSpec property (see footnote #1 below) with a value of BusinessGroup{{ imp.bgcode }}_Win16.  This value will leverage the SovLabs Template Engine to create the desired result during provisioning.   Specifically, the value of the imp.bgcode property (which, if you recall, we set on each business group) will be added to the string “BusinessGroup” and then” _Win16” will be appended at the end. (see footnote #2 below)  

Using Dynamic Elements with vRealize Automation Component Profiles 5


After the components are created and the new catalog item is published and entitled to the user in their business group, the user can request the item and choose the appropriate component profiles.

Using Dynamic Elements with vRealize Automation Component Profiles 6

During provisioning, the Sovlabs Template Engine will process the __CloneSpec value using the imp.bgcode property, setting the  __CloneSpec property to the correct customization specification set.


Deployed VM

Using Dynamic Elements with vRealize Automation Component Profiles 7 Using Dynamic Elements with vRealize Automation Component Profiles 8


As you can see above, the VM deployed with the correct customization spec. However, this method only works for WIndows 2016, and our solution is limited to just one property.

In the next blog in this series we’ll look at different ways to change properties on the fly and how to leave ourselves room for future customizations.



1. _CloneSpec is an out-of-the-box vRealize Automation property to set the customization specification for the CloneWorkflow provisioning workflow.  This value is the value set when you fill out the customization specification field for the component profile.

2. There are several ways to come up with the correct name of the specification. In this case, since the customization specification is the same as the business group name plus  “_Win16” we could have used BusinessGroup{{ imp.bgcode }}_Win16.  In a brownfield environment or if you want to plan on future business groups that don’t match that naming scheme, using a property on the business group like img.bgcode is useful.  

You could also use an “if” statement to determine the correct customization specification such as:

{% if img.bgcode == ’01’ %}BusinessGroup01_Win16{% else %}BusinessGroup02_Win16{% endif %}

However, this method requires logic to be maintained on a property group as the environment changes, such as adding business groups or specifications.

{% endraw %}

Recommended Reading