DefinIT

Alexa, turn on my workload cluster

Like many other geeks out there, I received an Amazon Echo device this Christmas, and whether it’s a fad or not, I’ve spent a few happy hours setting up my Hue lights and some other automation. The room in the house with the most automation is my office – the novelty may wear off, but walking in each morning and saying “Alexa, turn on my office” and having everything wake up for me is really cool.

I already have a vRealize Orchestrator workflow to shutdown my workload cluster. What I want to do is trigger that by a voice command from Alexa. (more…)

vRealize Automation 7 Custom Hostname with Event Broker (EB) Subscription

vRAThe new Event Broker service in vRA7 is one of the most exciting features of this latest release, the possibilities for extensibility are huge. At this point it time you can still use the old method of using workflow stubs to customise machine lifecycle events, but at some point in the future this will be deprecated and the Event Broker will be the only way to extend.

With this in mind, I wanted to use the Event Broker to do something that I am asked on almost every customer engagement – custom hostnames beyond what the Machine Prefixes mechanism can do.

This, as it turns out, Event Broker extensibility is not the simplest to get your head around – there is a very large (>100 page) extensibility document to parse!

For the purposes of this post, I will be using the BuildingMachine lifecycle state. This is because I want to modify the hostname before the VM is built – in much the same way as you would with the old ExternalWFStubs.BuildingMachine method.

One of the key differences between using the old WFStubs method and the new EB method is that it does not pass the same objects, there is no vCAC:Entity or vCAC:VirtualMachine – only a Properties object which holds the request properties. These include any custom properties from the blueprint. (more…)

#VMworld2015: vRealize Automation 7 Briefing Notes

vmworld2015-logoI was fortunate to attend a vExpert briefing for vRA.Next, which was announced this morning to be vRealize Automation 7. The briefing was run by Jad El-Zein (@virtualjad) along with Grant Orchard (@grantorchard), Brian Graf (@vbriangraf), Kimberly Delgado (@KCDAutomate) and Jon Schulman (@vaficionado) – if that list of names doesn’t fill you with confidence for vRA.Next, then I suggest you follow them on twitter and trust me that it’s a crack team!

(more…)

Configuring vCenter Orchestrator (vCO) with PowerShell over HTTPS with Kerberos Authentication

vCenter Orchestrator (vCO)As a PowerShell fan I find using the vCO PowerShell plugin makes my life a whole lot easier. What isn’t easy however, is  the configuration of vCO and a PowerShell jump host. Having done it a few times, this is my method for ensuring a secure working connection using HTTPS and Kerberos.

Configure the Orchestrator Appliance

Since we’re planning on using Kerberos authentication, we’d better ensure that the time is correct AND syncs to the same source as the domain.

image

In order to configure Kerberos on the Orchestrator appliance you need to SSH in to the box and log in using your root credentials.

Create a new krb5.conf file under /usr/java/jre-vmware/lib/security/ using the following command:

vi /usr/java/jre-vmware/lib/security/krb5.conf

Enter the following, substituting your domain details, and the local domain controller for “kdc =”. Case is important here, so use caps where I have:

[libdefaults] 
        default_realm = DEFINIT.LOCAL 
[realms] 
        DEFINIT.LOCAL = { 
                kdc = dc-01.definit.local 
                default_domain = definit.local 
        } 
[domain_realms] 
        .definit.local=DEFINIT.LOCAL 
        definit.local=DEFINIT.LOCAL 
[logging] 
        kdc = FILE:/var/log/krb5/krb5kdc.log 
        admin_server = FILE:/var/log/krb5/kadmind.log 
        default = SYSLOG:NOTICE:DAEMON

If the krb5.conf file did not exist, change the permissions to allow the system to read the file:

chmod 644 /usr/java/jre-vmware/lib/security/krb5.conf

Configure the PowerShell host

I’m configuring to use HTTPS with Kerberos authentication, so the first thing I need is a certificate with the Server Authentication (1.3.6.1.5.5.7.3.1) key usage. If you’re running a Microsoft PKI, the default Computer certificate template is perfect for this.

Open MMC and add the Certificates snap in for the Computer account, find your certificate and double-click to open. Select the Details tab and scroll to the bottom – copy the thumbprint value to use in the below command.

image

