Tag Archives: vCO

My First vCenter Orchestrator Workflow – Part 3 – Create a test workflow and see the awesomesauce

imgOrchestrateOk we are finally getting somewhere now with this series! So far we have downloaded, installed, and configured our vCO appliance. As well, we have registered our vCO instance with both vCenter and our SSO instance. This post will take us through verifying and testing our installation by creating and setting up a small workflow that we can then assign to some inventory objects inside of vCenter. This will allow us to perform that right-click magic in the Web Client and see for ourselves some of the awesome integration vCO and vCenter have.


With that said let’s get started on our test workflow. To do so you will need one of clients available to vCO. As you can see in the screenshot vCO provides you with a couple of options to start the client; one simply runs a java applet and the other let’s you install a client directly on your machine – whichever method you chose you end up sitting at the exact same login screen. Once you get there you should be able to simply input your vCO IP as the Host name and your proper credentials.

OK! So here we are, the vCO workflow development interface. Look a little foreign to you? No worries, it did to me as well. Actually, it still kind of does, this is just “My First” vCO workflow remember! So for the most part I’ve only really explored the workflow icon (shown below).  The others are simply Home (home), Scheduler (Allows scheduling of workflows), Policies ( Allows other plugins to trigger the kick off of workflows), and Inventory (You will see your vCenter inventory objects here). For now, we need the Workflows section active.vCOWorkflowWorkspace


So after you expand the Library tree you should see several folders by default. These folders contain all of the workflows that vCO is aware of. Obviously we can add more by creating our own or installing plug-ins (covered in Part 4). For now we will just create one of our own workflows. Before going to crazy I always like to create my own folder for things like this. I get a bit nit-picky about file management sometimes 🙂 To do so is pretty simple – Right Click Library -> Add New Folder and give it a name!



So now it’s time to create our workflow – Again Right-Click the folder you want to store it in and Select New Workflow and name it. At this point a new window, the workflow editor will open up. There is a lot of information and tabs here and to be honest I’m not going to explain what they all are. Partly because it would make this post much too long, but mostly because I don’t have a grasp on what they all are :). The main tab that we will be working in is called Schema. This is where we setup all of the flow elements inside our workflow. Once there you will see our main window is displaying the flow of everything, and the left hand side is showing all of the workflows that we can add to our workflow. The one I am interested in is ‘Reboot host’ As you can see you can browse through the tree of All Workflows to get to it or you can simply use the filter box at the top to search for specific workflows. Once you find it you simply add it to your workflow by dragging it into your flow window.


vCOPromoteInputsAfter doing so you will see a black bar along the top of the screen asking about the activities parameters. Something to know – workflows have inputs and outputs – these are pretty self explanatory. When we created the workflow initially it had inputs and output, and then when we dragged the Reboot Host workflow into ours it also had inputs and outputs. So what this is asking is if we would like to move the Reboot Hosts inputs into our workflows inputs. In this case this is something we want to do. So go ahead and click ‘Setup’. Now we see our ‘Promote Workflow Input Parameters’ window. This will allow us to do a few different things; First of all, we can promote or move our inputs from the reboot host workflow to our workflow, and secondly we can decide to assign default values to them at the same time. As you can see, the ‘Reboot Host’ workflow takes two inputs; one being the host and the other being the force switch. Leave host as it is but if you want you can set a default value of ‘Yes’ to force by selecting the value option and then the yes option. Then click ‘Promote’.

If you look at your Inputs section now you will see that only host is listed. This is because we require the user to tell us or select the host we wish to reboot. But wait, what about force?!?! Well, by assigning a default value to this input parameter we have actually converted this to an attributes. Attributes are available on the General tab. Anyways – this workflow is now complete! Go ahead and select ‘Save and Close’. You will notice that vCO will also handle a bit of version history for us! Awesome stuff!

Alright! We are done with vCO for now. Let’s flip back to our web client and assign this workflow to be executed on certain objects. Navigate through the web client to the vCenter Orchestrator section, then Select vCO Home and look in the Manage tab. This is where we will add our newly created workflow to our right-click context menu when associated with host. Click the + sign to add a new workflow. In the Available workflows browse through the tree until you find your workflow and click ‘Add’, then select the inventory objects to run it on – in our case, just a host and click ‘OK’


So, after all of this we are now ready for the awesomesauce! Get back into your Hosts and Clusters view and right-click on a host. Once the ‘All vCenter Orchestrator Actions’ menu loads have a look at what you see! Reboot Craziness!!! Your workflow!! If you see fit, go ahead and select it to kick off the workflow. You may be prompted for a token delegation – if so go ahead and click ‘Approve’ – I have no idea what this is 🙂 When your workflow window opens you can see that your host has already been pre-populated with our right-click. You can click Finish to start the workflow immediately or Next to setup a schedule of sorts. ***Warning – this will reboot your host *** – don’t know if that’s needed but whatever 🙂


