Tag Archives: vRealize Automation (vCAC)

Automating vRA IaaS Blueprint creation with vRO

In some situations it might be very convenient to be able to automatically create vRA (vCAC) Iaas blueprints. However, since the IaaS part of vRA uses an OData API doing so is not a trivial task. OData is basically just a representation of the IaaS database. So there is no logic in front of it and thus no way to tell the API: “Create a blueprint for this VM please”. Previsously I talked a bit about the vCAC API. In this post I’ll get more practical and explain the steps involved when automating vRA IaaS blurptint creation with vRO.


All objects in the IaaS OData API are called entities. It doesn’t matter if it is a blueprint, a host or a build profile, everything is an entity. So in order to create a new blueprint we have to create a new entity. Which is done with the following line of code:

the createModelEntiy method  needs a couple of input parameters. The first one is easy, it’s the id of the vCACServer. This is the IaaS server object in vRO not the vCACCAFE host. You can just configure this server as an input of the workflow.

The second parameter is always “ManagementModelEntities.svc” and the third one is basically the table name of where the entity should end up. In the case of a blueprint entity it’s always “VirtualMachineTemplates” because that’s the table where the blueprints live.

Now for the tricky part: the parameter and links values.


The parameters for the entity are basically the properties of the object. The trick is figuring out which properties to use. There are a couple of methods. You could create a simple workflow that just dumps all the properties of an existing blueprint entity in a log. I prefer using LINQpad because it also shows you the relations between different tables.

So which properties do we need for the blueprint entity and how do we put them into the parameters variable? The script below shows how to do this.

Obviously you might want to change the TenantID or get it from a variable.


An entity object is basically an entry in a database table. This table links to other tables. So when creating a new entity you need to define to which elemetns in other tables this entity links to.

For blueprint entities there are 5 links to be set:

  • InterfaceType (vSphere in this case)
  • HostReservationPolicy (The reservation policy to deploy to)
  • ProvisioningGroup (A.ka Businiss Group)
  • WorkflowInfo (This is the kind of deployment you want. So for a BP that clones a template you need the Clone Workflow WorkflowInfo entity… still with me?)
  • GlobalProfiles (A.k.a Build Profiles)

This is how you put those links into a links object:

As you can see each attribute in the object is an array. The content of the array are vCAC Entities.  Most arrays have one value only the globalProfiles has multiple values if you have more then one build profile selected. In the code above I the buildProfiles variable is defined somewhere else and it is already an array so I left out the [ ].

Finding links entities

I guess you’re now wondering how to get the entities object for the links. You need to use the vCACEntitieManager to find these entities. Here is an example of how to find the WorkflowInfo entity for the clone workflow:

You can find the reservation policy by name in a very similar way:

If you have an array with build profile names as in input you can find all the corresponding entities with this piece of code:

If you want more of this in a workflow that’s ready to run, see the link at the end of this post.


So now we are able to create an entitie with the right parameters and links. After that’s successfully done there is one more thing we need to do: configuring the custom properties on the blueprint.

There are a couple required properties which start with a double underscore. Here is the list I used:

__buildprofile_order (order in which the buildprofiles are applied)
__clonefromid (id of the virtualmachineTemplate entity we created)
__clonefrom (name of the vmtemplate entity we created)
__clonespec (name of the customization spec in vCenter)
__displayLocationToUser (false)
__menusecurity_snapshotmanagement (false)
VirtualMachine.DiskN.IsClone (true for each disk)
VirtualMachine.DiskN.Size (the size of each disk)

You can set these properties with the “Update Property to Blueprint” workflow that comes with the vCAC plugin.

I used this script to generate the buildprofile order:

 Just give me the workflow

Too much information? I uploaded the example workflows to flowgrab. Find the download here.

A word of warning: The workflows might assume you’re using the vsphere.local tenant in vCAC. Should be easily fixable. If I’ve got some timeleft in the near future I might fix that myself. If you’re using another tenant you should be able to easily makes this work for you anyways.

Automating vRA (vCAC) using vRO – Split Brain

