VMware vSphere Autodeployment (virtuallyGhetto)

Did I already mention that I am a huge fan of the Autodeploy Script from William Lam? William created a bunch of script which help you to deploy a nested VMware environment in an automated way. The environment itself is built with a VSAN based datastore.

You can find the Blog Post from William here:

vGhetto Automated vSphere Lab Deployment for vSphere 6.0u2 & vSphere 6.5


and his GIT repository with the scripts here:


When you look at the Blog Post from William you can see that he uses a single ESX Hosts for his deployment. In case that you maybe have more ESX host there is a small issue in case that you have a VSAN based cluster. For the deployment of a nested VSAN environment on a VSAN bases Cluster you must set a VSAN Parameter (not recommended for production usage!). William makes these settings only for one host as you can see in this script

if($datastore.Type -eq "vsan") {
My-Logger "VSAN Datastore detected, enabling Fake SCSI Reservations ..."
Get-AdvancedSetting -Entity $vmhost -Name "VSAN.FakeSCSIReservations" | Set-AdvancedSetting -Value 1 -Confirm:$false | Out-File -Append -LiteralPath $verboseLogFile


In my environment a have a four node cluster hosts with HA and DRS configured. In some cases, DRS kicks-in during the enrollment of the nested environment. When a virtual ESX Hosts ends up on a Hosts were the settings was node made, the deployment fails.

In my case I made an improvement (for my usage) to the script where I configure the Fake SCSI settings for all Hosts of a cluster.


if($datastore.Type -eq "vsan") {
$FakeVSANhosts = $cluster | Get-VMHost | ForEach-Object {
My-Logger "VSAN Datastore detected, enabling Fake SCSI Reservations for Host $_ ..."
Get-AdvancedSetting -Entity $_ -Name "VSAN.FakeSCSIReservations" | Set-AdvancedSetting -Value 1 -Confirm:$false | Out-File -Append -LiteralPath $verboseLogFile


So, if someone of you runs into the same problem, just change the lines in the script from William and everything should work like expected.


vCO and Veeam Backup&Replication a powerful combination

Last week I did a Webinar for Veeam in Germany. My topic in this webinar was Automation and Orchestration. Due the circumstance that the Webinar was in German, I decided to make this post to share the information for the rest of the non-German speaking world.

For those who understand German the Webinar was recorded and can be found here:


Before you start some really important notes on the combination of vCO and Veeam B&R.

Some Veeam B&R commands need a connection to the vCenter Server. When you invoke your commands in a PowerShell Window on your Backup host, the PowerShell uses CredSSP to provide the vCenter Server Login Information’s from Veeam B&R to the vCenter Server. If you do the same in a vCO Workflow, this does not work! The reason why it not work is because the vCO PowerShell plugin only Supports Basic- and Kerberos Authentication. In every Environment I used so far, the Servers where in a Windows AD. This allowed me to use the Kerberos Authentication in the vCO PowerShell Plugin. In the last time, I did many tests with the Basic Authentication and had a lot of problems and errors with that type of Authentication. So my recommendation for the Authentication is “use the Kerberos Authentication to avoid a lot of trouble and problems!”

Prepare the Backup Server

At the moment Veeam Backup&Replication has no SOAP or REST API Interface. The only available interface is PowerShell.  To use the Power Shell from vCO some necessary preparations has to be done.

First of all Veeam Backup&Replication must be installed with the PowerShell Extension. This is done during Installation or if you already installed it without PowerShell  to just start the Installation again and add the PowerShell feature.

After you have installed the PowerShell Extension, you can start it from the Management Console.

This Button starts a PowerShell shell with an already loaded Veeam Extension. The Files for this Veeam PowerShell Extensions reside here:  “C:\Program Files\Veeam\Backup and Replication” in this path the file ”Install-VeeamToolkit.ps1” is important to load the extension automatically. We will use this file later in our vCO Workflows.

The next we have to do is to check if the Veeam Backup Server has the PowerShell in the Version 3.

For the first workflows and test I recommend to change the Host execution Policy to unrestricted. When everything goes fine, you can change the execution Policy to remote-signed

Set ExecutionPolicy (RemoteSigned / Unrestricted )

After that, we need a command Window on the Backup server. Here we have to insert the following commands:

Run the following command to set the default WinRM configuration values.

c:\> winrm quickconfig

(Optional) Run the following command on the WinRM service to check whether a listener is running, and verify the default ports.

c:\> winrm e winrm/config/listener The default ports are 5985 for HTTP, and 5986 for HTTPS.

Enable basic authentication on the WinRM service.

Run the following command to check whether basic authentication is allowed.

c:\> winrm get winrm/config

Run the following command to enable basic authentication.

c:\> winrm set winrm/config/service/auth @{Basic="true"}

Run the following command to allow transfer of unencrypted data on the WinRM service.

c:\> winrm set winrm/config/service @{AllowUnencrypted="true"}

Enable basic authentication on the WinRM client.

Run the following command to check whether basic authentication is allowed.

c:\> winrm get winrm/config

Run the following command to enable basic authentication.

c:\> winrm set winrm/config/service/auth @{Basic="true"}

Run the following command to allow transfer of unencrypted data on the WinRM client.

c:\> winrm set winrm/config/client @{AllowUnencrypted="true"}

Run the following command to enable winrm connections from vCO host.

c:\> winrm set winrm/config/client @{TrustedHosts ="vco_host"}

After we have executed the commands, we are ready with the Backup Server. Let’s now switch to the vCO Server.

Prepare the vCO

From the view of the vCO the first and important thing is, that the PowerShell Plugin is installed and activated in the vCO Server. If you are not familiar with this, the documentation can be found here:


When the PowerShell Plugin is ready, we can start to add the Backup Server to our repository. This could be done be starting the PowerShell Workflow to “Add a new Server”. The needed information’s are self-explaining.

On the second site we have to choose as PowerShell remote host type “WinRM”. As Protocol we use “HTTP” or “HTTPS”. The last point is Authentication. Here we choose “Kerberos”.

On the last page we have to choose if we use a “Shared session” or a “User Session”. When you chose the shared session you have to insert User credentials. When you decide to use “User Session” you have to insert the Authentication Details in every PowerShell call.

After we are finished with the pre requirements we can start with our first Workflow. Let’s us a simple one…..

Develop the vCO Workflows

If we want to figure out which Veeam Jobs exist on our Backup Server we need the command Get-VBRJob.

The easiest way to start is to copy the Workflow “Invoke a PowerShell Script” into a folder of your choice.

There you have to insert a second scripting element and move the host and script Inputs as Attributes.

In this scripting element we put our script which includes the PowerShell code.

To use a Veeam PowerShell command in a vCO Workflow we need somewhat more input then just the command. We have to load the Veeam Extension into our PowerShell Session which we invoke from the vCO Server. Here is the complete code for the call:

script = "# Load Veeam Powershell Extension into the actual session \n"
+ "'C:/\Program Files/\Veeam/\Backup and Replication/\Install-VeeamToolkit.ps1' \n"
+ "add-pssnapin VeeamPSSnapin \n"
+ "# Veeam is loaded \n"
+ "Get-VBRJob";

For us the full example looks like this.

Now you can use this command in your own workflows. Now that command isn’t really useful by now. Let insert a virtual machine into a Backup Job after creation. For that we have to use the Veeam Command Add-VBRJobObject. For this command we need some information which we can collect during the Session. A full command to insert a VM into a workflow looks like this:

Add-VBRJobObject -Job $(get-VBRjob -Name "+ JOBNAME+ ") -Server $(get-VBRServer| Where {$_.Type -eq 'VC'}) -Objects " + VMNAME + " }"

The Values JOBNAME and VMNAME must be specified as vCO Attributes or Inputs.

When you now try to execute this like the command before:

You will get an error like this one:

Failed to login to “vcenter.example.com” by SOAP, port 443, user „root”, proxy srv: port:0 +   CategoryInfo : InvalidOperation: (Veeam.Backup.Po…FindVBRViEntity:FindVBRViEntity)         [Find-VBRViEntity], Exception + FullyQualifiedErrorId :   Backup,Veeam.Backup.PowerShell.Command.FindVBRViEntity

Why this happens?  Here we get into trouble with the Authentication against the vCenter Server. If everything was fine before and you can execute the command from a PowerShell shell the problem is in your workflow. Like described before we have to Authenticate against the vCenter Server from our Workflow.  vCO has no option to do this automatically . We have to change our Workflow to this:


script = "invoke-command -session $(New-PSSession <strong>BACKUPSERVER</strong> -Authentication Kerberos -Credential $(new-object -typename System.Management.Automation.PSCredential -argumentlist<strong> USER@DOMAIN</strong>, $(convertto-securestring -string '<strong>PASSWORD</strong>' -asplaintext -force))) -scriptblock{ set-item wsman:localhost\Shell\MaxMemoryPerShellMB 1024"
      + "\n Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue"
      + "\n Add-VBRJobObject -Job $(get-VBRjob -Name "+ <strong>JOBNAME</strong> + ") -Server $(get-VBRServer| Where {$_.Type -eq 'VC'}) -Objects " + VMNAME + " }"

This script looks really different then the script before. What do we do here? We generate a new Powershell session on the Backup Server (New-PSSession).  For this session, we define a Username (USER@Domain) and a Passwort (PASSWORD). For the Username it is very important that the user is written as user@domain. Otherwise the Kerberos Authentication will not work and the Workflow will fail! At last we set the Memory for the new Shell to 1024 MB (set-item wsman:localhost\Shell\MaxMemoryPerShellMB 1024) If we doesn’t exceed the Memory the workflow will also fail! At last we load the Veeam Snapin and execute the Script job…..

That’s easy or?

With this Background Knowledge you can start to implement your own Automation Workflows with included Backup of your virtual machines with Veeam. It is also possible to integrate the Replication….you have just to implement the replication command and start your Automation….

In the Veeam Community there is a good PowerShell forum. So if you have trouble with your Veeam PowerShell commands, get a look there:


Have fun with the Power of vCO 😉


Backup vCloud Director vApps automatically, driven by vCO

This video shows another example how powerful vCenter Orchestrator really is:

Auto-Create a new Backup Job, whenever a new vApp is deployed in vCloud Director

vCloud Director Backup driven by vCenter Orchestrator from Joerg Lew on Vimeo.

For that I used the AMQP-Plugin, so that the “Create VM“-Event in vCD triggers the Generate Backup Job-Workflow. This workflow calls out to a Powershell-Script to create a new Backup Job using the vendor’s snapin. I used Veeam Backup&Recovery, because they provide a lot of helpful Cmdlets to automate their backup solution.

What to learn?

  • For vCloud Administrators: vCO allows you to integrate vCD with the rest of your IT-world
  • For Backup Vendors: Provide a Plugin for vCO (or at least a basic API), and your customer can integrate your backup product with the rest of their IT-world.
    (Then you don’t even have to develop the integration for vCloud Director from scratch 😉 )
  • For every VMware User: Even without vCloud Director you can use vCO for a lot of cool stuff to integrate your IT-world (what about to create a new Backup Job whenever anybody deploys a Template in vCenter…?)
  • For all: Be creative! Everything is possible with vCO!

References (in case I kicked your mind :mrgreen:)


vCO integration with VMware View

Just that you do not miss it: @cloudnutz postet a great example how to leverage the Powershell plugin to call VMware View PowerCLI cmdlets from vCO Workflows:


Find the original post also on http://cloudnutz.com/2012/03/07/using-vmware-vco-to-manage-vmware-view/

And don’t miss some (unofficial, but don’t blame me (this time 😳 ) 😛 ) additional PowerCLI cmdlets for VMware View: http://velemental.com/2012/02/04/unofficial-advanced-vmware-view-powershell-cmdlets/

And Dear VMware View Team: Please give us a full (and documented) (and official) API!

Or even better: What about a View-Plugin for vCO?
I know a lot of customer having use-cases for it (and a lot of people having to use workarounds like this for now). Desktop-as-a-Service and Cloud Desktops need Orchestration (just to add the buzzwords for the robots 😈 )


Problems with AD-Plugin for vCO? Uninstall all old Microsoft-Plugin-Stuff!

Some problems came up getting the ActiveDirectory-Plugin for Orchestrator run. Mostly the problems are related to wrong credential settings in the configuration:

If you had the (old) Micrsoft-Plugin installed, you have to uninstall it completely. For details about how to do this, and some explanation, follow this discussion on the forums: http://communities.vmware.com/thread/319105

The new AD-Plugin has no WMI-support. Powershell has a good WMI-support. So the PowerSShell-Plugin might fit into the gap? Surely worth to figure out more and draft some ideas for the Roadmap…;-)   Stay tuned!