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%
IF NOT %ERRORLEVEL% == 0 (
ECHO Domain join failed !
EXIT /B 1
) 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.

Leave a Reply