A few days ago, VMware released an update for vRealize Automation (vRA). The list of improvements seems relatively minor this time, as detailed in the Release Notes. It seems the biggest change was mentioned in the blog announcement for this release, where vRA is moving to monthly releases. Since these updates are feature focused, that potentially means a more frequent update cycle for administrators. Hopefully this means the update process will become smoother going forward. From personal experience, it’s been a bit hit and miss.
VMware have released another update to vRealize Automation (vRA) 8. Like 8.3, I had issues updating to this version using Lifecycle Manager. This is why I never got around to writing about the 8.3 release. I ended up doing a fresh installation of 8.4 to see what’s new and changed.
Going through the Release Notes, it seems that this release is a set of incremental changes. There is a change to how the Access Token for the API functions, which could have an impact on those who are leveraging the REST API. As per the notes, there’s also been a lot of improvements to accessibility. It’s good to see VMware pushing ahead with this sort of initiative.
IP address management (IPAM) is one of those areas that suddenly becomes important when infrastructure automation is implemented. In the past, an IT team may have used an Excel spreadsheet for manually tracking address assignments. When the number of servers being provisioned increases due to automation, this manual approach isn’t viable anymore. An alternative could be to just allow dynamic addressing using DHCP but that raises its own issues (for example, some server-based applications insist on a static address).
There’s a lot of products out there that do IPAM. I’ve previously used the product from SolarWinds, in my home lab I use phpIPAM. In both situations, the use of the IPAM product was similar – a vRealize Orchestrator (vRO) Workflow would request an IP address during the provisioning of a virtual machine. A matching Workflow would execute when the virtual machine was decommissioned, signalling the IPAM system to release the IP address for reuse.
As part of the process in moving my home lab setup from vRA 7.x to 8.x, this is one of the functions I’d like to carry across.
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.
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…
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.
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.
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:
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.
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.
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:
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.