Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: vco

Tag Archives: vco

How Much Javascript Do I REALLY need to know for VCO?

I find vCenter Orchestrator to have an extensive library of workflows, actions, and plugins to do what I need.  However, sometimes I do have to use the customizable Scriptable Task element to customize the behavior of a vCenter Orchestrator workflow.  Thankfully, this is super easy to do as the Scriptable Task is a very powerful element that allows me a full range of programmatic manipulation using the simple, open language of javascript.

When I use the Scriptable Task 99% of the time what I need to do centers around if/then/else, loops, data structures (arrays, objects), common method calling (the System object, the Server object, and plugin objects) variable retrieval (vm.config.hardware.numCPU), and string transformation (character strip, match, substring, format, etc).  So what does that really look like?  In this example our vCloud Automation center needs to add a machine to AD as part of the post provisioning process.  The “ou” parameter is passed in to the vCO flow, and we will use the AD plugin to search for the AD:OrganizationalUnit object and assign that object to the “group” variable. The group variable gets bound as an “Attribute” in our workflow and then passed in to the “Create a computer…” workflow element in order to add the server to the specified OU.  But first we must do some basic error checking to determine if the group exists first.

This could be a 7-10 element flow if you used the flow control elements and the Active Directory Plug-In actions in a flow.

OR – we could just use a Scriptable Task, grab those input vars, and use the AD object from the AD plugin in javascript!

A little if/then/else error checking, and then pluck the first matching group off of the returned array – DONE!

WHEW* simple right?  😉

Also, some best practices around flow creation with Scriptable objects is that you are creating re-usable packages.  So each one should be a short block of about 20-30 lines, and you should try to rename them that describes what they do.  For example:

It’s easier to understand what this does:

Than this:

Laying out your flow with Scriptable Tasks first, renaming them, and then filling in the javascript afterwards might also help you plan your workflow and save you time in the long run.

If this post just scared you a little (and I completely understand if it did), you can read more on best practices at www.eloquentjavascript.net.  Also, if you’re looking to refresh some of your javascript skills I recommend spending an hour on CodeCademy.com, which has a free, interactive javascript course you can take using your browser.  Remember to focus on the data structures and language elements I specified above.

Article by: Jennifer Galvin – Sr. Systems Engineer

VMware vCenter Orchestrator makes a splash at VMworld US 2013 – Day 1

VMworld US 2013 kicked off Monday with a keynote by Pat Gelsinger, CEO of VMware, mentioning the importance of management and automaton in the Software-Defined Data Center (SDDC).  Also mentioned was the inclusion of vCloud Automation Center (vCAC) in the Standard, Advanced and Enterprise editions of the upcoming vCloud Suite release.  With bidirectional integration between vCenter Orchestrator (vCO) and vCAC, native vCO workflows can be coupled with resources managed by vCAC, either as part of the provisioning process, or as a Day 2 operation.  The upcoming vCAC Extensibility Package for vCO affords customers the ability to use vCO as a configuration tool for vCAC extensibility. Instead of manually reconfiguring stub workflows in vCAC to call vCO, the configuration workflows in the Extensibility package will do it for you.  Customers choose a workflow to be executed at a given point in a machine’s lifecycle (i.e. run a workflow before the machine is built), then select the blueprint(s) that should call the specified workflow.  vCO then calls into vCAC and programmatically wires up the specified vCO workflow to the blueprint(s).  Alternatively, vCO can expose and assign its own workflows as Day 2 operations to the contextual Machine Menu in vCAC (think right-click or hover menu), then enable that machine menu item on specified vCAC blueprints.  Very powerful stuff!

In addition to the reference in the keynote, two vCO-specific breakout sessions were held on Monday:

VMworld US 2013 session VCM4875 – Part 1: Getting Started with vCO

VCM4875 – Part 1: Getting Started with vCenter Orchestrator

This session was vCenter Orchestrator’s opportunity to shine, and the room was filled to capacity. The session was presented jointly by James Bowling, Cloud Architect at General Datatech LP, and Savina Iliena, VMware Product Manager for vCenter Orchestrator server.

