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.

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
FROM
		VirtualMachineTemplate AS VMT
	JOIN
		TemplateToGlobalProfiles AS TG
	ON TG.VirtualMachineTemplateID = VMT.VirtualMachineTemplateID
    JOIN
		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
	JOIN
	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.

Building a lab: from wood to cloud – part 1.

I needed to build a new lab to work on different cloud stacks and as I also love woodworking: I though why not building a custom rack to host my lab. The requirements were quite simple:

  • Host a full VMware stack: vSphere, vRA, vRO, vROM and NSX stack (with all required supporting infrastructure)
  • Host an Openstack instance as well
  • Consume minimal power (even a lab must be energy efficient)
  • Look good
  • Ease maintenance and cabling
  • Portable: I want to be able to move it arround without a forklift
  • Provide a large NAS storage space for various non-lab usage like time machine backups

So with that in mind the first thing was to select the hardware:

Compute:
Small size and low power consumption leads to two platforms Intel NUC and Apple Mac mini. One of the requirements being looking good: the mac mini was the obvious choice. It is small, power efficient, good looking an easy with ESXi (thanks to William Lam for his numerous and usefull articles on installing ESXi on Mac mini).

But the latest edition of the Mac mini has some limitations:

  • It is non upgradable: RAM is soldered
  • core speed are very low: the entry level nodel runs @ 1.4Ghz

As a consequence it will be quite expensive to get the correct configuration.
So I’ve ordered 3 previous gen MD387LL/A entry level model (on sale @ 499$ each), 3 16Gb upgrade and 3 32Gb SD card (more about those later).

The compute kit

You may ask why the entry level dual core ? the answer is simple, I found that 8Gb of RAM per core is the RAM/core sweet spot. So as the max RAM is 16Gb on those machines, 2 cores is enough and the clock speed is good.

Storage:
For the storage, I am an NFS fan but I also like VAAI and found that VAAI for NFS is making NFS too complex. So I went with iSCSI storage. I also wanted a large upgradable array. After seeking for the perect array I found that a Synology 1813+ will do the trick:

  • 8 bays upgradable to 18 bays by adding external enclosures
  • 4 Gbe network ports
  • VAAI capable firmware
  • SSD aware, they can be used as read cache or very fast storage.

On the disk side: I had 2x2Tb WD Caviar red, a 512Gb Crucial M500 SSD and another old 2Tb WD caviar green hanging around. I just order 2 extra 3Tb caviar red. The disk configuration will be detailled in a later post.

Networking:
As NSX is involved the following requirements comes with it, physical switch must support:

  • Jumbo frames: more precisely MTU of at least 1550 for VXLAN
  • 802.1q VLAN
  • IGMP snooping

Again I found that repurposing an old Netgear switch is the most economical option. I had for a long time a Netgear GS108Ev3 which actually meets all the requirements. It even has a nice web admin UI. It only has 8 ports but that will be enough for now.

Wood:
I am looking for something easy to work with medium mechanical resistance (the lab is not going to be that heavy, neither will it withstand heavy mechanical constraints). So I’ve choose to do it in 1/2 inch particule board (which also happen to be hanging around in the workshop).
Particule board are easy to work and finish. The only drawbacks are:

  • No advanced joinery is possible. i.e. no dovetails
  • It produce nasty particule when cutting or working with a routeur: proper eyes and breathing protection are mandatory, earing protection is always a plus.

Now that everything is chosen. I need to draw my custom enclosure and start working the wood. The next article will cover the building and fitting of the enclosure.