vCenter Orchestrator - You Own It, Use It!

At lunch this week with a customer when the subject of automation came up, as it seems to more and more frequently these days.  They were looking for a way to automate provisioning of servers so that they could reduce time to market.  What product would help them with that, they asked.

You already own it, was my answer.

If you're a VMware administrator you're probably aware of vCenter Orchestrator at least in passing.  If you're like me, you may have even played with it a little and moved on to other things because you couldn't really figure out how it all works.

On the other hand, you may have never even heard of vCenter Orchestrator and you don't know why you'd want to learn about it, much less use it.

What is it?

vCenter Orchestrator, or vCO, is a workflow engine that can help administrators automate tasks.  Simple, yet powerful statement, right?

In fact, vCO comes out of the box with lots of pre-built workflows for vSphere administration as well as plugins for things like Active Directory, SOAP, REST ... there's even a plugin by Cisco for UCS.  Naturually, VMware also provides plugins for other products like vCloud Director and Update Manager.  The community also provides a source of plugins such as Joerg Lew's PowerSSHell plugin.  VMware Labs also provides some unsupported/experimental plugins.


With vCO, a VMware administrator can create, using a drag and drop interface, a workflow to provision new servers including deploying a template, customizing and installing applications.

Did I say it was drag and drop?  That's the best part for salty old infrastructure folks like me - you know, the kind of guy who does his scripting through the Google search interface.  vCO doesn't require that you be a hacker, but it also doesn't limit you from creating some pretty complex workflows that include custom scripts.  The good news is, you can do a lot of powerful things, pretty easily, with the built in workflows.

What can it do?

Here's a list of examples from the vCO community --

• Mass Migrations
• Check for Snapshots
• Rescan HBAs
• Add an NFS datastore
• Set up a self-service VM provisioning portal
• Kick off a workflow based on a VM alarm trigger

How do I get it?

As the title of this post indicates, if you own vCenter Server you already have vCO.  Recently, VMware released a vCO virtual appliance so installation is super easy.

Burke has a good guide for installing vCO on a Windows server if you like to do things the hard way.


How do I get started with vCO?

There's actually a pretty good community out there already with example workflows, step-by-step guides and video demonstrations...


VMware vCenter Orchestrator Blog
VMware Orchestrator Community
vCO Portal
VCO Team
Mighty Virtualization
Cody Bunch - you can pre-order his book "Automating vSphere"

Setting the Citrix CLIENTNAME to match the View client host name

Often, applications will use the Citrix client name to assign location based resources (printers, for example).  In the case of a Citrix XenApp session running from a Windows based View session, location awareness is lost because Citrix client name assumes the Windows host name of the VM, not the endpoint (a thin client or View running on a physical desktop).

There are two ways that I have seen to address this - and personally I have a preference for one of those methods, but you can decide which works best for you.

First, it's important to understand a couple of things.

The View agent on the VM will capture information about the client and store that data in the hive "HKCU\Volatile Environment\" and one of the keys in that hive is "ViewClient_Machine_Name".

Citrix clients store the CLIENTNAME attribute in "HKLM\Software\Citrix\ICAClient\CLIENTNAME".

By default, the Citrix plugin installs with dynamic client name enabled.  This means that the CLIENTNAME reg is populated with the host name of the host running the client.  In other words, by default CLIENTNAME will be the VM's OS host name.

One method of changing the CLIENTNAME to the endpoint host name is to grab the reg key "ViewClient_Machine_Name" and replace the "CLIENTNAME" key with that string.  A script to do just that may look like this:

Option Explicit
Dim SysVarReg, Value
Set SysVarReg = WScript.CreateObject("WScript.Shell")
value = SysVarReg.RegRead("HKCU\Volatile Environment\ViewClient_Machine_Name")
SysVarReg.RegWrite "HKLM\Software\Citrix\ICAClient\CLIENTNAME", value

You would want this script to run on connection and reconnection, so when a roaming desktop user changes endpoints you are updating the CLIENTNAME to match for location awareness.

To use this method, you would need to reinstall the Citrix plugin on the VM to disable dynamic client name.

I like this approach because it's elegant and simple to troubleshoot.  I would recommend using BGinfo to add three bits of info to the VM desktop wallpaper to help validate that the CLIENTNAME is correct and to aid in any troubleshooting.  For example, I would have the following appear in the lower left corner in small font on the desktop:

  View VM -
  View Client -
  Citrix Client Name -

The other method would be to leave Citrix dynamic client name enabled and change the host name of the VM on connect/reconnect to match the endpoint host name (or include the endpoint host name in the VM host name).  I'm not a huge fan of this approach because it involves constantly changing the host name of the VM which could impact other applications as well as complicate troubleshooting.  You also need to make sure that the TCPIP name is changed as well, resulting in a DNS update if you're running dynamic DNS.

I do have access to a script to perform a VM host name change, but since I didn't write it I don't want to post it here.  I will check with the author to see if I can add it to this post later, but the script above should give you a start on creating that script.