James talked about his own experiences with vCO, and demonstrated a few things he put together, bravely presenting them in a live demo.  Savina took over in the second half of the session to talk about the new features coming in vCO 5.5, specifically the new Debugger and the High Availability configuration.  This news was well received by the crowd, and by the end, you could tell they were excited to try out vCO in their own environments.


PHC6050 – Moving Beyond Infrastructure: Meeting Demands on App Lifecycle Management in the Dynamic Datacenter

F5’s Charlie Cano presenting on vCenter Orchestrator at VMworld US 2013

This session was co-presented by Charlie Cano of F5 and Dan Mitchell of VMware.  The session focused primarily on vCO’s capabilities around provisioning, configuration and remediation using their brand new vCO plug-in.

Charlie started the session off by asking how many folks owned vCO, and only a few hands went up.  He informed them they own vCO if they own vCenter, which seems to have caught a number of them by surprise.

F5 did a great job getting the initial release of their new plugin completed in time for VMworld. Thanks to Charlie Cano at F5!


Be sure to check out the other vCenter Orchestrator sessions at VMworld US 2013:



VCM5695 – Part 2: How to Build a Self-Healing Data Center with vCenter
   presented by Dan Mitchell, VMware Product Manager and Nick Colyer of CatamaranRX
   Wednesday, Aug 28, 8:30 AM – 9:30 AM – Moscone West, Room 2006

…and as always, stay current with the latest product updates via Twitter by following @vCOTeam, @StartsWithV and @VMwareCloudAuto


The More vCO @ VMworld 2013 – The Better: vOTING Guide

Dear vCO Fans,

The best season of the year is just few months away. Yes, it is real – It is VMwolrd season of 2013. Please, be aware that there is a Public Session voting process in place at www.vmworld.com.

It is pretty easy to get lost while browsing so many great ideas available for voting. There is no need to worry – the usual suspects are also in place with creative abstracts (Christoph, Joerg, William , James Bowling …). Beside this, there are lot of new folks proposing catchy titles, revealing the power of vCO.

Please, take your time to review through the list of vCO related ideas.

4875 vCenter Orchestrator: A Beginner’s Guide – James Bowling, iland

5242 Extending vCloud Automation Center with vCenter Orchestrator; Rich Bourdeau, VMware

5287 Open up the vCloud hood using PowerCLI, Hyperic, vCenter Operations Manager and vCenter Orchestrator to reveal the inner cloud; Phil Ditzel, VMware;Cathal Cleary, VMware

5352 Automating the Software Defined Datacenter with vCAC, vCO and Storage Automation, Jeremy Goodrum, NetApp; Joerg Lew, VMware

5360 vCenter Orchestrator Best-Practices – Joerg Lew, Christophe Decanini, VMware

5365 “7 Design Patterns for vCenter Orchestrator Workflows” – Joerg Lew, VMware

5472 vCO – Say hi to Razor and Software Defined Storage, Magnus Nilsson, EMC; Jonas Rosland, EMC

5586 Optimize Application deployment time and lifecycle management via vCloud automation Center (vCAC) and vCenter Orchestrator (vCO), Boskey Savla, iGate Technologies, Inc. Indranil Bal, iGate Technologies, Inc.

5695 How to Build a Self – Healing Data Center with vCenter Orcestrator (vCO), Dan Mitchel, VMware

5703 Supercharging vSphere Web Client with vCenter Orchestrator (vCO) Dan Mitchell, VMware, James Bowling, vSential

5717 How to Automate ANYTHING with vCenter Orchestrator (vCO): Dan Mitchell

5731 Become a Rock Star with PowerCli and vCenter Orchestrator; Josh Atwell, VCE

5923 vCenter Orchestrator: Customize Your vSphere Web Client Experience – James Bowling, vSential

So be sure to go to www.vmworld.com to review submissions and vote before 6 May 2013.

And to all submitters… thank you and best of luck!


The vCO Team



vCenter Orchestrator 5.1 Update 1 Released

Voila! vCenter Orchestrator 5.1. Update 1 Is Now Available!

This is not just an ordinary update release.  vCO 5.1.1 actually incorporates significant enhancement around built-in plug-ins and the vCO platform itself.

Please, take your time and read throughout the outlines below to find out more about this compelling release.

vCenter Server configuration

