Category Archives: vRA

vRA 7.0 software components for guest customization: example

Microsoft Active directory integration is one of the most (if not the most) requested customization of vRA. There are multiple ways to integrate with active directory during VM lifecycle:

  • Prestaging AD computer objects using a vRO workflow in the requested state of the machine using the Extensibility Broker (EB). The main drawback of this technique being the replication latency, vRO server may not “talk” to the same DC as the machine joining the domain. You may end up with a machine joining in the “computers” OU or joining failing because the service account does not have the right to join AD without the staged object already created.
  • Joining AD using vSphere customization specification (custom specs). This works fine but can only join in the Computer OU using default setup. You will also have to maintain custom specs in each vCenter, possibly one per domain. And yes it is limited to the vSphere endpoint.
  • Runing the domain join using the guest agent. Works great allow to specify the target OU and allow maintaining multiple target domain ou OU just by attaching the custom properties at the right place. See this article for guest agent drawbacks (like lack of error handling).
  • Another option for joining is running the domain join as part of a vRA 7 software component, which is what I will describe in this post
  • Never forget the out of the box AD cleanup plugin to remove objects from AD when a machine is destroyed.

Joining the domain: the software component

Here is an example on how to leverage software components to join AD in a specific OU with logging and error handling, fell free to hack, modify adjust it to your use case.

  • properties

Those are the required properties to join the domain. They bound to property group attached to the IaaS machine. They can also be attached to Business Groups to allow a different target domain per business group.

domainFQDN – string – domain to join, FQDN notation – required
domainOU – string – OU to create the computer object in. LDAP notation (OU=my OU,DC=acme,DC=com)- required
domainUser – string – Domain service account that has the privilege to join the machine to the domain – required
domainPassword – string – Password for the domain joining service account – encrypted – required

  • Code

I will provdide both CMD using netdom and PowerShell code to cover the largest selection of OS.

INSTALL (cmd) – Reboot:Yes