Recently I have done some work on automating vRA (vCAC) using vRO (vCO). This meant I had to dive into the vCAC APIs. The bad news is that this felt like diving into a pool of dark muddy water. The good news is that I’m still alive, my headache is gone and I’ll try to capture some of the things I learned on this blog.

Split brain

In this post I’ll start out with an introduction to the vCAC APIs. Yes, plural. Not just one API.

vCAC ahem… VRA is actually not just one product, it’s two products which are loosely coupled and sold as one. The first product is the vRA Appliance also known as CAFE. This is a new product that was introduced with vCAC verion 6.0. It is developed in Java (springsource), runs on linux, uses postgres as a data persistence layer, seems to use a micro services architecture , supports multi-tenancy and provides a REST API.

But there also is the old product that was originally developed at CreditSuise, spun off as DynamicOps and then acquired by VMware. It was sold as vCAC 5.x, is developed in .net, uses an MS SQL back-end, runs .net workflows, has no notion of multi-tenancy and provides an OData API. This part is usually called the Iaas Part.

The two products are also reflected in two separate vCO ahem… vRO Plugins. Although you download and install just one package there are really two plugins installed. One is called VCAC and has the description “vCloud Automation Center Infrastructure Administration plug-in for vCenter Orchestrator” the other one is called CAFE and is described as “vCloud Automation Center plug-in for vCenter Orchestrator”.

Confusing. Right? So let’s clear things up:

CAFE is the virtual appliance. All new features are developed in CAFE. So anything that was added since 6.0 runs on the appliance and can be used from the REST API. On top of that some functionality was moved to the appliance. Functionality running in CAFE in version 6.1 includes:

  • Business Groups and Tenants
  • Advanced Service Designer
  • The Catalog
  • Resource Actions
  • Approval policies
  • Notifications

So if you want to automate anything regarding any of these features you’ll need the CAFE plugin which talks to the REST API running on the virtual appliance.

IaaS is the name of everything that’s not on the appliance. It is the reason you need a windows server to run vRA, not just the appliance. This windows server (or multiple servers) runs the old DynamicOps Software with some modifications. Features provided by this part of vRA include:

  • Virtual Machine Blueprints
  • Machine Prefixes
  • Provisioning Groups (Maps to Business Groups in CAFE, GUI only knows Business Groups in the current version)
  • Reservations
  • VirtualMachines (vCAC VM objects which map to vSphere/vCloud VMs or even physical machines)

If you want to automate any of the above you’ll need to use the vCAC plugin or the Odata API. If you’re note familiar with Odata APIs there is something you should know: It’s not an actual API. It’s just a representation of the database. There is no application logic behind it, just database constraints. This means that creating new things (called entities) is rather difficult. You have to figure out all the links between different database tables yourself. I’ll try to dive into this deeper in another blog post.

There another peculiarity I want to point out: there is no multi-tenency in the IaaS part. This means that a lot of items from the IaaS part (for example: machine prefixes) are shown to all tenants!


The fact that vRA basically has a split brain provides some challenges when automation things in vRA. For Example: You’ll have to create a blueprint in the IaaS part but when you want to publish it you have to create a catalog item in the CAFE part of the product. Which brings me to the last part of this post.

As I said before the two product are loosely coupled. The actual touchpoints are not documented. Or at least I couldn’t find anything. But after spending a lot of hour trying to find out how to autmate the publishing of blueprint I found these touchpoints between both APIs:

  • The Business Group ID in CAFE is identical to the Provisioning Group ID in IaaS. If you create a Business Group in the REST API then vRA also creates the ProvisioningGroup in IaaS for you.
  • The catalog actually consists of three catalogs. More on this later. One of the catalogs is the provider catalog. Each provider manages its own provider catalog. IaaS is on of the providers. Somehow CAFE knows where to find certain provides IDs. Not sure where to find or set that mapping.
  • Every Catalog Item has a providerBinding attribute. This contains the bindingId. This binding ID is the blueprint ID (virtualMachineTemplateID) from the IaaS Part. This is how vRA figures out which blueprint to deploy when you request a catalog Item.
  • A Resource Operation has bindingId which maps the CAFE action to the IaaS action (like powerOn a VM for example)

