Tag Archives: vSphere Web Client

Running free VeeamZip directly from the vSphere Web Client

veam_thumb.pngThere are a lot of times I find myself needing to take a one-off backup job of a VM – prior to software upgrades or patching I always like to take a backup of the affected VM(s) in the event that, well, you know, I mangle things.  VeeamZip is great for this – it allows me to process a quick backup of my VM that is separate from its’ normal backup and replication routines.  Since I deal in an environment that running paid Veeam licenses I have access to the Veeam Plug-in for the vSphere Web Client – and this plug-in does exactly what the title of this blog post is – it allows us to perform VeeamZips of our VMs without having to leave the vSphere Web Client and/or log into our Veeam Backup and Replication console.

What if I’m using Veeam Backup and Replication FREE?

So this is all great for me, but I got to thinking – What if I wasn’t running a paid version of Veeam Backup?  What if I was simply running the free version – this doesn’t come with Enterprise Manager, therefore it doesn’t come with a means of getting the Veeam Backup and Replication Web Client plug-in installed – therefore no VeeamZip from the Web Client right? – Wrong!  Ever since Veeam Backup and Replication v8 U2 came out they have been including PowerShell cmdlets around the VeeamZip functionality.  I wrote about how to use it last year in Scheduling Veeam Free Edition Backups.  Well, since we have PowerShell that means we can use vRealize Orchestrator to build a workflow around it – and we have the ability to execute workflows directly from within the vSphere Web Client – so without ado, Running the free VeeamZip functionality directly from the vSphere Web Client.

First up the script

I didn’t get too elaborate with the script as you can see below.  This is simply a handful lines that take in a few parameters; the VM to backup, the destination to store the backup, and the retention, or autodeletion of the backup.

#Load Veeam Toolkit
& "C:\Program Files\Veeam\Backup and Replication\Backup\Initialize-VeeamToolkit.ps1"
#Get the VM Veeam Entity.
$vmentity = Find-VBRViEntity -Name $VM
#VeeamZip it!
Start-VBRZip -Entity $vmentity -Folder $destination -AutoDelete $Autodelete -DisableQuiesce

That’s it for the script – simple right – feel free to take this and add whatever you seem fit to suit your needs 🙂

The Orchestrator Configuration

Before we get to creating our workflow there are a few things we need to do within orchestrator, mainly adding our server that hosts our Veeam Free instance as a PowerShell host within vRO.  But even before we run the ‘Add a PowerShell Host’ workflow we need to run a few winrm commands on the Veeam Free instance.  I have a complete post about setting up a PowerShell host here, but will include the commands you need to run below for quick reference.

First up, on the Veeam server run the following in a command shell…

  • winrm quickconfig
  • winrm set winrm/config/service/auth @{Kerberos=”true”}
  • winrm set winrm/config/service @{AllowUnencrypted=”true”}
  • winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”2048″}

Next, from within vRO (as shown below) we can run the the “Add a PowerShell host” workflow…


As you can see my Veeam Server is actually the same as my vCenter server – don’t recommend doing this but hey it’s a small lab!  Just be sure to use the FQDN of your Veeam Server for Host/IP column.


Ensure that the remote host type is WinRM, and that the Authentication method is set to Kerberos.


And be sure that we are passing our username in the ‘username@domain’ format, along with ‘Shared Session’ for the session mode.  Once you are done go ahead and click ‘Submit’.  If everything goes as planned your Veeam Backup and Replication server should be added as a PowerShell host within vRealize Orchestrator.

And now, the workflow!

Finally we can get to actually building our workflow.  If you remember our script we take in three parameters; VM, Desitination and AutoDelete – so we will mimic the same with our workflow, only calling them Input Parameters within vRO (shown below)


Now since we will be using the built-in Powershell workflow ‘Invoke an External Script’ we will also need to have some workflow attributes setup in order to pass to that workflow.  Below you can see how I’ve setup mine…


Your configuration may vary a little from this one, but as you can see we simply add a PowerShell host attribute and map it to our newly added host, as well assign the ScriptPath attribute to the representation of where we saved our little VeeamZip script earlier.  The arguments attribute can remain empty as we will only use this to build the arguments string to pass to the script.


The first element we want to add to our workflow schema is a Scriptable task – go ahead and drag that over into your workflow.  This is where we will create our arguments string.


