I wanted to rebuild my environment in vRealize Automation to use 7.6 as I had been using 7.3 for quite a while. When I had finished installing the appliance along with the IaaS hosts, I noticed that running the “vSphere Initial Setup” XaaS form would fail to perform the initial configuration. I attempted running the workflow in both vRA along with the embedded vRO to see if maybe something was wrong with the XaaS form, however much to my dismay that wasn’t the case. Some information on my environment and what I used.


The vRA environment is a lab, therefore I used the default tenant

vCenter endpoint is called “vcenter01”

Agent name is called “Agent01”

The login for the vCenter endpoint was the default administrator@vsphere.local

The requester was configurationadmin from the out of box setup in the final installation steps


Running the workflow would step through about half of the built-in scripts and yield the following logs (I stripped out the preceding ones for simplicty, else this post would be exceptionally long):

[2019-08-29 17:18:15.025] [I] ********************************************************

[2019-08-29 17:18:15.031] [I] Trigger data collection operation

[2019-08-29 17:18:15.037] [I] ********************************************************

[2019-08-29 17:18:15.105] [I] Agent entity with name vcenter01 found

[2019-08-29 17:18:15.111] [I] Wait for data collection statuses to be created.

[2019-08-29 17:18:15.116] [E] Error in (Workflow:vSphere Initial Setup / Data Collect Endpoint resources (item33)#43) TypeError: Cannot call method "getProperty" of undefined

[2019-08-29 17:18:15.152] [I] --------------------------------------------------

[2019-08-29 17:18:15.157] [E] Unable to execute step: Trigger data collection operation

[2019-08-29 17:18:15.162] [I] --------------------------------------------------

[2019-08-29 17:18:15.184] [I] Rollback creates entities

[2019-08-29 17:18:15.194] [I] 4c8ecb26-8a2c-48c3-b2d1-6bc138e1be71

[2019-08-29 17:18:17.198] [I] Fabric group with uuid 4c8ecb26-8a2c-48c3-b2d1-6bc138e1be71 deleted successfully

[2019-08-29 17:18:17.318] [E] Workflow execution stack:


item: 'vSphere Initial Setup/item1', state: 'failed', business state: 'Data Collect Configured Endpoint', exception: 'TypeError: Cannot call method "getProperty" of undefined (Workflow:vSphere Initial Setup / Data Collect Endpoint resources (item33)#43)'

workflow: 'vSphere Initial Setup' (daf78a25-baf7-4e8e-a12a-b7b1b0576795) 

What stood out to me was the “Agent entity with name vcenter01” found. I noticed this was the endpoint name inputted in the XaaS form initially, along with the workflow if ran from vRO. So my next step was to drill down what was going on. I first wanted to identify the dependencies and noticed the only attribute used is the vCAC:VCACHost variable, which was easy to map as it was simply vRA. I cloned the script into its own workflow and recreated the bindings. It did not hold and outs either (excluding the attribute) which led to the following:

I ran this workflow on its own to see if it would yield the same error. The above error code was thrown once more and what stood out to me was the ‘vcenter01’ was found. The endpoint however, is called ‘vcenter01’ but not the agent. In the next attempt, I decided to try it and input the Agent name instead because I noticed one particular oddity within the script.

var agentEntity = getAgentByName(iaasHost, endPointName);

function getAgentByName(vcacHost, agentName){
	var modelName = 'ManagementModelEntities.svc';
	var	entitySetName = 'Agent';	
	var properties ={
		AgentName : agentName
	var resultEntity;
	var resultEntities = vCACEntityManager.readModelEntitiesByCustomFilter(vcacHost.id, modelName, entitySetName, properties, null);
	System.log("hi sirr meme");
	if(resultEntities && resultEntities.length > 0){
		System.log("hi sirr meme");
		resultEntity = resultEntities[0];
	System.log("Agent entity with name " + agentName + " found");
	return resultEntity;

The “System.log” portion caught my attention as it’s simply outputting whatever the in value is. It’s never actually performing any validation if the Agent was found. So when the resultEntities is trying to pull data, it’s yielding an undefined value. Subsequently, that was when I tried inputting “Agent01” as the endpoint name instead for “endPointName.” This worked and it found the Agent and began the data collection process. A bit strange, so I gave it a try on the original workflow. 

Of course, an easy solution is typically not the right one. This failed because as I assumed, the ‘vcenter01’ endpoint name is used in previous scripts. A dilemma really, but given that no “Outs” were needed in the data collection portion of it, I figured I could cobble a way to at least satisfy it. While not the most elegant way, I created an attribute string named “globalAgentName” and assigned it a static value of “Agent01” then tied it to the visual binding region.

The script of course also removed and mention of “endPointName” and substituted it with the “globalAgentName” attribute to pass the agent entity name instead. This worked! The inventory collection began to function without any issues, and I was able to invoke the workflow for the inventory collection at any point. The next part was to create this as a XaaS form to request it on the vRA self-service portal.


I proceeded to clone the vSphere Initial Setup, add in the modifications made and start adding the extra functionality needed for the Agent reference. The first thing I wanted to do was convert the attribute back to just an “IN” element, that way I could integrate it within the presentation form and nest it under the vCenter server settings as a mandatory input.

Now instead of being hardcoded in, the individual can pass any name they want. 

The next step was to create the XaaS form on the design tab of vRA. Adding the workflow was a simple process to do, and vRA did a fantastic job of generating all the form elements required. The following images depict the steps I took:


We can see here that the new workflow is there with the additional input variable I added.

I changed the text here a little to differentiate from the original workflow.

The form automatically imports the presentation from the vRO, which saved a lot of time! And further it showed the new input variable I added.

Given this isn’t provisioning anything but only configuring the environment, no managed machines are being instatiated so we’ll leave it as “No provisioning.”

Simply part, just adding it to the XaaS category.


Now with that all complete, I published the blueprint and added the entitlements to it. When performing the request of the XaaS object, I was able to see the token worked just fine in vRO, the endpoint was added in vRA along with all inventory objects.

I’ve been working on a vRealize Automation distributed environment for some time now. During the time using it, I wanted to try adding a proxy agent, but I decided prior to that I’d deploy a CA in my environment instead of using self-signed certificates across the board. To facilitate this, I used Windows 2016 CA and OpenSSL to generate the pem files I needed for the vSphere appliances. However, lately when I was automating certificate generation in my lab I noticed a particular flaw when generating the openssl.cfg file to materialize the CSR. The following code was used to perform the request:

$opensslCfg = <your_config_information>
$opensslCfg > openssl.cfg
Openssl req –new –nodes –out rui.cer –keyout rui-org.key –config “C:/<path_to_config>/openssl.cfg”

Doing this would yield the following error:

unable to find ‘distinguished_name’ in config
problems making Certificate Request
3252:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or environment variable:crypto\conf\conf_lib.c:270

After a lot of troubleshooting, I checked a file that had previously worked when manually created and put it in a tool to check for differences. The text was effectively the same. I tried pasting the text into vim on a Linux box to perform the OpenSSL command and found it worked. This certainly puzzled me, and I went so far as to reinstall OpenSSL and ensure the environment variables were correctly configured. Upon further inspection, I found that the UTF encoding of the files were different. PowerShell by default saved it as a UTF-16, but the original file that worked was marked as UTF-8. I changed the file generated by PowerShell into UTF-8 and it worked flawlessly.

I used this code to perform the cfg generation instead:

[IO.File]::WriteAllLines($fileName, $opensslCfg)

This resulted in the following code:

$opensslCfg = <your_config_information>
[IO.File]::WriteAllLines($fileName, $opensslCfg)
Openssl req –new –nodes –out rui.cer –keyout rui-org.key –config “C:/<path_to_config>/openssl.cfg”