Category Archives: PowerCLI

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 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.


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.

Workflows vs. Scripts (or: Scripts are scary)

I originally wrote this blog post a couple weeks ago and was planning on publishing it today. I started the post with this line: “Let me start by saying this: Scripts are awesome!”. But today I read Duncans post titled “Automation is scary!“. And I partly agree with Duncan, automation can be scary. But I think not all automation is scary so I’ll start this post with a slightly modified line…”

Let me start by saying this: Scripts are scary! They can do the tedious tasks for you, they can be scheduled so you never forget to delete a snapshot again, they can be used to offload your work to less skilled colleagues, they can save you time and frustration.However, Most scripts used are not written by the user. They are usually left by your predecessor, downloaded from blogs, copied from tutorials and what not. On top of that  if somebody tells you he “Hacked some scripts together” you are left with the feeling it’s a quick and dirty solution. So while scripts are awesome there appears to be something wrong with them which make them scary as well. So let’s dig a little deeper into what’s scary about scripts.

Have you ever taken over the responsibilities of another administrator who was really into “automating” his work? Just to discover that he has a million scripts somewhere on a file server which do all his work for him? How did that work out for you? Would you use all of those scripts?
Probably not. I know I wouldn’t. Because I don’t have a clue what each script exactly does, for which version of whatever software it was developed, if it was tested thoroughly, in which order they are supposed to run and so on and so forth. In all likelihood there will be no, or very little documentation. So when you have to deploy a new VM you have no clue if you need to run the “reserve IP” scripts first and then the “Deploy VM” script or the other way around. So the best course of action would be to not use the scripts and first figure out how the process is done manually.

But that’s a shame really. Because there was a lot of time spend on developing the scripts and they could saved you a lot of time as well. Over time you will probably develop new scripts for the same, or new, tasks. Which is just more time wasted.

Now let’s compare this with workflows in vCenter Orchestrator. Instead of a bunch of undocumented scripts you have a collection of workflows. Each one has a meaningful name, comes with a version history, displays what it is going to do and can hold a description or even nice “sticky notes” explaining what is going on. But more importantly, they execute a whole process instead of just one task.

And that’s the major difference between scripts and workflows: Workflows automate processes, scripts automate tasks. Actually, workflows just consist of a number of scripts because that’s what workflows do: executing all tasks in a certain process.

The good news is: if you happen to have a ton of powershell scripts laying around, you can use these in a vCO workflow just fine. One fair warning for the PowerCLI enthusiasts out there though: Once you start learning vCO you’ll probably use less and less powershell…..

How to Automate: PowerCLI

After writing my blog posts about the why and the what of automation I decided to write a bit about how to automate. This series of posts won’t go into much technical detail but rather offer some pointers to help you choose the right tool for the job.

When you think of automating tasks in a vSphere environment the first tool you probably think about it PowerCLI. For all less technical readers out there: VMware vSphere PowerCLI is a command line interface tool for automating vSphere tasks.

The Upsides

PowerCLI has the backing of a huge community. There are also plenty of books on the subject. On top of that there are a lot of command lets available from all kind of vendors so it integrates easily with a lot of products.

Thanks to the huge community it is pretty easy to learn PowerCLI or to build your scripts by just recycling code that can be found online and in books.

Another upside is that it is object oriented. This makes passing around information and monipulating the information pretty easy

The Downsides

The object oriented nature of PowerCLI could also be a downside depending on where you’re coming from. If you are used to writing bash scripts then some of the PowerCLI syntax may seem familiar but handling objects can be confusing.

Another disadvantage in my opinion is that you need a windows machine to run powershell. Me being a linux guy I really don’t feel a need to run any windows machine. Especially in lab environments where you can get away with running vCenter VA instead of the windows installation.

The last disadvantage is not specific for powerCLI but applies to scripts in general: Simple tasks are easy to automate but more complex tasks or long processes will result in huge scripts or piles of scripts which are hard to understand and very hard to troubleshoot and modify if needed.

The right tool for the job?

So is powerCLI the right tool for your job? Of course this depends on what the job is. I think it’s the right tool if you’re automating vSphere administration tasks. In that case it can make your life easier and save time. But if you try to automate whole IT Operations processes I highly doubt if this is the right tool you. More on that in a future blog post.