How to extend vCAC with vCO Part 2 – Hello world Script in Guest

Updated on 8/20/2014 to fix some problems with some of the steps with help from loyal followers of this site. 

In this lesson we will use the vCAC to vCO extensibility that we setup in Part 1. In many customers that I work with provisiong the virtual machine and operating system are only one part of the problem. To fully automate the provisioning of infrastructure in any organization there are going to be additional tasks that need to occur. These tasks can occur both in the guest operating system after the VM is provisioned, for example running installation scripts in the guest to install management agents. Or outside the guest like adding the server to an Active Directory OU before the VM is added to the domain so the correct Group policy is applied. This is where vCO comes in. In this simple example I will show you how to pass properties from the vCAC blueprint and pass that into the guest operating system at provisioning time. This is a very powerful tool as you could use this to run your own scripts that you may already have. You would just need to modify those to accept a custom property as the argument for the script to run.


Start by adding a simple shell script (Linux) or command file (Windows) to your template. In the following examples I am going to pass two properties to a Script to run in the guest.

Linux example:

echo $1 $2 >> results.log

Save as


Windows Example:

echo %1 %2 >> results.log

Save as myscript.cmd

You should test the above to verify they work before you shut down your template. For example sh Hello vmtocloud

Now let’s login to vCAC and add some custom properties to our Blueprint. We will pass these properties to vCO to run a command in the guest VM at provisioning time.

my.custom.field Hello
my.script /
my.command /bin/sh

Login to vCO client and the first thing we will need to do is import an action courtesy of Tom Bonnano of @dailyhypervisor, download and unzip the file from the link below and then browse to the com.vmware.library.vcac folder and right click and import the action getVirtualMachineOwnerUsername


To use a vCO workflow with vCAC you need to start with special provided workflow and then build your workflow from that. This special workflow will get all the custom properties from the vCAC blueprint and make them available for you to work with in your work flow. The custom properties are more than what we added to the blueprint in the previous step. There are also out of the box properties that are already populated. You can see the complete list here. In this lesson I will use one of the out of the box properties and the ones we created to give you the full perspective.

Login to vCO and create a new folder to keep your workflows.


Login to to the vCO client and browse to the following workflow


Right click and Duplicate the Workflow Template to a your folder and give it a new name Run Script in Guest


Browse to your folder and right click your new workflow and select edit


Click the inputs tab and you can see some of the parameters that are coming from vCAC. Notice the vCACVMProperties. This is where we are getting all the custom properties from.


Since we are not using vCloud Director in this example let’s remove that portion to make this easier. Highlight that Parameter and delete it.


Also delete the additonalInputFieldbyBlueprint Parameter as we don’t use it in this example


Now click the Schema tab and click edit on the Display inputs task.


On the In tab delete the vCloudVAPP Parameter. Then close this pop up window.


Now go to the scripting tab and delete the following lines of code


Now drag and drop a scriptable task into the workflow as shown


Now click edit on the Scriptable task


Enter the following info on the Info tab


Now change to the Out tab and click to create three new attributes named myscript mycustomfield, mycommand


It should look like this when your done


Now select the Visual Binding tab and drag the vCACvmProperties to the IN box so it looks like this:


Now click the scripting tab and add the following lines

myscript = vCACVmProperties.get('my.script');
mycustomfield = vCACVmProperties.get('my.custom.field');
mycommand = vCACVmProperties.get('my.command');

Now let’s drag in that action we imported earlier.


Now click the General Tab and add a new Attibute named VMowner of type string


Now go back to the Schema Tab and click to edit the GetVirtualMachineOwner Action and go to the visual bindings tab and connect the following then close


Now lets drag in another scriptable task and click edit


Enter the following on the Info Tab


Now click the Out tab and create a new attribute named args


Now click the Visual bindings tab and add the following connections


Now select the Scripting tab and enter the following line and click close

args = myscript + " " + mycustomfield + " " + VMowner

Now let’s add the run program in guest workflow to our workflow


Select the following parameters to move to values in your workflow but make sure vCenterVm is and change Program path to mycommand and arguments to args. It should look like this.


Verify that your visual bindings look like this:


We’re almost there. Everything would be done at this point but we need some way to know that the VM is up and ready for use to run a command in the guest. Drag the vim3getVMtoolsstarted action into the workflow. You will find this under folder on the left.


Next select the following for input Parameters and values for pollingRate and timeout and click Promote


Now let’s go to the General tab and setup some of our attributes. You need to set the VMusername and VMPassword that the run program in guest will use as well as the polling rate and timeout that vCO will check if the VM tools is started. You also need to enter something for the working directory. / for Linix and C:\ for windows.