Yes, it is true: tedious manual configuration of vCenter Server is no longer required when you use vCO 5.1.1.  The new release provides out-of–the box workflows that automate the configuration of vCenter Server instances, thereby allowing you to dynamically provision vCenter Server capacity  in your datacenter.

Notifications, notifications, … and more notifications

Sending and receiving e-mail notifications have always been an important part of most automation processes.  In addition to POP, vCO now provides out-of-the-box support for the IMAP protocol. And triggering notification or notification-based workflows have never been easier thanks to significant improvements in available scripting methods.  The E-mail plug-in has been extended with several new scripting objects that can be used either with the IMAP or POP client for:

  • Retrieving messages
  • Reading details of the retrieved messages as well as file attachments
  • Searching messages
  • Deleting messages

Fine-tuning and fixes

When it comes to workflow development, we all know that the sum of little things is what adds up to a great experience.  With that in mind, we’ve included quite a number of changes and fixes that we trust will go a long way to improving your experience:

  • The zooming feature in the workflow schema has been enhanced so that it re-centers on the selected element(s).  It is now available in the contextual element menu and as a shortcut.
  • Copy and paste is the key to productive workflow development. vCO 5.1.1 is enhanced not to miss any of the properties of your workflow activity element during the copy paste process.
  • Take a deep breath and relax – no more issues with JSON.  vCenter Orchestrator 5.1.1 introduces a new JSON format that can be used by providing the Accept: application/json;v=5.1.1 header

For a complete list of all fixes, please be sure to read through the vCO 5.1.1 release notes and documentation listed below.

VMware vCenter Orchestrator 5.1.1 Download Landing Page:




Documentation Landing Page:


Release notes:


VMware Releases vCenter Orchestrator Gifts in Time for the Holidays

As 2012 comes to a close, we thought it would be a great time to end the year with some gifts to put under your (virtual) holiday tree!

2012 was a great year for automation in general, with the launch of the vCloud Suite 5.1, and orchestration in particular, with the release of vCenter Orchestrator 5.1.  Our team was extremely happy to see a tremendous increase in vCO adoption, and a growing list of integrations with other management systems.

In that spirit, we are very glad to announce the availability of several integrations and learning tools to make your automation projects easier than ever before.

1. vCloud Automation Center 5.1, which was just released, provides the ability to extend pre-built processes and post-provisioning actions by invoking vCO workflows. This means that any technical integration or logic built in vCO can be leveraged by vCAC’s lifecycle-management platform, thereby broadening the realm of self-service provisioning and basic administration for consumers of IT services.

2. Reversely, the new vCenter Orchestrator Plug-in for VMware vCloud Automation Center allows organizations to automate vCAC provisioning and post-provisioning tasks. With these two components, customers can leverage full bi-directional integration capabilities between vCloud Automation Center and vCenter Orchestrator.

3. Another new offering is the vCenter Orchestrator Elastic Service Plug-in. This plug-in provides a foundation for the self-scaling virtual datacenter, by automatically balancing the physical resources between virtual datacenters in VMware vCloud environments. This plug-in contains a rules engine that can analyze resource usage metrics (for instance, metrics captured by vCenter Operations Manager) and make scale-up or scale-down decisions automatically.

4. The vCenter Orchestrator Plug-in for VMware Service Manager enables organizations to automate operations around Configuration, Incident, Task and Service Request management.  Thanks to this plug-in, repetitive tasks such as updating an Incident or creating a Configuration Item when a new virtual machine is provisioned can now be fully automated.

5. And to help you take advantage of all of the above gifts, the VMware Training department just released over 10 self-paced vCO training videos available for free!

For additional information on these materials, please visit the following sites:


The entire vCO team wishes you the very best for the holidays and 2013.


Your Guide to “Orquestación” Goodness at VMworld 2012 Barcelona


You can decide to refresh your Spanish (or even better yet, your Catalan) and memorize the following sentence:

¿Por favor, donde son las demos y sesiones sobre vCenter Orchestrator?

Or you can make it easy on yourself and use the list below to help with your orchestration immersion planning at VMworld 2012 in Barcelona 🙂

Below is a list of events you won’t want to miss…


Breakout Sessions and Group Discussions

