Create vCO/vRO scheduled workflow automatically

With vCAC/vRA, when you “destroy” a machine it deletes the vm immediately. There is a setting you can disable that will not delete it but instead will power if off and send it to a default “destroyed” folder in vCenter. However, after that it just sits there until it’s manually deleted.

Due to a business need, I wrote a workflow that automatically deletes the vm after a given number of days. In my example, we delete vm’s 14 days after they’ve been shut off. You can edit the code to make it however many days you’d like though.

First, if you haven’t changed the destroy option yet, check out this blog on how to do that. Once done, go on to the next step.

Once you have disabled the immediate delete feature, you’ll want to do the following in your vCO/vRO console:

In your Decommisson workflow, drag and drop a scriptable task element on the page. You’ll probably want to make it one of the very last elements. Here are the properties:

and the script is:

workflowScheduleDate = new Date();
var day = workflowScheduleDate.getDay();
workflowScheduleDate.setDate(workflowScheduleDate.getDate()+ (day == 0 ? 14 : day == 1 ? 14 : day == 2 ? 14 : day == 3 ? 14 : day == 4 ? 14 : day == 5 ? 14 : day == 6 ? 14 : 0 ));

//This workflow ID is Delete virtual machine — copy and change to suit other workflows
var workflowToLaunch = Server.getWorkflowWithId(“BD80808080808080808080808080808003C180800122528313869552e41805bb1″);
if (workflowToLaunch == null) {
throw “Workflow not found”;

var workflowParameters = new Properties();
var scheduledTask = workflowToLaunch.schedule(workflowParameters,workflowScheduleDate);


The most important part is understanding how the days are calculated. If you see where it says “day ==0 ? 14″, this is javascript saying if day = Sunday, then schedule the deletion 14 days later. You could work the numbers to be business days only. You’d have to take into account the number of days and weekends etc. Our policy is 14 days from the time of shut down – business or not. Nevertheless, if your policy is 30 days, then just replace the 14 with 30.

Update1: If you want to give the user the ability to choose the number of days, all you have to do is create an input parameter type number called something like “numDays” and replace all of the “14’s” with the numDays variable. Then, when the workflow is run, you can put in any numeral and the workflow will be kicked off that number of days later.

Lastly, be sure to change the long character string that is the delete vm workflow. In essence, you could schedule any workflow with this script – you just have to change the workflow ID. To get the workflow ID, click and highlight the given workflow, then hit ctrl-c, then open notepad and ctrl-v. This will paste the workflow ID!

Now when you “destroy” a machine in vRA, it will be shut off, moved to the default folder, and deleted 14 (or however many) days later!

Update2: If for whatever reason you want to kill the deletion of vm, all you have to do is the following: Open vCO/vRO client -> From the main “Run” page and on the home tabe, click on “Tasks scheduled in the sytem.” Find the scheduled task created for your vm and delete it. That’s it!

Posted in Uncategorized | Leave a comment

vCAC 6.0.x and vCO to rename a virtual machine

This post is to demonstrate how to use vCO with vCAC extensibility to rename a VM during vCAC 6.0.x provisioning automatically including an incrementing unique identifier.

I’ve read many blogs and posts on how to do this. None of them show how to do it without vCAC Designer, powershell, or both. This “how to” utilizes ONLY vCAC and vCO (no designer or powershell needed). From what I have read, the focus moving forward will be on vCO with Designer being deprecated. So, if you don’t know vCO or don’t use it with vCAC I would learn it.

First, I’m using vCAC I’m not sure the minimum version needed but 6.0 would probably work. I’m also using the latest vCO 5.5.1 appliance. The prerequisites you need are the vCAC 6.0.1 plugin . This will give you all of the workflows that you need in vCO. As of this writing, the link to the plugin is:; title=”vCAC 6.01 vCO plugin”></

For this to all work, you must set up vCAC extensibility with vCO. There is a really good blog post on how to do this. The only difference is you will not update design center but instead the settings will be tied between vCAC and vCO directly. Just be sure your vCO endpoint is setup on your vCAC. I would recommend reading part 2 for a complete understanding of how this works.

Once you have this piece complete and your External stubs installed (WFStubBuildingMachine,MachineProvisioned, etc) you must then set it up so that when you kick off a VM build it runs whichever stubs you want it to. Typically, the standard is to run WFStubBuildingMachine for things like renaming and setting other custom properties i.e. IP ,storage, etc., then WFStubProvisioned for custom installs after the vm has been built. An example would be adding the machine to DNS (if linux) or joining it to the domain or installing components like IIS. Lastly, the WFStubMachineDisposing is used for the disposal of the machine. So, things like removing it from AD, unlocking the name if you use the System locking method etc.


To do this you will use the following workflow: “Assign a state change workflow to a blueprint and its virtual machines.” The way to do this is the following: when you run it, one of the steps it asks is to assign a workflow to be run during one of the states (building, provisioning, disposing). You will want to create three separate master workflows: one for each state (Building, Provisioning, Disposing). Depending on the master workflow, you will build around it based upon the functionality (see above as to why you would use each one).


Select the first option, which is BuildingMachine. Set your master “BuildingMachine” workflow as the workflow that it calls and select the various blueprints you want to kick the workflow off. From now on, anytime you build a machine from that blueprint, it will now call this master workflow that you selected. Do the same for Provisioning and Disposing. If you ever want to remove these workflows you can just run the “remove a state change workflow from a blueprint and its virtual machines” or manually delete them in your blueprint in vCAC itself:


In my example, I have set my master workflow as “Building Workflow”, “Decommission workflow”, and “Provisioning workflow.” To rename the VM to something dynamic, we will be using the Building Machine Workflow.


Here is what my workflow looks like:


To explain this a bit, we have the following needs for a VM name:

Domain makes up the first 3 characters; Location the next three; app code the next three; If it’s a web or database server we add an additional character; we set the classification (Production, QA, Test, etc); Generate a unique ID (01,02,03) then update the properties so vCAC uses the new name.

To keep this example simple, let’s just use two pieces. Let’s say we want a Domain and app code. To set this up, we will want to create a new property in vCAC. Select one of your blueprints, go to the properties tab, and create a new property called “Custom.Domain” with nothing in the value field. Create another called “Custom.AppName” with nothing in the value field.


The best way to set this up is to use a property dictionary. Here is a good blog post on how to do that. Just mimic this for what we’re doing.

Here are some screencaps of my property dictionary. You can probably just copy what I’ve done since the blog post goes into a bit more detail than we need for this. Be sure and name your property dictionary entries the same as what you called the properties you created in the blueprint (this is what links them together). Of course, you can always put static values in the “value” field of your property if you just want to test.


Click on edit under “Property attributes”. Select type “valuelist” and enter your values separated by a comma. This is what will be in the dropdown of your blueprint.

At this point, we can begin to manipulate the actual workflow. Drag and drop a scriptable task onto the form. This will be to grab the Domain name. Here are my inputs, outputs, and script:




Drag another scriptable task onto the pane after the first. This one is for the App Code.




(the second line says to capture from the first character until the first space. My app codes are setup in the following way “Code – Name”. So, you can remove this line assuming you just put in app codes as “SQL”, “ORA” etc.)

At this point our serverName variable is composed of domain + app code. If our domain was “TST” and our appcode “ABC”, the variable would be TSTABC.

Possibly the best part of this for some will be the creation of the unique ID i.e. a unique number at the end of the VM. After all, if you have 1000+ vm’s, it can be a major pain to come up with a unique name automatically. I will include the code here and explain it:


(On a side note, I am not a programmer and I did not write all of this code. I had a basis including the search functionality and had a programmer friend tweak it to make it more efficient)

Copy and paste this into a new scriptable task. The one input is serverName and the one output is finalName (string/attribute).

Here is what it does: It searches both vCenter via the vCenter plugin (pre-requisite for this to work) and the internal vCO locking system to see if the name already exists. If true, increment the number by 1. For example, if TXTABC01 exists, then it will make the name TXTABC02 etc. It also locks the new name in vCO from being used again (be sure to set an unlock workflow to run during your decommission stage or remove the locking line towards the end all together).

Drag and drop a third scriptable task onto the pane, and call it something like “Update Properties.” Here are my ins/outs/script:




Finally, drag and drop the workflow called “Updated a vCAC model entity.” Here are its properties:



That’s it: Once the workflow is finalized, your vm will have it’s new name. Be sure you have your customization spec set in your blueprint from vCenter or else sysprep won’t change the name (it will show up in vCenter correctly but the actual OS won’t reflect the change). You’ll set the option that says “Use the virtual machine name.”

Posted in vCAC | Tagged , , , , , | 5 Comments