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!


Workflow Developer Tools

For convenient viewing of the log files, you can use mtail:
Like the linux tail-command it refreshes the open files and is so a very useful tool to watch the logs while running your workflows.


If you want an alternative for the built-in script editor
For convenient viewing of the log files, you can use mtail:
Like the linux tail-command it refreshes the open files and is so a very useful tool to watch the logs while running your workflows.


Rhino shell
If you want an alternative for the built-in script editor you can use the Rhino-debugger.
Rhino shell

Download the Rhino-package from:
(The links point not to the current version, but to the older 1.6R3-version of Rhino which is used in Orchestrator.)
Unzip, open a command prompt, change to the base-directory and start the debugger with
java -cp js.jar
For more information, see the docs at
Unfortunately, there is no integration of this debugger to vCO, so it’s difficult to use it for scripts which uses other Orchestrator objects (which is the fact for most of your scripts, I guess). And you have to copy&paste your code to the vCO-Client. Not very convenient, but maybe helpful to debug some plain JavaScript-elements.

Script Debugger

Hmmmmm… finished 🙂
Unfortunately, there is no built-in debugging tool for scripting elements. So no breakpoints, no variable inspection, no tracing.
As a workaround, the only way to see the content of variables is to log them, e.g. to System.debug. Example:
<div>//vm is an input parameter with type VcVirtualMachine)
 System.debug("vm: " + vm);
 var vmname =;
 System.debug("vmname: " + vmname);
 var numvcpus = vm.summary.config.numCpu;
 System.debug("VM " + vmname + " has " + numvcpus + " vCPUs");</div>
Gives following output in script-log.log in $INSTALLDIR\app-server\server\vmo\log:
2011-02-26 17:09:59.010+0100 DEBUG [SCRIPTING_LOG] vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-128>'lab-db'
2011-02-26 17:09:59.011+0100 DEBUG [SCRIPTING_LOG] vmname: lab-db
2011-02-26 17:09:59.015+0100 DEBUG [SCRIPTING_LOG] VM lab-db has 1 vCPUs
You can see the timestamp (see log4j-config for format), the loglevel DEBUG. For numbers and strings you can see the plain content, for complex data type you can see the type of the variable (e.g. [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine]) and it’s toString() implementation (VALUE : VirtualMachine’lab-db’).

Orchestrator Logfiles

Orchestrator uses the log4j-mechanism (Version 1.2) for logging. The core-platform, custom scripting elements (via System.log()) and the Plugins log to the targets configured in the log4j.xml in %INSTALLDIR%\app-server\server\vmo\conf.


For a description of the possible log-targets view the original log4j-documentation:
Nice examples for the configuration log4j.xml you can find on
Additional there is a snmp-appender for log4j. So you can send snmp-traps for log-events as well. An example configuration:

Managed Object Browser

The Managed Object Browser (MOB) runs on your vCenter-Server (It’s installed and started automatically, so there is no need to download something). It provides a HTML-View on the vSphere API.
You can use the MOB to surf through the Objects in your environment and look for names of methods, attributes,…

see also
Page 2 of 3123