INF-VSP2033  Auto Scaling and Cloud Bursting in the Hybrid IaaS cloud

OPS-CIM1274  What’s New in vCenter Orchestrator 5.1

OPS-CSM1379  Extending vCloud Director

OPS-CIM2892  Making IaaS and APaaS Available to the IT Masses: Rolling Out Self Service for the Cloud

OPS-CIM2179  Transforming Your Cloud with VMware: Day One – Building Your Cloud

GD-41  vCloud Director Architecture, Integration and Orchestration with Chris Knowles


Hands-on Labs

HOL-OPS-07  vCenter Orchestrator “The undiscovered country”

HOL-PRT-01  Automate IP Address Assignment & DNS Registration with Infoblox

HOL-INF-09  Deliver your IT Services in the Cloud



EMC, F5 Networks, Infoblox, Radware, VCE and VMware for some really cool demos…


We had some great discussions with many customers in San Francisco and are hoping to repeat that in Barcelona.  So please, come by the VMware vCO/DynamicOps booth to see the latest 5.1 release, share your experiences, and get your questions answered.

¡Hasta pronto!

The vCO Team

VMware vCenter Orchestrator 5.1 is now GA!

As part of the broader announcements around vSphere 5.1, we are extremely glad to announce the general availability of vCenter Orchestrator 5.1!

As we mentioned last year, 2011 was all about bringing you new plug-ins (and more plug-ins…) to simplify multi-system integrations.

Whereas the emphasis on plug-ins has not stopped, we are extremely excited to announce that vCO 5.1 includes some major new capabilities!


Launch Workflows Directly from the vSphere Web Client

vSphere administrators and operators can now launch vCO workflows directly from the vSphere Web Client, thereby saving precious time and preventing the need to switch into and out of multiple user interfaces. Operators can use the vSphere Web Client to launch any workflow, whether pre-built, custom, and whether it interacts with VMware or partner applications! Operators can run workflows from the vSphere inventory browser in just a couple of clicks. Based on the object from which it is run (for instance a host or a VM), a workflow’s input parameters get populated automatically to save time and eliminate errors. Operators can run multiple workflows concurrently, or schedule them as recurring or future off-hour tasks. For larger organizations, administrators can allow different groups of operators to have access to different categories of workflows.


Develop Workflows More Easily

Workflow developers can also benefit from a simpler, faster, and more enjoyable development experience thanks to a complete redesign of the Workflow Designer. The new Designer allows workflow developers to use multiple screens, detach windows, customize workflow icons, and perform many more operations in just a single click. Auto-attach and auto-layout capabilities also greatly reduce development time. And to simplify workflow administration, vCO 5.1 introduces new capabilities such as version control and automatic generation of workflow documentation in PDF.


Richer Integration Capabilities

vCenter Orchestrator 5.1 includes a new REST API that does everything covered by the current SOAP API… and more! The new REST API provides more control and flexibility when launching workflows programmatically. It also introduces support for new capabilities around content management such as workflow and package importing and exporting. In short, vCO administration itself can now be more easily automated.

These are just the major new capabilities but you’ll find plenty of additional enhancements that simplify and enhance the automation of your virtual and cloud infrastructure. For a full list of new features and capabilities, please refer to the detailed overview or the release notes.

And finally, while vCO 5.1 is a major enhancement over version 4.2, you’ll still be able to leverage all of the work you’ve already created in the previous release.