Now go back the the schema tab and click validate, you should see the following screen, if not review your workflow otherwise and Save and Close


Now run the following workflow to add this to your vCAC blueprint


Change to Machine Provisioned and Set the vCAC host and click next


Now browse to select your blueprint click add then Select.


Be sure there is only your blueprint in the list and click accept. Then click next.


Now select the workflow we just created and select no for the two options and click Submit


When you look in vCAC the Blueprint should have a new custom property


Fire off a new request and when you login to the provisioned VM you should see that the script executed with the following in results.log


Download the workflow here:

Remember sharing is caring!

26 Replies to “How to extend vCAC with vCO Part 2 – Hello world Script in Guest”

  1. Pingback: How to extend vCAC with vCO Part 1 – Installation |

  2. Hi, what was the last action you added to the workflow before you added the state change workflow. i cant read it.

  3. Ryan, this is very very helpful. Unfortunately I’m learning on the fly, so I’m sure i’m missing some stuff. Your script dives pretty deep, where I’m just trying to get one property from vCAC and the VRMOwner to add the local user. Any chance you could double check my work? I don’t have any access to a site to upload my file, but I did create a thread on the vcac forum.

  4. So after fighting with this for a while, there were to key errors that I hit:

    1. When you set vCenterVm1 to skip when setting up the run script in guest workflow, you sets it to Null, causing the vm input parameter to be null, meaning var host = vm.sdkConnection; bombs out for vm being null.

    2. Also in the Run Script in Guest workflow, you tie the arguments attribute to the arguments input. But arguments is null, you stored the output from build args into the args attribute.

    Just though you’d like to know.

    • Right. Neither the steps nor the package works for me. Keep getting the error “Error executing vCenter Orchestrator workflow: TypeError: Cannot read property “hostId” from null “. Was there a workaround you found?

  5. Hi folks, I am looking at it now. This may be a problem with the vCAC plugin version or vCO build I am using as compared to yours. I will post update as soon as I figure it out. Sorry for the inconvenience this may have caused.

    • Thanks Ryan. My vCO build is 5.5.1 (, vCAC plugin version is and vCAC Infrastructure Administration is

      • I updated the post with corrections. It should be working now. There was a problem with the visual bindings on the run program in guest workflow. See visual binding screen shot in this post. Also uploaded the new version so you can import it into your vCO install.

        • Unfortunately, it is still the same. Workflow “WFStubMachineProvisioned” failed with the following exception: Error executing vCenter Orchestrator workflow: TypeError: Cannot read property “hostId” from null. Attempted to create the workflow multiple times with no luck. Looks like it has something to do with the parameter “envrionment” but skipping or leaving it to default doesn’t do any good.

          • This worked for me with the following changes:
            1. my.script property set to in vCAC
            2. value for workingDirectory left blank in vCO
            3. Action used is vim3WaitToolsStarted
            Thanks for this post!

          • Hi Surabhi,

            Thank you for your feedback. I updated the blog with vim3WaitToolsStarted. For the my.script property I have a question, which flavor of Linux are you running. I am wondering if this is different for CentOS/RHEL vs another flavor or if this is a typo on my part.

  6. Thanks for the informative post. I am a novice with vCAC (6.1) and vCO (5.5), so forgive my naivety for asking this question: What are the reasons you would runs script in the way you’ve described here instead of doing it with the vCAC Guest Agent? I am struggling with which approach is considered the better practice when doing things like installing management agents on newly provisioned (via cloning) VMs. Thanks!

    • Hi Marty,

      It’s a great question but unfortunately I don’t have a better answer than “it depends” It all depends on the customer and their environment. For example some customers do not want any agents or software installed in their templates so I use this vCO route to run post provisioning actions in the guest. Some customers don’t mind agents so I use the guest agent. There are also a few customers that don’t even want the VMtools installed so I can not even use the run process in guest action as that requires VMtools to be installed. I have done this using SSH or powershell to the guest. It all depends what regulation the customer has.

  7. I followed the directions here and the provisioning fails with this error:
    Workflow ‘WFStubMachineProvisioned’ failed with the following exception: Error executing vCenter Orchestrator workflow: ReferenceError: “VMowner” is not defined..

    vCAC Appliance version Build 2216936
    External Orchestrator – version Build 2179237

    Any suggestions?

  8. Getting error: [SCRIPTING_LOG] ReferenceError: vm is not defined for waiting for the DNS name

    Have rebuilt multiple times and importing your workflow has the same results.

    vCenter 5.5
    vRA 6.2 Build 2299574


    Any thoughts?

    • hey Mark, did you ever figure out that “vm is not defined for waiting for the DNS name” error? I am getting the same thing. no luck yet. thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.