Category Archives: vCAC

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.

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: