As you may now know, the ability to assign a Custom Spec to a build happens at a blueprint level in vRA. I've had plenty customers wanting to make blueprints as dynamic as possible, resulting in zero (or at least, dramatically reduced) blueprint sprawl.

Static Blueprints

Now, imagine you have a single Windows 2012 R2 template that you are cloning, with a Customization Spec that performs a SysPrep and adds the machine to a domain upon Provisioning. This means that the Customization Spec contains Domain Credentials, and you would have put the customization spec name in the blueprint here:

Inserting the Customization Spec (statically) at the Blueprint level

Great. Now imagine you wanted to deploy to multiple domains. If you had to deploy to 3 domains on a single instance of vRA, it means you would need to create 3 different blueprints for the same O/S, since you would also need to have 3 different customization specs with the relevant domain credentials.

Customization Specs for Windows and Linux, per domain

What if you had Windows 2008 R2, 2012 and 2012 R2, and then RHEL 6 and SLES? You would have 5 basic blueprints x 3 (3 domains) = 15 blueprints off the bat, just because of the need to apply different customization specs statically.

Dynamic Blueprints

The way we can overcome static sprawl is by dynamically assigning the Customization Spec (and other values as you'll see in a later post on this blog related to T-Shirt sizes) on-the-fly.
This means we still have a single blueprint per O/S, but we leverage vRO to assign the Customization Spec property before the build hits vCenter, during the "BuildingMachine" phase / stub.

What this effectively means is, from inside a Scriptable Task inside a vRO Workflow, we will need to determine:

The Domain we are provisioning to
The O/S we are using

In order to minimize the dependency on a whole bunch of switch statements, I've made this rather simple for the purposes of this demo.

Consider the image above, listing our Customization Specs. We will be using "linux.virtualnebula.com" and "windows.virtualnebula.com" which are simply the names of our customization specs, one for linux and one for windows, both for the domain "virtualnebula.com".

We will read 2 custom properties off the machine from within vRO. The first, I've put into my build profile (you can put this into the blueprint as well). This is for Linux machines.

This is in a build profile, and applies to any Linux machines

The second is placed on our Business Group (or Reservation). In my case, I have business groups related to domains:

This format is specified at a Business Group Level.

The fun stuff

Now for vRO work.

At this point, the assumption is that you've already integrated your vRO with vRA, and you've hooked up a "BuildingMachine" Stub Workflow accordingly. If not, you can follow one my previous articles on how to achieve this.

So, in my case, I have a workflow assigned to the building stub:

Editing my "LinuxBuildingStub" workflow reveals a really simple script and an action. The script reads the aforementioned custom properties, builds the name of the customization spec, and then simply applies the name of the customization spec in the form of another custom property called "__clonespec".

The "Drive Cust Spec" action above is a simple Scriptable Task that contains the following script. The script sets an output string variable (attribute) to the new name of the Customization Spec.

Remember, when this workflow is run, both of the previously entered custom properties will be accessible as follows:

So we get those custom properties in the script and build up our new name, replacing "x." in the format with the prefix from our build profile or blueprint.

The next step takes this newly built up Cust Spec Name and applies it to the VM by calling a built-in Action. The "PropertyName" variable for this Action should be "__clonespec".

Save. Increase Version. Close. Request Machine. Done.

You should now have dynamically assigned Customization Specs.

Feel free to ping me if you need more info,

Twitter: @T1gerShark

--Chris