Enable WinRM with the following command:

winrm quickconfig

Increase the amount of memory allowed to be allocated to each executing PowerShell:

winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}

Create an HTTPS listener using the thumbprint and the following command:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="host_name";CertificateThumbprint="certificate_thumbprint"}

 

 

image

Finally, enable Kerberos authentication:

winrm set winrm/config/service/auth @{Kerberos="true"}

The PowerShell host is now listening on port HTTPS 5986 authenticated by Kerberos!

Test the WinRM connection

Using another computer on the same domain, run the following command to execute NSLookup on the PowerShell host:

winrs –r:https://mgmt-01.definit.local:5986 nslookup google.com

image

Adding a PowerShell host

The final step is to add a PowerShell host to Orchestrator. Open (or install first and then open) the Orchestrator client and connect to your vCO appliance. Make sure you’re connecting using your domain account (i.e. you need to pass your domain identity to the vCO appliance to use for authentication to the PowerShell host).

Specify a name for the PowerShell host (the hostname of the server is fine), the FQDN (best to use FQDN with Kerberos) and the port that we created the listener on – 5986 by default.

image

Select WinRM as the host type, HTTPS and do not accept all certificates, finally select Kerberos authentication.

image

Select “Session per user” to configure the remote host to use the workflow user’s identity. You can enter credentials for a shared session, but this could pose security risks if running as an elevated user.

image

Finish the wizard and wait until the workflow completes:

image

Now we have a PowerShell host added to vCO, we can run a PowerShell script against it over HTTPS and authenticated with Kerberos.

Running a Hello World PowerShell script in vCO

Firstly, lets create “Say-HelloWorld.ps1” script and save it in c:\SCRIPTS on the PowerShell host.

return “Hello World”

Next switch back to the Orchestrator client and select “Design” mode. Create a new folder to contain your workflows (mine is called “DefinIT”) and then create a new workflow (“Test-PowerShell-Hello-World”).

Select the “Workflow” tab and then expand “All Workflows” > Library > PowerShell, then drag the “Invoke an external script” onto the workflow editor:

image

Click on the “Setup” button:

image

Select the value radio button for the “host” binding and then click to select the PowerShell host from the inventory. Select value for the “externalScript” binding and enter the path to the hello world script we created earlier. Select script for the arguments, as we don’t have any. Leave the output binding as is.

image

Now we can run the workflow and select the “Logs” tab to see the output – you can see the “Hello World” that we returned is echoed in the logs.

image

Hopefully this has been a helpful kick-starter into using vCO PowerShell over HTTPS with Kerberos Authentication

Extending a vCenter Orchestrator (vCO) Workflow with ForEach – Backing up all ESXi hosts in a Cluster

vCenter Orchestrator (vCO)In my previous post Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough I showed how to create a workflow to back up host configurations, but it was limited to one host at a time. For this post I’m going to show how to create a new workflow that calls the previous one on multiple hosts using a ForEach loop to run it against each one. This was actually easier than I had anticipated (having read posts on previous versions of vCO that involved created the loops manually).

Ready? Here we go…

Create a new workflow – I’ve called mine “DefinIT-Backup-ESXi-Config-Cluster” and open the Schema view. Drag a “ForEach” element onto the workflow and the Chooser window pops up. This is a bit deceptive at first because it’s blank! However, if you enter some search text it will bring up existing workflows, so I searched for my “DefinIT-Backup-ESXi-Config” workflow that was created in that previous post. (more…)

Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough

vCenter Orchestrator (vCO)As a little learning project, I thought I’d take on Simon’s previous post about backing up ESXi configurations and extend it to vCenter Orchestrator (vCO), and document how I go about building up a workflow. I’m learning more and more about vCO all the time, but I found it has a really steep entry point, and finding use cases is hard if you haven’t explored capabilities.

The steps I want to create in this post are:

  1. Right click host to trigger
  2. Sync and then back up the configuration to file
  3. Copy the file to a datastore, creating a folder based on date and the host

Ideas for future extensions of this workflow include – trigger from cluster/datastore/host folder, email notifications, emailing the backup files and backup config before triggering a VMware Update Manager remediation. Hopefully all this will come in future posts – for now, lets get stuck into the creation of this workflow.

(more…)

Sponsors