So don’t wait any longer! Try it today and let us know what you think via blog comments, Twitter (#vCO) or the vCO Community.


The vCO Team



Configuration Elements revisited

What are Configuration Elements?

A configuration element is a list of attributes you can use to configure constants across a whole Orchestrator server deployment. That’s what the vCO documentation states. In other words, the configuration elements are the easiest way offered by vCO to organize and establish a set of constant values which will be accessible from any key element of vCO (workflows, policies and web views).


A configuration element is a vCO entity composed basically of a list of attributes which are defined by a name, a type, and (once it’s configured) a value. Moreover, configuration elements support versioning, user permissions and access rights like other vCO entities.

How to create Configuration Elements

The creation of configuration elements is detailed on the official documentation, so there’s no need to describe it here (see http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.vco_dev.doc_42/GUID1A027CCA-B462-4580-A7E5-F0431CF75C3A.html).

How to use Configuration Elements

As example let’s define a workflow with some inputs, attributes and a scripting block that require to access to some configuration element to get the value from its attributes. The sample workflow would be used to send e-mail notifications from vCO, for example when some external event occurs or some specific condition is satisfied.

So on the one hand the workflow “Send notification message” defines these inputs:

  • To: the addressee of the notification (an e-mail address)
  • Subject: the subject of the notification e-mail
  • Body: the notification message itself

Also it contains this attribute:

  • From: the sender of the notification (a default e-mail address)

And furthermore, before sending the notification the workflow attaches a predefined footer to the body of the e-mail.


On the other hand the configuration element “Email” defines these attributes:

  • default_sender: the sender’s e-mail address, which will be different for different environments (e.g. development, integration or production)
  • default_subject: the default subject of the notification e-mail
  • default_footer: the default footer of the notification message, which may contain for example a legal notice text


Now let’s match the workflow elements with the configuration element attributes.

To set the value of an attribute
In that case it’s a workflow attribute but it’s exactly the same process for attributes of policies and web views.
You have to go to the General tab of the workflow in edit mode and select the option of linking the value of the attribute to a configuration element attribute. Then you choose the proper configuration element and the desired attribute.


Once you select the attribute it appears linked on the workflow’s attribute value.


In this way you linked the attribute “from” of the workflow to the value of the attribute “default_sender” of the configuration element “Email”. And after that you can use the attribute “from” like any other attribute inside the workflow.

To set the default value of an input parameter
The easiest way starts like setting the value of an attribute. You create an attribute called “default_subject” in the workflow and you link it to the value of the attribute “default_subject” of the configuration element “Email”. After that you go to the Presentation tab of the workflow in edit mode, select the input “subject” and add the property ”Default value”. Then you link the value of that property to the workflow attribute “default_subject” that you have just created.


Once you select the attribute it appears set on the “Default value” property value.


In this way you linked the input “subject” of the workflow to the value of the attribute “default_sender” of the configuration element “Email”.

To set the value of a variable inside a scripting block
The easiest way again starts like setting the value of an attribute. You create an attribute called “footer” in the workflow and you link it to the value of the attribute “default_footer” of the configuration element “Email”. After that you go to the “Schema” tab of the workflow in edit mode, select the Scriptable task element and add as a local input parameter the workflow attribute “footer”.


In this way you linked the scripting task input “footer” to the value of the attribute “default_footer” of the configuration element “Email”.

And once you have all the inputs of the Scriptable task element set properly you can actually write the code that will send the email (for example you could use the Mail plug-in and its EmailMessage object).


How to access Configuration Elements directly via scripting

The previous section describes how you can access to configuration elements via workflow attributes. That’s the easiest way but it has some minor drawbacks (or major if you use configuration elements a lot from your workflows). The two main drawbacks are:

  • You must define an extra workflow attribute for each configuration element attribute that you want to use inside that workflow.
  • You must set those workflow attributes as input parameters of each Scriptable task which you can get the attribute’s value from.

Alternatively, to avoid using extra workflow attributes, you can make us of a custom action that implements the logic for accessing to the proper configuration element attribute and getting its value. For example you can define an action like this, inside the module “org.company.mymodule”:


This action receives as parameters the path to find the configuration element, the name of the configuration element and the name of the attribute that you want to get from the configuration element. With that information the action tries to find the proper configuration element and return the value of the desired attribute.

The best is that you can invoke the action very easily from the presentation of a workflow (e.g. the case of the “Default value” property):


And you can invoke it also very easily from inside any Scriptable task without passing any extra input parameter to the Scriptable task itself:


The main benefits of that method are:

  • You avoid the extra workflow attributes.
  • You can invoke the action directly from workflow presentation elements.
  • You can invoke the action directly from any Scriptable task.
  • You could replace the logic of the action that gets the values from the configuration elements and use, for example, an external properties file or a database. Since you are writing the code here you have infinite possibilities.

And the only drawbacks are:

  • You have to make sure that the action is included inside your package.
  • You have to make sure that the proper configuration elements are included inside your package as well.

How to import/export Configuration Elements

You can import/export configuration elements in two ways:

  • Import/export a single configuration element
  • Import/export a set of configuration elements inside a package

The first way, import/export a single configuration element, is not very common. Here you probably want to import or export some specific configuration settings at development time to try them somewhere else. In that case, when you export the configuration element you get a file which contains the definition of the configuration element with both the list of attributes (names and types) and the values for those attributes. And when you import that file you create a new configuration element in vCO with again both the list of attributes and their values.



The second way, import/export a set of configuration elements inside a package, is the most usual because the configuration elements are used from other vCO entities. That’s why if you create a package containing a workflow, action, policy, or web view that uses an attribute from a configuration element, vCO automatically includes the configuration element in the package. Nevertheless there is a small difference with exporting a single configuration element, the difference is that in that case the values of the attributes are not exported! In another words, if you import a package containing a configuration element into another vCO, the configuration element attribute values are not set. This is because the configuration elements are supposed to define vCO server-specific settings. And for example, if you set the server-specific attributes directly in a workflow, the workflow probably won’t work with the same settings if you import it into a different server or environment. That’s why after importing a package that contains configuration elements you have to set them with values appropriate to the new server, otherwise some elements could fail (workflows, policies, etc.) because they might not find the attribute values that are required.


The configuration elements are a powerful mechanism offered by vCO to define constant values across multiple vCO entities. They are easy to create and easy to use in many common scenarios. And the only thing to be aware of is that when exporting and importing them inside a package, their attributes need to be set to the proper values of the new environment.

vCO PowerShell plug-in

vCenter Orchestrator + PowerShell plug-in = vCenter Orchestrator on steroids. Windows PowerShell is command-line shell and scripting language designed especially for system administration, as such he has wide-spread industry support. There are PowerShell scripts already written for most of the task you will ever need. Enabling vCO user to use and reuse those scripts is one of the most exiting feature of vCO. In short vCO PowerShell plug-in is used to call PowerShell scripts and cmdlets from Orchestrator actions and workflows, and to work with the result.

PowerShell host configuration

One of the drawbacks of PowerShell is that it is windows dependant. That's why we need a Windows machine with PowerShell instaled on it (PowerShell host). Connection between the PowerShell plug-in and PowerShell host machine is established using WinRM or OpenSSH. To configure PowerShell plugin make sure that winrm service is installed on the PowerShell host and run trough following configuration steps.


  • Run the following command to set the default WinRM configuration values.
    c:\> winrm quickconfig
  • (Optional) Run the following command on the WinRM service to check whether a listener is running, and verify the default ports.
    c:\> winrm e winrm/config/listener The default ports are 5985 for HTTP, and 5986 for HTTPS.
  • Enable basic authentication on the WinRM service.
    • Run the following command to check whether basic authentication is allowed.
      c:\> winrm get winrm/config
    • Run the following command to enable basic authentication.
      c:\> winrm set winrm/config/service/auth @{Basic="true"}
  • Run the following command to allow transfer of unencrypted data on the WinRM service.
    c:\> winrm set winrm/config/service @{AllowUnencrypted="true"}
  • Enable basic authentication on the WinRM client.
    • Run the following command to check whether basic authentication is allowed.
      c:\> winrm get winrm/config
    • Run the following command to enable basic authentication.
      c:\> winrm set winrm/config/service/auth @{Basic="true"}
  • Run the following command to allow transfer of unencrypted data on the WinRM client.
    c:\> winrm set winrm/config/client @{AllowUnencrypted="true"}
  • [Updated] Run the following command to enable winrm connections from vCO host.
    c:\> winrm set winrm/config/client @{TrustedHosts ="vco_host"} 
  • Run the following command to test the connection to the WinRM service.
    c:\> winrm identify -r:http://winrm_server:5985 -auth:basic -u:user_name -p:password -encoding:utf-8

Before start working with a PowerShell host you need to register it in vCO.

Add a PowerShell host validates connection to PowerShell and registers the host only if connection is successful. The difference between shared and not shared mode is which user credentials are used to connect to PowerShel host

  • Shared Mode – in this mode all users are using the same credentials
  • Session Per User – in this mode the currently logged user credentials are used

Invoke a PowerShell script

Having an existing PowerShell script you can invoke it without any modifications. Invoke a PowerShell script workflow is suitable for single invocation of script. The result from execution will be available into vCO log tab. This workflow requires you to specify the target host, and the script to be executed. For example we will invoke following script trough vCO:

# Get set of adapters
$adapters  = [System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces()
# For each adapter, print out DNS Server Addresses configured
foreach ($adapter in $adapters) {
    $AdapterProperties = $Adapter.GetIPProperties()
    $dnsServers        = $AdapterProperties.DnsAddresses
    if ($dnsServers.Count -gt 0){
foreach ($IPAddress in $dnsServers) {
"  DNS Servers ............................. : {0}" -f $ipaddress.IPAddressToString

This script first gets all the interface objects, then iterates throught them to get the DNS address(es) configured for each one.


Check script output in Log tab.


Invoke an External PowerShell script

Invoke an external script workflows is suitable for running external “.ps1” scripts available on the host machine (.PS1 being the file extension for Windows PowerShell scripts). Required parameters for this workflow are “Name” and “Argument”. The “Name” parameter can be simply the name of the script for example “test.ps1” (if it is available on host machine “Path”) or full path “c:\SomeDirectory\test.ps1”. Script arguments are provided through “Arguments” parameter and the syntax is the same as the one of PowerShell.exe console.


Generate an action from a PowerShell script

PowerShell plug-in allows you to preserve PowerShell script as an action that could be used later in your custom workflows, and even executed on different PowerShell hosts. To achieve this run “Generate an action from a PowerShell script” workflow providing the script. Script customization can be achieved using placeholders. The syntax for defining a placeholder is {#ParamName#}. For each placeholder corresponding action parameter of type string is created in generated action. During action invocation the placeholder is replaced with actual value provided as action parameter.


Generated action looks like.


Sample workflow for running the generated action will be generated if “Generate Workflow” option is “Yes”. The workflow will be generated in provided folder and the name of the workflow will be “Invoke Script ” followed by name of generated action.


Generate an action for a PowerShell cmdlet

Another feature of the vCO PowerShell plug-in is the ability to generate action based on PowerShell cmdlet. This way you are able to use functionality that is already available in PowerShell inside vCO. To generate action for given PowerShell cmdlet select the cmdlet from inventory tree, and specify which parameter set will be used during action generation.



  • More info about VMware vCenter Orchestrator Plug-In for Microsoft Windows PowerShell: release notes, documentation and download


    VMware Releases Four New VMware vCenter Orchestrator Plug-ins!

    As 2011 comes to an end and the holidays approach quickly… it just felt right to thank the fast-growing vCO user community with a set of new shiny toys.  Not to mention that, like people with children know all too well, we've heard these requests over and over again throughout the year… 😉

    So on this holiday note, we are extremely pleased to release four new plug-ins that should help you achieve your 2012 cloud automation resolutions!

    1. The first one is the VMware vCenter Orchestrator SQL Plug-In.  Who hasn't had a need to automate operations on database tables and records?  Well, now you can do so without actually having to write any SQL statements.

    2. The second is the VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy.  Considering the move to a stateless ESXi architecture?  If so then this plug-in is definitely for you. 

    3. Third is the vCenter Orchestrator Multi-Node Plug-In.  As you increase the scale or geographical reach of your automation solutions, you may need to deploy more vCO server instances.  In that case, this new plug-in makes it a lot easier to manage several vCO instances from a single point.

    4. And last but not least… is the vCenter Orchestrator Plug-In for Microsoft Windows PowerShell!  It lets you leverage your existing PowerShell and PowerCLI scripts and opens up so many new capabilities… that we'll need several postings to tell you all about it 😉   So be on the lookout for additional articles on this topic very soon.  In the meantime, we obviously encourage you to take it for a first spin.

    For additional information on these new plug-ins and to download them, please visit the following sites:

    We hope that these new plug-ins will keep you occupied during the holidays.  Seriously, we'd actually prefer that everyone took a well-deserved break, but we know how hard it is not to play with new technology 😉

    So on this note, the entire vCO team wishes you the very best for the holidays and 2012.


    PS.  As always, you can find documentation on vCO and all available plug-ins on the vCO Documentation site.