Running vRA 6.2 without Windows

After the release of vRA 6.2 I wanted to setup a small lab on my laptop. I really didn’t feel like creating a windows machine and getting SQL and AD up and running. So I tried running vRA 6.2 without windows.

If you leave windows out of the vRA installation you’ll still end up with a useable vRA environment. I’ll go into what’s working and what’s not in a minute. Let me explain how I build the environment first.

Building the Windows less vRA environment

Below is a brief description of the deployment of the vRA components I used. I left DNS out of this because I just used local hosts files. That works fine for a lab. Obviously I don’t recommend any of this in a production scenario.

The first thing you’ll need is an authentication source. In every installation I have seen this is Microsoft Active Directory. But vRA also supports open ldap so that’s the obvious way around AD. I used the turnkey openldap appliance. After download, just open it in VMware workstation, start it and answer the few questions the setup asks you. Then open a browser and go to the IP address for the ldap vm. After logging in your screen should look something like this:


To create a new user account navigate to the users ou and click “Create new entry here”, then select “Generic: User account” and fill out the form. If you’re really lazy you can just use the existing admin user as a user in vRA. I also tried using the LDAP groups in vRA but somehow that doesn’t work for me so I’m just using a single user account from the LDAP.

After the ldap is setup you need to deploy the vRA identity appliance. After it’s deployed just start it, answer the questions and then go to the configuration page. configure the identity appliance as you would normally do, just don’t configure any AD stuff.  Once the identity appliance is up and running you deploy and configure the vRA (vCAC) appliance. No special configuration here.

When everything is installed and configured you should be able to connect to you vRA instance through the url: https://<vra appliance ip>/vcac. Login using the administrator@vsphere.local account. On the tenant tab click “Add Tenant”.


give the tenant a name and url and click “Submit and next”.


Now click “Add Identity store”


Connect to your ldap as shown above. The IP address is the IP address of the open LDAP appliance we deployed earlier.

After the Identity store is configured the next step is to add a Tenant admin.


As you can see in the screenshot you’ll be unable to add any infrastructure administrators. This is because all IaaS functionality in vRA is delivered through the IaaS windows components which we did not install.

Now logout and go to the tenant url for the tenant you just created: https://<vra host>/vcac/org/<tenant url>. You should be able to login with the tenant administrator account you configured in the previous step.


What doesn’t work?

  • As I wrote above, LDAP groups don’t seem to work. I don’t know if this is a vRA issue or an issue with the turnkey openLDAP appliance. I’ll need to investigate this further.
  • Any IaaS feature. This includes:
    • Machine Blueprints
    • Machine Reclemation
    • Business Groups (although they are in the CAFE API but definitely not in the GUI)
    • Fabric Groups
    • Reservations / Reservation Policies
    • Actually the whole “Infrastructure” tab is not available.


What works?

  • All ASD features
  • The catalog
  • Approval policies
  • Tenants
  • Branding



Setting up vRA without any windows components is really easy. Mostly because you can skip all the IIS, vCAC manager, DEM and other stuff that comes with it. It also doesn’t require a lot of resources. For me it runs fine a my laptop (i7, 16GB RAM, SSD). You are only able to use the ASD part of vRA but that is actually pretty powerfull. You’ll just have to do without the IaaS stuff. That doesn’t mean you can’t deploy any virtual machines, you can actually deploy them using an ASD workflow.

By the way: I have a feeling the performance of vRA is a lot better without the IaaS parts. But I have no numbers to support this.

VMworld and the future of Orchestrator

Last week I attended VMworld Europe in Barcelona. I had a great time, eating tapas, drinking Rioja and learning something new in between. I already wrote about elasticity achieved using project fargo and docker on my company blog. Since this blog is more automation focussed I wanted to highlight some automation news. OR actually it is more about the future of Orchestrator.

