vRA/vRO 8.1 Powershell – Peaking Under The Hood

One of the new features in vRealize Automation (vRA) and vRealize Orchestrator (vRO) 8.1 was support for PowerShell. This means there are now 4 scripting language options for Action Based Extensibility (ABX) in vRA and Workflows in vRO. In this post, I’m going to have a look at some of the technical details of the PowerShell implementation.

Why We Should Care

There’s two items that come to mind about why we should care about the PowerShell implementation. The first relates to the history of PowerShell itself. Up until 2016, PowerShell had been based upon the full .NET framework. In that year, Microsoft announced PowerShell Core, which was based on .NET Core. This allowed PowerShell to be used on non-Windows platforms like Linux. This new “branch” of PowerShell had reduced functionality, with many modules no longer working. Eventually PowerShell Core was re-branded to a 6.x version line. In March 2020, PowerShell 7 was released. This version was an attempt to close the gap in functionality between the two branches.

The second item is how PowerShell was used in vRA/vRO 7.x. In 7.x it was possible to add a PowerShell host. The PowerShell host was a Windows system configured to allow vRO to remote into it to execute commands. This created an incredible amount of flexibility because you could install any modules you liked on the host. On the down side, it added complexity (more moving parts to manage) and security issues (like ensuring the PowerShell Host had a network path to each target, and Kerberos double-hopping issues).

With this background in mind, it becomes relevant to figure out what implementation of PowerShell is used in vRA/vRO and other information about the implementation.

Read morevRA/vRO 8.1 Powershell – Peaking Under The Hood

Calling System Center Orchestrator Runbooks from vRealize Orchestrator

Sometimes you end up having to put in place an implementation that’s pretty crazy to get something (non-production) over the line. This was the case recently where I used vRealize Orchestrator (vRO) to call System Center Orchestrator (SCORCH) Runbooks. That is, using Orchestrator to call Orchestrator…

yo dawg...

A lot of the credit for figuring out how to do this goes to Laurie Rhodes and their blog post about calling SCORCH runbooks via REST using Powershell. It was my starting point for this piece of work and I was able to adapt the core pieces of this for my scenario.

vRO Configuration

Assuming there’s existing SCORCH and vRO instances, the first task is to add the SCORCH server as a REST host in vRO. This can be achieved by running the “Add a REST Host” workflow that comes with vRO. The “Orchestrator Web Service” runs on port 81, so that will affect the settings for the host.

Host properties for Add a REST Host
Host properties for Add a REST Host

Read moreCalling System Center Orchestrator Runbooks from vRealize Orchestrator

Managing Local Admins via vRealize Automation

One of the major benefits of vRealize Automation (vRA) is the ability to add and extend the “Actions” available. These Actions enable self-service by the customer. One scenario I wanted to try was allowing someone to manage local administrators on a virtual machine they had provisioned.

Creating The Workflow

The starting point with this is creating a Workflow in vRealize Orchestrator (vRO). Managing local administrators would mean being able to add and remove members, so if I wanted it as a single workflow, there would be some sort of branching logic, such as the flowchart below:

Simple Workflow

Read moreManaging Local Admins via vRealize Automation

VMware vRealize Automation 7.6 – What’s New

VMware released an update for vRealize Automation (vRA) at the start of this month. This was a slight increment from 7.5 to 7.6. At a high level, two key areas of change are NSX integration and the vRealize Orchestrator (vRO) user experience. The Release Notes goes into a bit more detail and I’ll be using those more detailed items as a guide for the content in this post. I will be skipping over the new NSX pieces as I don’t have those available to me.

Read moreVMware vRealize Automation 7.6 – What’s New

Managing F5 Load Balancers with vRealize Orchestrator

F5 Load Balancers (LB) have been a common feature across a number of environments I’ve worked at. While administration of these devices is generally performed via the web interface, F5s also have a REST API that allows the same management tasks to be performed. This opens the possibility of using VMware’s vRealize Orchestrator (vRO) to manage F5 Load Balancers via the same REST API.

Read moreManaging F5 Load Balancers with vRealize Orchestrator

vRealize Orchestrator – PowerShell Hosts

PowerShell Hosts are one of the types of endpoint available in vRealize Orchestrator’s Inventory. By having a PowerShell Host, you can leverage the breadth of PowerShell functionality from within your vRealize Orchestrator workflows. In this article, I’ll run through adding a PowerShell Host as well as some considerations from a technical and security point of view.

Adding A PowerShell Host

vRealize Orchestrator has a built-in Workflow for adding a Host under Library > PowerShell > Configuration. Run the “Add a PowerShell host” Workflow to start it. The opening interface is below:

First page of the “Add a PowerShell Host” workflow

Read morevRealize Orchestrator – PowerShell Hosts

Creating Service Accounts with vRealize Orchestrator

vRealize Orchestrator (vRO) has a lot of plugins that allow it to integrate with other systems and services.  One of such plugin is for Active Directory.  This plugin allows you to perform a number of standard AD activities, like creating users.  vRO already has built in workflows to create and manipulate users.  In this post, I’m going to run through what you might end up implementing if you wanted to be able to create Service Accounts via vRO.

Read moreCreating Service Accounts with vRealize Orchestrator

Improving the vRA Admin Experience – Reservation Alerts to Slack

The Reservation system in vRealize Automation (vRA) provides a bucket of resources to a team or business unit via Business Group.  A risk with Reservations comes about with how I think VMware intended them to be used vs how some organisations may use them.  I suspect VMware’s intention was that Reservations should be self-managed by the Business Group associated with it.  This makes sense if each individual team has a Business Group as the scope of what’s in the Reservation is “their stuff”.  It would mean if a Reservation reached capacity, it would be up to that team to manage the situation.

What if the Business Group was being used differently, where it covers multiple teams?  In the event of the Reservation becoming full, the scope is larger than one team.  In this situation, it might be good to get a heads up on when Reservations are running low on resources.  Email alerts can be setup and yes, sent through to Slack, the formatting in Slack is less than desirable.  So I decided to look at a way of doing it better.

Read moreImproving the vRA Admin Experience – Reservation Alerts to Slack

Improving the vRA Customer Experience – Send Chef errors to Slack

One of the issues that can be amplified by automation is logging.  Some logs have an ephemeral nature, having a short lifespan due to various factors.  This can be especially painful if the logs relate to failures and contain information that could assist in fixing the problem.

This was the issue I was seeing when vRealize Automation (vRA) requests would fail when Chef attempted to apply settings.  If Chef failed critically, vRA would be made aware of it and fail the entire request.  Of course, vRA would then delete the virtual machine and the local Chef logs.  In many cases, there was a gap of only a minute or two between the Chef failure and the vRA cleanup tasks.

Read moreImproving the vRA Customer Experience – Send Chef errors to Slack

Bitnami