So there you go! We’ve successfully created a test workflow in which we integrated into and executed from the vSphere Web Client. Pretty awesome stuff! I hope you are starting to see some of the benefits of vCO now! Next we will get back on track with our workflow and dig a bit deeper into creating workflows by installing the Powershell plugin and getting vCO to execute a script for us!

My first vCenter Orchestrator Workflow

My first vCenter Orchestrator Workflow – Part 2 – Installing vCenter Orchestrator

orchestrate2Welcome to the second part of My first vCenter Orchestrator Workflow series.  Now before we can really get into the functionality of vCenter Orchestrator we obviously need to go through the task of getting vCO installed and configured. VMware has provided a couple of different ways to do this; one being installing on a Windows box, normally on the same server as your vCenter Server. And the second being through the download of a virtual appliance. For the sake of this series I will go over the installation and configuration of the appliance as it seems to be the trickier of the two.  If you go with the windows installation it is simply included as an installable package on the vCenter Server media.

So first off you need to go and download the vCO appliance through your myvmware account.   vCO is bundled in with vCenter Server so if you have a copy of vCenter you are good to go with vCO (I think foundation only comes with the ability to run workflows and not edit)   From here you simply need to import the ovf appliance into your environment using the typical  File -> Deploy OVF Template and power it on.

Once the appliance has fully booted you will notice that it displays a slew of URLs and information.  Don’t worry!  By simply pointing your browser to the IP address of your vCO server you will see the same list – you don’t need to remember all of the ports.   There are a couple we need to pay close attention to here; Orchestrator Configuration (used to perform Orchestrater setup, plugins, ssl certs, etc – this is the main ui you will work in) and Appliance Configuration (the setup pages to manage your actual appliance settings, such as networking, ntp, admin passwords, etc.. )

For your documentation (more so mine) I’m going to list the default usernames and passwords for vCO below as it can be tricky trying to find some of them in the documentation.

Orchestrator Configuration – vmware/vmware – will prompt for new password when you first login
Appliance configuration – root/vmware – change password manually in the ‘Admin’ section.

So to get started let’s browse to Appliance Configuration – As described above here is where you can perform appliance related tasks such as setting up ntp, networking and change your root password. If you have used any VMware virtual appliances before you should be somewhat familiar with this interface.


Same look and feel as most VMware Virtual Appliances

Once you have your network settings configured we can continue on to the Orchestrator Configuration. This is the main interface for configuring all things Orchestrator. We have quite a bit of work to do here so lets get started. After logging in with the default credentials (vmware/vmware) you will be prompted to change the password so go ahead and do so.  Now we need to setup our Orchestrator appliance to listen on the proper IP address which set in the appliance configuration as well as work with the new SSO service that was shipped with vSphere 5.1. To do this we will first stop the Orchestrator server service. This can be done through the ‘Startup Options’ section on the left hand menu, then clicking ‘Stop Service’.



For the network listener, simply select the ‘Network’ menu on the left hand side, then select your IP Address in the associated dropdown box, then click ‘Apply Changes’ Easy peasy so far – well, now we are about to explore SSO and SSL Certificates – yikes!

In the same section (network) select the SSL Trust Manager tab. Here is where we list all of our imported ssl certificates. In order for SSO to work we need import a couple certs; one from our vCenter Server and the other from our SSO service. To do this there are a couple of URLs we need to know.