The first thing that stood out to me was the lack of vCenter Orchestrator uuhh vRealize Orchestrator break-out sessions. I think there were two or three session explicitly about Orchestrator. A couple others went a little bit into orchestrator but were focused on vRealize Automation (vCAC). Last year there were quite a couple of sessions about Orchestrator. Telling us it was the best kept secret or the best VMware product never released and we should really go and use this awesome tool. And of course they were right to say so. And seeing where VMware is going with Orchestrator I was really surprised they didn’t give it more attention during Vmworld.

Which brings me to my second point. It is clear by now that Orchestrator will be used as the back-end for vRealize Automation. We can already see this in the current versions: The integration with NSX is completely implemented using Orchestrator. vCAC ugh… vRA has no interaction with NSX whatsoever, everything is handled via Orchestrator.

The same goes for what VMware calls Anything as a Service. Which is delivered using the Advanced Services Designer. Yeah that’s a lot of buzzwords in one sentence. In reality it is just a forms designer which you can use to design user front-ends for Orchestrator workflows. The objects created by the workflow can then be managed by vRealize Automation.

I already see that the adoption of Orchestrator is mainly driven by the use of vCAC. But there is more to come. VMware told in one of the Orchestrator sessions that Orchestrator will be used as a DEM replacement for vRealize Automation (but any information given in such presentation may change at any time). For who isn’t familiar with vCAC/vRA; The DEM is the Distributed Execution Manager. It is basically the component which does the actual work in a vCAC deployment. Currently it is 100% .net code and runs MS .NET workflow foundation workflows. So it makes total sense to replace that workflow engine with VMwares own workflow engine. The result will be that some day we can get rid of the windows components in vCAC and end up with just a virtual appliance which is easy to deploy and configure. That day will be a good day.

To be able to use orchestrator on the scale that vRA requires there will be some changes to the product in the future. For example, better permission management, multi geographical deployment models, integration with DevOps solutions and a lot more.

So although Orchestrator didn’t get a lot of attention during VMworld it seems it is going to play a crucial role in VMware’s automation strategy. Nice 🙂

Prerequisites check vCAC 6.1 (automated)

As many of you already know VMware released vCloud Automation Center 6.1 September 9th. I’m working on an implementation already, so I feel pretty lucky. An installation always starts with the deployment of the necessary Windows (2012R2) servers and all the prerequisites listed in the documentation.

We at automate-it.today are big supporters in automating everything, as long as it useful or fun to build. So I was really excited about the pre-req automation script build by Brain Graf. It’s easy, it’s fast and will give you a good verification of all the necessary prerequisites.

You can find the script here.


vCO LockingSystem

Whenever you are using external resources in vCO you might run into a race condition. This can happen when a workflow using an external resource is running multiple times simultaneously. To avoid data consistency problems you can use the vCO LockingSystem.

Why lock?

Imagine you have a vCO workflow which reads a counter from a web API, then changes the data, lets say add 1 to the counter, and writes it back to the API. What happens if you start the workflow multiple times simultaneously? You could run into a situation where one workflow reads the data and modifies it but has not yet written it to the API, then the second workflow reads the not yet updated data and modifies it. Then the javascript engine decides to execute the API call in the first workflow and then the API call in the second workflow. Now both workflows are using the same counter value while they were supposed to get a unique value from the API.

A real life example for this is retrieving a hostname sequence number from a vCAC hostname prefix. This process involves reading the current number from the vCAC API, increasing the number and then sending the new number back to the API. Btw: why the api itself does not handle the increase of the number remains a mystery to me.

To prevent above scenario from happening you want to lock the resource before reading and updating it so any other action using the resource has to wait until you are done.

Using the LockingSystem

Locking in vCO is done using the LockingSystem scripting object. To acquire a lock you use:

This method tries to acquire the lock once and then returns a boolean which tells you if the lock was acquired or not. If you want the workflow to wait until the lock is acquired you can use

The parameters lockid and owner are strings. The lockid identifies the object you are trying to lock. So just use a name that makes sense. The owner can be anything, I usually use the name of the workflow which is acquiring the lock. Below is an example of a scriptable task which acquires a lock. Note that this script will wait until the lock is acquired.

LockingSystem.lockAndWait example

After the lock is acquired you can get, modify and write data to the external resource. After that you release the lock and start using the data. Below is a screenshot of a workflow that uses locking.

Locking example workflow

Remember to release the lock in case something goes wrong. If you don’t handle exceptions for the tasks between acquiring the lock and releasing it, you can end-up with a lock that never get’s released. If you do end up in that situation you can run a workflow which contains a single script with this line:


How to Automate: vCAC

This is the third blog in my “How to automate” series. In the first posts I dicussed PowerCLI and vCO. In this blog I will talk about vCAC.


vCAC = VMware vCloud Automation Center. It was originally developed by Credit Suisse, then spun off into a company called Dynamic Ops before it was acquired by VMware. It is software that takes care of the buniness side of automation. It presents a portal on which users or admins can request machines and services. The logic inside vCAC determines who can request which services and where machines are deployed. After a VM or service is requested it  manages the lifecycle of the object. I use the word “object” on purpose here because it can be a virtual machine as well as a physical server. And since version 6 it can even be any kind of service instead of an actual server.

The Upsides

The big upside of vCAC is that it is a very versatile tool. Especially if you have the cloud developer license you can make the software do virtually anything. And even without it you are able to do a whole bunch of stuff. This includes deploying machines to both your internal cloud as well as public clouds like Amazon or vCloud powered clouds. You could also provision storage or networks if you need to. So the software was not only developed in Switserland, it’s also versatile like a Swiss army knife.

Another big plus in my opinion is that it integrates with vCenter ORchestrator so well. This is one of the reasons vCAC can do almost anything even without the developer license. If you can do it with vCO, you can integrate it with vCAC.

vCAC delivers an end user portal which doesn’t require you to do any web development. This makes building a portal very easy and leaves more time for you to focus on the automation that happens behind the portal.

vCAC also makes it possible to import existing virtual machines. This is something that is very hard with vCloud Director. This makes vCAC a much better fit than vCD for companies running their own private datacenter (or should I say “cloud”?). For public cloud providers vCD is still the way to go in my opinion although using vCAC is not impossible.

The Downsides

The fact that vCAC is so versatile is also a downside. vCAC needs a lot of configuration before it does what you want it to do. And that’s before you start digging in to custom workflows. There are 10 workflows which you can customize out of the box. If you want more you need the developer license. On top of that you need .NET knowledge to actually develop custom workflows.
And in depth .NET knowledge is not something you find in a regular vCloud admin.

But there is a way around this. That way is called vCO. You can call vCO workflows from the default vCAC workflows. This will solve most of your integration problems and I really like this approach.

Speaking about vCO integration, that is actually my next downside. Don’t get me wrong, I really like the vCO integration. It just leaves me wondering why I need a bunch of virtual machines, two database servers, an additional SSO and a lot of complexity to have a portal which basically calls vCO workflows and does some life cylce management. It just doesn’t feel right. Ok, vCAC can do a bit more then that. Deploying physical machines for example or creating datastores on NetApp storage. But most companies who will be using vCAC will probably not use these features. So they are stuck with an overcomplicated vCAC setup which has features that are already covered by vCO.

And that brings us to my last downside. The vCAC infra itself can get rather complex if you want to set it up in a redundant and scalable way. To VMware: Please simplfy this. I like the VA approach that was introduced with version 6 but I don’t like setting up 6 additional Windows machines and 5 loadbalancers.

The Right Tool for The Job?

When should you use vCAC? I my opinion you should use it when you regularly deploy new virtual machines or other services and you want to automate that process. Using vCAC forces you to automate every single step in the deployment process. This includes creating change requests, registering IP addresses, creating the VM, assigning a network and so on. This makes it possible for application administrators and developers to request machines without any intervention of a cloud administrator. And it doesn’t stop there. You can also automate the decommissioning process, limit the amount of resources someone can consume or allow them to deploy machines on Amazon instead of your internal cloud.