ECHO Begin domain join...
C:\windows\system32\netdom.exe join %COMPUTERNAME% /d:%domain% /ou:"%domainOU%" /ud:%domainUser% /pd:%domainPassword%
ECHO Domain join failed !
) ELSE (
ECHO Domain join OK, rebooting...

I used quotes to “escape” the OU LDAP path that can contain spaces and reserved characters. EXIT /B 1 allows to exit the script with an error so vRA will fail the deployment.

INSTALL (Powershell) – Reboot:Yes

write-output Joining machine to the doamin : $domain
write-output In OU : $domainOU
$passwd = ConvertTo-SecureString -String $domainPassword -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential $domainUser, $passwd
Add-Computer -DomainName $domain -OUPath $domainOU -Credential $cred 2>&1
if ($?) {
write-output "Domain join OK"
exit 0
} ELSE {
write-output "Domain join failed !"
exit 1

CONFIGURE (cmd) – empty

START (cmd) – empty

UNINSTALL (cmd) – empty

Joining the domain: The property groups

When usgin doamin join in any large deployment you may want to join a different OU based on the situation. A different OU per business group for example is a common use case.
To achieve this easily just create a property group containing domainOU and create this property on the business group.
The property group will allow vRA to validate the binding of domainOU to an availbale custom property.
Another way to make the OU a variable is to create a dropdown with external values comming from vRO: A user will input text into a search fields and the vRO action will present a list of OU maching the search ready to be selected.
Making the entire domain configuration variable works in vRA 7.0.0 where you can bind all of the software component’s properties to blueprint’s custom properties. A bug in vRA 7.0.1 prevent binding secure string properties to any blueprint properties. You can still used the same domainPassword password on all domain it will be more complicated.

Joining the domain: The blueprint

Here are the screenshot of this software component in use on a simple Microsoft Windows 2012 R2

  • property groups on the virtual Machine:


  • Software component mappings:



Joining the domain: AD cleanup plugin

If you create and attach those property to a blueprint vRA will take care of removing your computer from AD after they have been destroyed.

Some of those properties are redudant with the one we use in the domain join software component, binding the software component to those ADclean properties may be an easy way to limit the number of place you maintain the same information.

vRA 7.0: Software components vs. guest agent for guest configuration

vRA 7.0 new software components bring new possibilities, even for basic IaaS provisioning. We can now use the software components to configure guest and deploy agents with an all new level of automation and ease of use.

Here is a rapid comparaison of what and how you can configure your IaaS guest OS between leveraging the traditional guest agent and the new software components:

  • Required edition

Guest agent : Any vRA edition
Software components : Only with vRA enterprise edition

  • Passing custom properties from the request

Guest agent : using command line parameters in the custom properties (using {property_name} or reading the workitem.xml within the guest.
Software components : Variables in the script will be replaced by their actul values before the script runs. Any of those variables can be binded to custom properties from another blueprint component (usign [component_name]~[property_name] for binding)

  • Managing reboots

Guest agent: You can reboot between scripts, the guest agent will continue to run at the reboot and go to the next step. managing reboot need to be handled from within the script.
Software components: Reboot are handled automatically by software components on each step of the deployments. You just have to tick a checkbox.

  • Error handling

Guest agent : None out of the box. You can build one using a simple machine shutdown if something fails: vRA will timeout and destroy that machine
Software components : Any script that exits with something else than 0 will be considered as failed and the deployment will be canceled.

  • Logging

Guest agent : None out of the box.
Software components : Standard output of all script are accessible through vRA UI directly. Those log are kept even in case of failure making script debugging way easier than with the guest agent.

To summarize software component are way more powerfull and easy to use than the guest agent. Those two options are also exclusive fron each other: If you are using software components in your blueprint, vRA will not honor the VirtualMachine.Admin.SoftwareN.[Name|ScriptPath] directive. In fact software components are launched in the guest using the VirtualMachine.Software0.ScriptPath property.

Another intersting fact is that even if you do not specify VirtualMachine.Admin.UseGuestAgent software components will run on the guest BUT guest agent basic action like formating and mounting disks will not take place. So you still need to specify VirtualMachine.Admin.UseGuestAgent=true in a property group attached to all blueprints that will leverage software component or guest agent.

The next post will cover common examples using software components to customize guest.

Finding where a build profile is used in vRA

Keeping track and documenting relationships between build profiles and blueprints is a very important aspect of keeping your vRA deployment organized and easy to maintain.

But is very tedious keep track of build profiles and blueprint relationships. And can even be difficult for some activities:

  • When yo try to delete a build profile you may end up with this message, asking yourself in which blueprints it is actually referenced:

  • when trying to document your blueprint you will struggle with this selector window that only let you see 5 build profiles at a time:

All those informations are stored in the IaaS DB, so here are two short SQL queries that you can run against the vRA IaaS SQL server DB to help speeding up things:

  • Find where a build profile is referenced (the WHERE clause is optional and given as example):
SELECT GP.ProfileName, VMT.VirtualMachineTemplateName
		VirtualMachineTemplate AS VMT
		TemplateToGlobalProfiles AS TG
	ON TG.VirtualMachineTemplateID = VMT.VirtualMachineTemplateID
		GlobalProfiles AS GP
	ON TG.GlobalProfileID = GP.GlobalProfileID
 WHERE GP.ProfileName = 'vra.gugent.enable'

  • Print a human readable list of the build profiles attached to each blueprint:
SELECT VMT.VirtualMachineTemplateName ,GP.ProfileName
FROM	VirtualMachineTemplate AS VMT
	TemplateToGlobalProfiles AS TG
	ON TG.VirtualMachineTemplateID = VMT.VirtualMachineTemplateID
	JOIN	GlobalProfiles AS GP
	ON TG.GlobalProfileID = GP.GlobalProfileID
ORDER BY VMT . VirtualMachineTemplateName


You can even copy the data to excel (or create a data source) and build a nice PivotTable:

vRA 6.2 installation gotchas

Here is a list of the tricks and tips I found deploying vRA 6.2:

  • Java

This one is very nice. Java 1.8 prevent Liquibase from working using SSL (credits). The easiest workaround is to install Java 1.7 instead.
Don’t forget to create the JAVA_HOME environment variable using short names because again vRA installer is not confortable with the quotes in the path.

  • Internet explorer

I was working at a customer where IE is stripped out from Windows (even the explore.exe file is removed). Nevertheless if you don’t disable IESC for admin this will prevent the installer to reach the repository. So disable it (server manager > local server > IE Enhanced Security Configuration).

Setting screen:

  • Simple Install

When you try to deploy a simple install be aware that you cannot control the following elements:
– Installation path of vRA, everything will be deployed in “C:\Program Files (x86)\VMware\vCAC”
– Certifiacte to use, vRA installer will generate a self-signed one. You can then change it after the install following the procedure on page 126 of vrealize automation 62 installation and configuration PDF.

  • Custom install

When you choose the custom install and want to deploy everything on a single machine you must deploy all core components in one pass. I tried to deploy database, model manager data and web site then later Manager and the installer just told me that the vCAC app pool already exist and refused to go further. I had to reinstall everything from scratch including dropping vCAC DB.