First enter in the following URL (https://IP_of_vCenter:443/ and click the import button. The certificate should be displayed in your browser. Simply click ‘Import’ once again to pull it into vCO.

Importing SSL Certificates

Importing SSL Certificates

Next we need to repeat the exact same steps excepting using https://IP_of_vCenter:7444/ as the URL.

Now that we have the required certificates we need to setup Orchestrator to point to SSO for authentication purposes which is done by, you guessed it, the Authentication section. Switch your authentication mode dropdown from LDAP Authentication (default) to SSO Authentication. Then you need to input your SSO Host – This will be the same as your vCenter unless you have explicitly installed SSO elsewhere in your environment. Also we need an admin username and password on your SSO host. Remember a way back when when you installed SSO and it was prompting you for admin usernames/passwords – I hope you remember these because we need them now. By default if you didn’t make to many changes your username might be admin@SYSTEM-DOMAIN – unfortunately I can’t help you with your password 🙂 Once done select ‘Register Orchestrator’.

vCO will authenticate users using the SSO installation included in vSphere 5.1

vCO will authenticate users using the SSO installation included in vSphere 5.1

On the next page you can actually put more restrictions on who can and can’t be a vCO administrator. I left all defaults here and simply clicked ‘Accept Orchestrator Configuration’.  Basically you are configuring what users or groups can be vCO admins.

Alright, almost there – Now let’s go ahead and get the vCenter Server plugin installed and activated – we will go a little more in depth with plugins later so I’ll leave most of the details out that this point.  Simply select your Plug-ins menu and enter in a username and password in the boxes provided (SSO should be working now), select the checkbox next to the vCenter Plug-in and click ‘Apply Changes’ .

Installing the vCenter Plug-in

Installing the vCenter Plug-in

This might be a good time to give your vCO server a nice clean reboot or at least restart the services under Startup Options.  As you can see there are a few plug-ins stating they will perform the installation at the next server setup.  Either way you should see a vCenter Server menu option appear, once it’s there select it, then go to the ‘New vCenter Server Host’ tab. Fill in all of the information in regards to your vCenter Server

Adding a vCenter Server

Adding a vCenter Server

As you can see most the options here are pretty basic with the exception of the user strategies.  Basically ‘Share a unique session’ will result in orchestrator creating only one connection back to your vCenter Server.  This will certainly use less resources and may be ‘secure-enough’ for some small deployments.  The ‘Session per user’ option will actually execute the workflows under the user credentials of the user that is logged into Orchestrator.  This does have the ability to use a few more resources however provides a bit more secure and audit-able environment.  I used the ‘Share a unique’ session as I’m just running through my lab at this point.

OK, i told you we had a lot of work to do in here – but for the most part we have things configured now. If you want to double check you can log in to your vSphere Web Client, Select the vCenter Orchestrator item on the left hand navigation menu and you should be able to drill down and see your new vCO server registered.  If not and you have followed all these instructions to a tee with no break, you may want to give your vCO server a reboot and have a look. It should be there  🙂

vCO registered within the vSphere Web Client

vCO registered within the vSphere Web Client

At this point you can give yourself a huge pat on the back.  You’ve now succesfully setup and configured the vCO virtual appliance and have registered it within your vCenter Server.  In the next portion of this series I will discuss how to create a small test/sample workflow in order to test our integration between vCenter Orchestrator and the vSphere Web Client.

My first vCenter Orchestrator Workflow

My first vCenter Orchestrator Worlkflow – Part 1 – Introduction

Orchestrate all of the thingsvCenter Orchestrator in it’s basics is a workflow development tool that can be used to schedule and automate multiple tasks in your environment.  A tool that can be used to create and execute workflows not only on your vSphere environment, but with the use of plugins you can manage other types of applications such as Active Directory, SQL, etc.  In the past I’ve often heard of vCO being described as a hidden gem inside of your vCenter Server; meaning it’s usually already there and licensed  but for the most part, you are probably not using it.  Such is the case with myself. I’ve often thought about trying to learn this technology in order to execute some of my common day to day tasks through a more automated and scripted fashion but I’ve always resulted to things like PowerShell and PowerCLI to do the same job.  Why?  Well, comfort really.  I already have a good handle on Powershell technology and could get things done faster there rather than learning something new.  That being said with the introduction of vSphere 5.1 a bunch of new features and enhancements were made with the vCenter/vCO interoperability.  The biggest IMO was the ability to execute a vCO workflow while directly inside of the vSphere Web Client – contextually!!!  This integration is what enticed to have a closer look at vCO.  Basically I now have the ability to create workflows that can do pretty much anything and grant access to myself or to others to simply right-click a host from within vSphere and execute them.

contextualThus leads me to these series of posts where I will try and take you though my experiences with vCenter Orchestrator; and it couldn’t come at a more opportune time.  I have approx 50 hosts to configure and deploy within the next few months and in effort to keep them consistent I decided to do so with a PowerCLI script that I had written a while back.  The only difference being I will be executing this script through vCenter Orchestrator (to get that super awesome right-click functionality).  Now there is certainly some overlap here.  A lot of the actions that the PowerCLI script performs actually have workflows already created in vCO that do the same thing however in this case I’ve decided not to use them – baby steps right!  Also, it helps to highlight the power of the vCO plugins – I can in fact do things like execute PowerShell commands, run queries against SQL servers, move objects around in Active Directory, etc.

So with that said I guess you could call this post an introduction of sorts with nothing too technical included.  Be sure to check out Part 2 – Installing and configuring vCenter Orchestrator where we will dive a bit deeper into the setup of vCO.

My first vCenter Orchestrator Workflow