But remember: vCAC always brings a friend to the party: vCenter Orchestrator. But in my opinion that only makes the party better.

Invite: ITQ Technical Update Session

ITQ Technical Update Session
Woensdag 25 juni 2014
Sorry to all non dutch speaking readers. The following invitation is in dutch because all sessions at this event will be in Dutch. Dennis and I will be presenting two sessions: “Shoebox sized datacenter” and “Datacenter Robotics.

De virtualisatie specialisten van ITQ volgen de ontwikkelingen en trends in de markt nauwgezet door onder andere het bijwonen van evenementen zoals; VMworld, VMware Partner Exchange, VMUG, Storage Field Days, DevOpsDays etc.
Een belangrijke trend is het “Software Defined DataCenter”. Maar wat is nu eigenlijk het Software Defined DataCenter, wat zijn de voordelen en mogelijkheden en kan dit in mijn huidige Datacenter?
Tijdens deze avond gaan we in op de verschillende factoren van het Software Defined DataCenter, zoomen we in op Software Defined Performance, Software Defined Storage en de automatiseringsmogelijkheden welke Software Defined ons biedt.
De verbindende factor tussen onze consultants is de passie voor technologie, deze passie willen we graag met je delen op deze avond.
Sessie 1:
Software Defined Performance met PernixData FVP
Ontdek hoeveel performance met de huidige technologie haalbaar is in een datacenter ter grootte van een schoenendoos! Dit laten we zien door middel van een presentatie ondersteund met infographic achtige visualisaties met aansluitend een live demo op het door ITQ zelf gebouwde mobiele datacenter.
De presentatie zal ingaan op wat de verschuiving van traditionele disks naar flash inhoud voor onze datacenters en hoe opslag capaciteit los gezien kan worden van performance. Hierbij worden de mogelijkheden van PernixData FVP besproken en wordt inzicht gegeven in nieuw aangekondigde features.
Sessie 2:
Software Defined Storage
De ITQ vUnit heeft in drie teams een serie testen uitgevoerd waarbij objectief gekeken is naar o.a. performance, features, stabiliteit, robuustheid, ease of use, et cetera. Na een korte toelichting op deze disruptieve marktontwikkeling en de producten die we getest hebben, zal ITQ de testresultaten tijdens een interactieve paneldiscussie geheel uit de doeken doen!
De producten welke getest zijn:
·         Maxta Storage Platform,
·         EMC ScaleIO
·         VMware Virtual SAN
Sessie 3:
VMware vCloud Automation Center / vCenter Orchestrator
Deze sessie maakt duidelijk waarom een datacenter een robot nodig heeft om het Software Defined Datacenter te besturen en waar je die robot kunt vinden. We zullen laten zien dat met software die iedere vSphere gebruiker tot zijn beschikking heeft, nagenoeg alles is te automatiseren. Daarnaast zal worden ingegaan hoe deze robot verschillende processen kan automatiseren door het inzetten van vCloud Automation Center.
18.00 – 18.30:     Ontvangst met soep en broodjesbuffet
18.30 – 19.30:     Sessie 1: Software Defined Performance met PernixData FVP
19.30 – 20.00:     Sessie 2: Software Defined Storage (Panel)
20.00 – 20.15:     Pauze
20.15 – 21.00:     Sessie 3: VMware vCloud Automation Center / VMware vCenter Orchestrator
21.00 – ??.??:     Afsluiting + netwerkborrel
Locatie:       Hotel Vianen
                        Prins Bernhardstraat 75
                        4132 XE Vianen
Er is beperkte ruimte beschikbaar, dus zorg ervoor dat je je op tijd inschrijft voor dit evenement. Schrijf je hier in! Wij hopen je te mogen verwelkomen.

Automating SRM with PowerCLI

Update (11-sept-2014): VMware released a vCO plugin for SRM. So if you are looking to automate SRM with vCO don’t use the Powercli script below but use the plugin instead.