As far as what goes into the scripting you can see I’ve simply brought in the arguments attribute, along with our three input parameters and simply chained them together into one string (arguments = ‘”‘+VM.name+'” “‘+Destination+'” “‘+AutoDelete+'”‘;), then ensured that my arguments attribute was included in the output as well.


Next drag the ‘Invoke an external script’ workflow into your schema (you can see I’ve renamed mine ‘Run VeeamZip’.  Ignore all of the prompts regarding the setup of parameters that pop up – the easiest way I like to do this is by editing the workflow (the pencil above it) and using the ‘Visual Binding’ tab as shown below.


Simply drag and drop your in attributes to their corresponding in attributes on the external script workflow, along with mapping your output to output.  Easy Peasy!

At this point you can go ahead and save and close your workflow – we are done with Orchestrator.  If you want to run the workflow a few times to test from within vRO go ahead – but the point of this post was to run it from within the Web Client so let’s move on to that step.

vRO and vSphere Web Client

I love vRealize Orchestrator and I love the fact that I can contextually execute custom workflows from within the vSphere Web Client.  To do this you need to first register your vRO instance with vCenter – this should be automatically done for you depending on you set everything up – I’m not going to get into that configuration today.  To get to our context mappings we need to click on Home->vRealize Orchestrator.  With the vRO Home in context select the ‘Manage’ tab and then ‘Context Actions’.  We then are going to want to hit the little green + sign to add a new workflow context map.


As far as the next steps they are pretty self explanatory – navigate through your vRO inventory to your workflow, click ‘Add’, and select ‘Virtual Machine’ from the types box.  This is what will allow us to right click on a VM and run our VeeamZip, passing the contextually selected VM to the workflow’s VM input parameter.  Click ‘OK’ and it’s time to VeeamZip!

Now when you want to run the workflow you can simply right click a VM and navigate to (in my case) All vRealize Orchestrator Actions->VeeamZipVM


As you can see our workflow will start, using our VM selected as the VM input, and simply prompt us for the destination and AutoDelete settings.


And there you have it!  We can now use the Free version of Veeam Backup and Replication to VeeamZip our VMs directly from within the vSphere Web Client.  In fact, our workflow will even show up within our vSphere tasks so we can monitor the status of the job.  Now, there is no error checking or anything like that…yet!  Let me know if you have any questions, concerns, etc… always happy to read the comments!

Friday Shorts – #vDM, New Web Client, Linux Cleanup, Betas and more…

Is it flowing? I like flowing, cascading hair. Thick lustrous hair is very important to me. Let me ask you this. If you stick your hand in the hair is it easy to get it out?

George Costanza – Seinfeld

Virtual Design Master 4 looking for sponsors

vdmlogoIf you have never checked out the Virtual Design Master challenge I suggest you stop reading this and head over to their site and peruse the last 3 season, then com back here of course…. Anyways, the online, reality based challenge is back for Season 4 and they are looking for sponsors to help provide prizes, swag, infrastructure, etc for the upcoming season!  So if you work for a vendor and want to get your brand attached to VDM4, follow this link to indicate your interest!  They are looking to get everything firmed up to have a July/August competition.

New HTML5 vSphere Web Client!

VMware LogoWhy VMware feels the need to change how the lightening fast, crazy responsive, highly reliable vSphere Web Client that is currently out there is beyond me, but they are…  I hope you can detect the sarcasm in that last sentence.  Anyways, they have been hard at work (re)developing the vSphere Web Client, removing it’s reliance on flash and flex and providing the same functionality through code based on HTML5.  I’ve not yet had a chance to check this out, but from the reactions on the blogosphere and Twitter I’d say that they are on the right track!  They are releasing the vSphere Web Client 6.5 as a Fling, allowing the product to get out into everyone’s hands before it’s integrated into a vSphere version.  If you have a chance go and check it out – it’s simply a virtual appliance that integrates with your current environment.

Getting Linux ready for a vSphere Template!

tuxcloudFellow VFD4 delegate Larry Smith recently posted in regards to cleaning up your Ubuntu templates!  It’s a great post that covers off a lot of things than you can do to ensure you have a clean, prepped instance of Ubuntu to use a template within your vSphere environment.  That said, he takes it one step further, scripting out the complete cleanup in bash – and in Ansible.  If you deal with Linux/Ubuntu templates I would definitly recommend heading over to Larry’s blog and applying some of this scripty goodness.

vSphere.next – Beta Time!

VMware has announced that the next version of vSphere will enter a (limited) public beta. If you feel like you have the time and are ready to provide the effort in providing feedback, submitting bugs, etc to VMware in regards to the next release of vSphere then you can head here and indicate your interest in being a part of the beta.  As far as I know not everyone will be accepted – careful consideration will be taken on who is chosen to participate as they want to ensure they are getting valuable feedback and discovering any gotchya’s in the product before releasing it to the masses!

ZertoCon – The Premier Business Continuity Conference

ZertoCON_Ads_125x125Zerto has been a long time sponsor of this blog so I thought I’d place a shoutout to them and what they have in the works this spring!  You can join Zerto and many others from May 23-25 in beautiful Boston for ZertoCon.  Lately we have seen a lot of these smaller vendors opting to have their own conferences – and honestly if you use their products they are a must for you to go!  The VM/EMC Worlds are a great venue, but honestly, these smaller, laser focused conferences are absolutely fabulous if you are looking to gain more knowledge around certain vendors and their ecosystems!  I encourage you to check it out and sign up if you have the chance to go!

To The Point – Removing stranded vCenter Orchestrator servers from vCenter

Ever have an issue that no matter what you do you can’t seem to get rid of an old vCenter Orchestrator server that’s registered with vCenter?  No?  Well, you might want to just stop reading then!  Either way, I have and no matter how many times I un-configured the vCenter plug-in, removed the vCenter plug-in, reloaded the vCenter plug-in the entry would just not seem to go away.  After a slew of curse words and a half dozen restarts of vCO and SSO I finally prevailed – and this is how I did so.

Take the “mob” approach and “dispose” of the vCO server.

Don’t worry, there’s no illegal activity here – I’m not talking about taking Soprano action but what we will do is get a little Al Capone on the vSphere MOB (Managed Object Browser).  The MOB is basically a graphical representation or hierarchy of our vSphere objects which allows us to view properties and  invoke and perform different methods on different objects to achieve the respective results.  That’s about the best way I can explain it – anyways, let’s cut to the point and get rid of that registered vCO server.

Access the mob by opening up your favorite browser and navigating to https://IP_OF_VCENTER/mob/

Once authenticated let’s click our way to our vCenter extensions by hitting ‘content’, then ‘Extension Manager’

mob-content mob-extensionmanager

Here we can see all of the extensions that are currently registered with our vCenter Server, including our vCenter Orchestrator extension.


Before we can go ahead and unregister this extension we need to obtain the extension key or unique identifier.  To do so, you guessed it, click on it

mob-vcoextension key

If you have more than one vCO extension and can’t figure out which one is which try drilling further down into the object by clicking ‘server’ in order to get the URL associated with the object.  That should help you figure out which object key you need.

Copy that object key and head back to the ‘Extension List’ screen.  Here, we need to invoke a method located in the bottom section called ‘Unregister Extension’.    Simply paste in your extension key you obtained above and click ‘Invoke Method’.


mob-unregistermethodBooyah!  All should be well in the world again!  Hope someone finds this short, but to the point post helpful!  As always, comments, concerns and threats are all welcome through the outlets provided in the comments section.  Happy Friday and #GOHABSGO.


My First vCenter Orchestrator Workflow – Part 5 – A little bit of SQL

orchestratepart5Thus far in this series of posts we have installed and configured vCenter Orchestrator as well as setup and utilized a couple of plugins; the vCenter plug-in and the PowerShell plug-in.  Before the series ends I wanted to go through one more plug-in.  The SQL plug-in.  The SQL plug-in is used for, well, you guessed it; running SQL queries against a database.  If you remember in Part 4 we setup a workflow that took two input parameters; a host and a location code.  The script then went on to create a new port group on a vSwitch named locationcode-VM_Network.  The logic in itself works fine and the workflow validates, the only problem I see with it is that the user needs to enter the ‘location code’ manually as an input.  Now I know you are all very careful and take your time when doing things, but I’m not, and more than likely after doing this 40 or 50 times you can count on me keying in that location code wrong 🙂 – Enter the SQL plugin.

So the setup is as follows; I have a database containing a table with the following columns; locationcode and deployed (boolean).  What I would like to do is have an input parameter that would allow me to select the location code from a list of non-deployed locations in a drop-down box (rather than manually enter this information in), and in turn pass the location code to my PowerShell script.  Once the script has ran I’d like to update the deployed column for that specific location, ensuring it isn’t displayed in the list again in turn ensuring I can’t deploy the same location twice.  Make sense?  I know it’s a lot to follow but the concepts of setting it up are pretty much the same no matter what you are looking to do.

Alright – enough background – Let’s get into it.  I’m not going to go through the installation of the SQL Plug-in – it’s exactly the same installation process as the Powershell plug-in which we covered in Part 4.  Similar to how we setup our Powershell host we need to setup our SQL server database connection inside of vCO.  To do this fire up your vCO client and navigate through the workflow tree to Library->SQL->Configuration and select the ‘Add a database’ workflow, right click and Start Workflow.  There are a few parameters as you can see that we need to pass to the workflow in order for it to successfully run.  First, give this connection a name and select your desired Database Type – in my case MS SQL.  Also here we need to pass a Connection URL.  Now if you don’t know anything about jdbc connection urls no fear, it’s not that difficult.  Simply enter it in the the following format…


So, for a SQL Server with named DC.lab.local running on the default port 1433 and  database named ServerDeploy you would use the following…



After clicking Next we are once again presented with our Shared/Per User session mode – again, I chose shared to use one simple set of credentials rather than a per user authentication.  When you are ready click ‘Submit’ to add your new database to vCO’s inventory.  One thing to note here is that this step is not necessary   If we wanted we could perform all of this at run time inside code, however for tutorial purposes and learning purposes it’s sometimes easier to do it this way.

Alright, nuff config!  It’s time now to get started on our task at hand; Querying the database for non-deployed servers and pushing the result as a drop-down box as an input parameter to our workflow that we created in Part 4.  First off there is a simple change we need to make to our existing workflow.  Here’s a tip – don’t feel like buffalo-ing your original workflow, simply right click on it and  select ‘Duplicate Workflow’ to copy it.  OK, first off we need a new attribute.  We originally have locationcode setup an input parameter of type string – and we still need this, however the result we get back from our database will be an array of strings.  So, on the General tab of your workflow create a new attribute called  databaseParameter of type SQL:Database and assign it the value of the Database we created earlier (this should allow you to browse the inventory to do so).  Once you are done that simply Save & Close and continue on with any validation errors.


So here comes the real magic!   We need to take that database attribute and pass it to a newly created action which will in turn spit out an array of string attributes (our locations in our database).   Again, you could do the following all in script embedded within your workflow, but you never know when you are going to need to reuse something so I’ve decided to create a new action to do so.    To create an new action be sure you are on ‘Design’ view from within your client and click on the actions tab in the left hand side menu.  Where you place your action doesn’t really matter, I chose to right click com.vmware.library.sql and create my action inside that module.  Just remember where you put it and what you named it:).


OK, you should now be in the Action editor.  This is where we are going to place the code that does all the querying of the database.  As I said earlier we need to pass this Action a database parameter and it will return an array of string.   The setup of input parameters and return types, along with all the other work we are going to do is all done on the scripting tab.  First off define your return type of an Array/string.  Secondly add an input parameter of type SQL:Database.  You can see all of this outlined in the capture below…


Hey!  That was easy!  Now it’s time for a little scripting.  vCO script is nothing but Javascript which calls the rich set of API’s that vSphere provides, along with the functions and properties of all the plug-ins provided in vCO.  The script I used is displayed below…

var resultingArray = new Array();
var query = "SELECT locationcode FROM Locations WHERE deployed = 0";
var resultingActiveRecords = databaseParameter.readCustomQuery(query);
for each (var resultRecord in resultingActiveRecords) {
var locationcode = resultRecord.getProperty("locationcode");
return resultingArray;

Simply paste this into the script pane of your action.  As you can see it’s a pretty simple script.  Creates and array, queries our database, pushes the locationcode column value of each record returned into that array and finally returns the array.  So – time to Save and Close and head back to our workflow.

So at this point we are left with 2 tasks.  The first being the creation of the drop-down box as an input.  To do this we will need to change the way our original input parameter, locationcode, is displayed.  This is done on the Presentation tab of our script editor.  Be sure you have selected locationcode in the Presentation tree that the top of the screen and select the icon to add a new property to it.  There are many several different properties listed but the one we are after is called Predefined list of elements.  Under the value field of our new property select the icon to assign an action.  In the popup find/filter for our action we created earlier, assign the actions parameter to our database parameter and click Apply.


There done right…well, kinda, you could run the workflow now and it would populate our input and it would go ahead and run the PowerCLI script and the VM Network would be created, however if you remember it was my intent to go back at the end of the workflow and update our database to ensure that the same locationcode could not be selected twice.  To do this we will need to drag a new Scriptable task element to run after we invoke our PowerCLI script.  Inside this scriptable task we will need to import a couple of local attributes in order to accomplish the sql we need to do, the locationcode, and the databaseParameter.


As for the script it’s going to look very similar to the syntax that we placed inside of our action with the exception of and executeCustomQuery function in place of the readCustomQuery and the actual query itself is different.  The following is what I used…

var query = "UPDATE locations SET deployed= 1 WHERE locationcode= '" + locationcode+ "'";

And now at last we are done!!  Go ahead and run your workflow, either from within the vCO client or the Web Client and you should now see a drop-down selection for the locationcode.  Once it’s selected once the script will run, create the VM Network, then update our database to ensure that the selected locationcode is not shown again in the drop-down.


So that my friends is the end of the line for me on creating my first vCenter Orchestrator Workflow but it is most definitely not the end of the line with vCO.  With access to a huge set of vSphere API’s along with all of the functionality and properties provided by its’ plugins, throw in some sweet integration with the vSphere Web Client I’m beginning to see my usage of vCO ramp up within my current role.  This series has hardly even grazed the surface in terms of vCO’s functionality so I urge you all to go out there and learn as much as you can about this product.  I’ll do one more post in the series and outline some of the resources that I’ve found along the creation of this workflow so expect to see that soon.

My first vCenter Orchestrator Workflow

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