Small, but useful command-line tools for vCO Workflows

In Orchestrator you can execute local commands on the vCO-Server using the Command-Object.

Usually it’s a good idea to place these commands together in a directory like c:\Orchestrator.
Don’t forget 1: Remember to configure your vCO-Server to allow the execution of local commands and to access these folder in case you have external scripts, temp-files,…:
Add com.vmware.js.allow-local-process=true to the, and configure the js-io-rights.conf, see vCO Administration Guide, section “Setting System Properties” for details.

Don’t forget 2: Remember to include this folder and all its file when you deliver your solution to production environment, customers, …! They are NOT included in any package you create inside your vCO content.

Don’t forget 3: The external tools are always executed in the security context of the Orchestrator Server (usually SYSTEM), and NOT in the security context of the user who starts the workflow. AFAIK there is no way to change this.

Some tools I call frequently:


Download (the Amiga-Version…, just kidding :mrgreen: ) from, and call it e.g. with:

var url = "";

var cmd = new String();
// 1st proof-of-concept example:
//cmd =  "c:\\vcoscripts\\curl.exe --help";
cmd = "c:/vcoscripts/curl.exe -o NUL -w %{http_code} " + url;

System.debug("executing cmd: " + cmd);
var command = new Command(cmd);

var resultNumber = command.result;
System.debug("resultNumber: " + resultNumber);
var curlResultNumber = resultNumber;

var resultOutput = command.output;
System.debug("resultOutput: " + resultOutput);
var curlResultHttpCode = resultOutput;

The resultNumber shows the result of the curl execution (e.g. if there are network problems), see the full list here:
The -o NUL -w %{http_code} in the call configures curl only to return the HTTP-Status Code, which is then accessable via command.output.
For other possible parameters check the curl-Documentation:

Use it to check the availability of some Web-Resources, POST some data to external systems, GET information from external systems, or do the geeky hardcore way to access 3rd-party webservice (I rather suggest to use the new REST and SOAP-Plugin for the latter :-D).


Download from you can use this command to access the whole bunch of information on your Active Directory (without being limited to the small attributes accessible for a LdapUser-Object in vCO).

Example call:

var attribute = "sn"; //for surname, others see link in post

//hardcoded to use in workflow input presentation, otherwise I suggest to use a Configuration Element
var adfind = "c:/vcoScripts/adFind.exe";

//use-case here: get some information about the user running the workflow
var ldapuser = Server.getCurrentLdapUser();
var dn = ldapuser.dn;

var cmdString = adfind + " -list -b \"" + dn + "\" " + attribute;
var command = new Command(cmdString);
System.log("Executing System-Command: " + command);
var cmdReturn = command.execute(true);

System.log("...returns " + cmdReturn);

System.log("Output: \n" + command.output);

var output = command.output;

var outputStr = new String();

//remove blank lines at the end to have the answer in a clean string
if (output)  outputStr = output.replace(/^\s+|\s+$/g,"");
System.debug("outputStr: " + outputStr);

This example calls AdFind to get some attributes of the workflow-starter. (For a full list of Active Directory Attributes and their LDAP-Display-Name check and the very convenient Excel-Sheet on )
Use it to get the manager of the user for approval-workflow, document the telephone number in custom attributes in vCenter, or do usability-improving filters in input presentation.

However, AdFind is by far not limited to this use-case: Get some ideas what else you can get from your AD on the manpage:


Nobody really wants, but sometimes you have to… 😕 : If you have some existing VB-Scripts you want to execute, you can use cscript to start them in a console-context (without any windows, perfect for the headless vCO-Server). See the parameters here:


Command.execute() can be used to call PowerShell-Scripts, see an example on Calling PowerShell from vCO. However, you have to serialize input parameters and output results from  the script, which leads to very confusing command-strings and a lot of RegExp-Work to parse the output.
(Sneak Peek: I’m working on a better solution, watch for updates here)

Whenever you want to integrate your Workflow with external systems, you can search for CLI-tools of the external system (HP Lefthand CLIQ, DsShed.exe for Altiris, …) . They provide a quick (no need to learn/use any base-level API) but maybe dirty (the need for serialization to pass information, see above) way to achieve your goal.
Be creative!