Recently I was working on automating the deployment of VMs on a twin datacenter vSphere design. The failover is handled by Site Recovery Manager and the deployment of the VMs is taken care of by vCAC. Luckily vCAC has SRM integration so no prolem there….. But apparently when VMware says “integration” they mean: “It’s ok if you failover VMs deployed by vCAC”. It doesn’t mean that all VMs deployed by vCAC are automatically protected by SRM. Since we are using vCAC the logic choice would be to automated this using a vCenter Orchestrator workflow that enables protection for the deployed VMs. However, there is no vCO plug-in for SRM and SRM does not have a REST or SOAP API. At least not one that is compatible with the vCO SOAP plugin. This, to me, is surprising because both SRM and vCO have been around for quite a while. Luckily the latest version of VMware PowerCLI comes with SRM cmdlets. Or rather: one cmdlet. Now, vCO can call Powershell scripts so the obvious solution is to create a powershell script that configures SRM protection for a virtual machine and then call that from vCO.

The first thing I tried was copy pasting the example from the documentation. Which didn’t work. It kept failing with the error:

The operation is not supported on the object”

The same error was reported here but no solution available. The error was caused by the line containing: “associateVms()“. It turns out I should have just read the developers guide because that states this method is only needed when you’re using SRM Replication. If you are using array based replication there is no need to associate the VM with a protection group. However, removing this line only resulted in a new error. This time the error appears in the vSphere client:

Not authenticated into SRM server <servername>

The account I was using has administrator permissions on both vCenter servers and both SRM machines so it’s not a permission issue. The solution is to pass credentials with Connect-srmserver command for both the local and the remote SRM server. Below is the script I created. It takes the vCenter server ,a username, the VM to protect and the protection group it is in as parameters.

Please notice the “$password =” line in the script above. This reads the encrypted password for the user account from a password file in c:\orchestrator\powershell. Passing the password as plain text was not an option. Typing it obviously is impossible if you want to run the script from a vCO workflow. To solve this I store the password encrypted in a file. The password file is created using the script below:

This script takes a username as an input. You want to use the UPN here (user@domain). The script doesn’t generate any output on the screen. Just start the script, type the password for the user and you’re done.

Now we want to kick this off from vCO. That’s where it gets a little tricky because the script will probably not run under the account you use to develop and test the script. The thing is, the password file that is generated by the script  above is encrypted with a key specific to the use running the script. In other words: we need to run the script under the same account that will be used to run the srm protect script (in my case the vCO service account). Here is how to do it from a windows cmd prompt:

Now you’re ready to protect VMs automatically. I’ll explain how to run it from a vCO workflow in another post.

For now I’ll leave you with an additional script which you’ll need to unprotect the VM. Could come in handy when you want to automate the deletion of VMs.

Selecting Network Through vCAC Property

vCAC is a really powerful automation tool, primarily giving users the opportunity to request their own applications without interaction of the IT Department. In this particular case I was configuring a blueprint to be used by developers.

Using vCAC to clone vCenter templates is really simple; users request a machine to use in the development or in the production environment. While I was testing the deployment of this blueprint the department responsible for Active Directory complained because my test machines, without the correct naming convention, appeared in the production AD.

The reservation used for this blueprint contained two networks, a development and a production network. Normally after deploying a vCenter template you edit the Virtual Machine hardware and select the correct network, before powering on the VM. In this case the requesting user does not have permission to connect to vCenter and to change this setting, and vCAC will just power on the VM. So we need another solution.

The solution is surprisingly not that difficult, you can use a custom property within vCAC. I will describe this in a few steps.

The first step is to find out which networks are available, this can be done by editing the reservation for this particular blueprint.


The next step is creating a new property definition within the property dictionary:


Name: VirtualMachine.Network0.Name
Display Name: Select Network
Control Type: DropDownList
Required: Yes

After you created the definition you can edit the property attributes


Type: ValueList
Name: Network
Value: Add all choices comma separated.

Now when the user will request a blueprint, there is a required choice with the name Network and the choices you added, in this case Development-1 and Production-1.