Latest Headlines

Wanted: Tester for Preview of my PowerSSHell-Plugin for vCO

I’m looking for Tester for my first Plugin for the Orchestrator: The PowerSSHell-Plugin for vCO

It allows you to execute Powershell Cmdlets and -Scripts from within workflows, without struggle with Security Context or painful parsing output text-data because it leverages the PowerShell SSH Server of powershell|inside and provides object-oriented results.

PowerSSHell-Plugin for Orchestrator - Architecture

So please Download the Plugin (it’s free, yet 😎 :-D), give it a try and share your comments on

I’m looking forward to your feedback to create a further roadmap for the Plugin!


“Orchestrate Your Cloud” #vMeetup at VMworld 2011

Join the #vMeetup about vCO at VMworld 2011, to…

  • … meet other people in the (yet 😀 ) small Orchestrator universe
  • … share real-world experiences
  • … discuss Best-Practices for vCO projects
  • … learn the power of vCO
  • … lift its mystery

We will meet on Thursday, Sept. 1, 12pm at VMworld Community Lounge, just outside the Solution Exchange.

There are a lot of other interesting meetups, see the complete list on I’m especially looking forward to the “Developer/Administrator #vMeetup” on Tuesday!


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!


vCO Use-Case: Extend vSphere Functionality: Clone from Snapshot


One possible Use-Case for vCenter Orchestrator is to provide some kind of User Interface to vSphere Features which are not directly usable from vSphere Client.

The vCenter-Plugin bundled with vCO provides access to the complete vSphere API (even though some of the Library Workflows and Actions are not complete to the current version). So it is possible to create a Workflow that uses API-Calls that are not visible in the standard vSphere Client.

Example needed?

The vSphere API allows you to create Linked Clones of Virtual Machines.
This feature is not exposed to the vSphere Client (for some good reasons I guess 😆 , think about all the “Pebkac”-issues even with usual snapshots 🙄  ).

However, in vCO there are some Workflows to create Linked Clones (in Library / vCenter / Virtual Machine Management / Clone / Linked Clone):

Other Example: Clone from Snapshot

vSphere Client olny allows you to clone the current state of a Virtual Machine, even if the Virtual Machine has one or more Snapshots.

However, often you want to clone the old state of a Virtual Machine, which is “conserved” in a Snapshot:

  • in Lab/Dev/Demo/Test-environments you want to roll out several “branches” from the same state of a VM,
  •  in production environments you recognize the “bad-practice” to keep a lot of Snapshots, but before deleting them you want to clone these old states for later usage,
  • everywhere you have a snapshot, but you don’t know the reason and state why it was created, and you want to go for sure before deleting it,
  • …..

The vSphere-API allows you (since 4.1) to clone a Virtual Machine from a snapshot state by specifying the snapshot in the VirtualMachineCloneSpec.

For this there is no bundled Workflow in the Library, so can take my package with the solution:

How to use it?

1. Download the Package from

2. Import the Package to Your Orchestrator:
(depending on the Version of Your vCO-Server it will ask to import some used library-Actions as well…):

3. Start the new “ // Clone from Snapshot”-Workflow:

4. Select the source Virtual Machine, one of its Snapshots, all the target information as for a usual clone task, and watch the progress in vSphere Client 😎 !

How does it work?

(Well, the package allows you to inspect the content, so see for yourself 😛  )
The Package contains a Workflow and two Actions, all duplicated from original Library-content bundled with vCO. The only extension I did was to add the “snaphot”-Parameter to the Action which provides the VirtualMachineCloneSpec and extend the “Clone VM”-Action to allow filling this parameter.

A possible improvement: Add a “filter” to the Input Presentation to show only Virtual Machines which have at least one Snapshot.
Another possible improvement: Add some validation, that the Snapshot really belongs to the Virtual Machine (here it is done by the “tree-root”-Property of the Input Presentation of the Snapshot Parameter. However, if you call this workflow from other workflows, the input presentation is not been processed…).

Do you have ideas for more improvements of the package?
Or are you looking for other workflows with functionality the API provides but is not usable from vSphere Client?
Leave a comment, insert a coin (or spend a drink at VMworld 🙂 ) and be patient!

Clone from old Snapshot-Package
Clone from old Snapshot-Package
31.3 KiB

vCenter Orchestrator@VMworld 2011

UPDATE: Don’t miss the Orchestrator-#vMeetup at Thursday, 12pm!

The Content Catalog & Session Builder for VMworld 2011 in Las Vegas is online:

Filter by “Orchestrator” you’ll find following Sessions about VMware’s Sleeper Cell:

Page 21 of 26« First...10...1920212223...Last »