Intro Today, we have released a new version of PowervRA, 4.0.0 with support for vRA Cloud and vRA on-premises version 8.0. The observant among you will notice that we’ve incremented the PowervRA version from 3.7.0 to 4.0.0. We’ve done this since there is a significant breaking change.
The API for vRA Cloud / 8.0 is completely different to that which exists for vRA 7.x and earlier. If you’ve been with the product for a while you’ll be aware of the pain challenge it has been to work with since inception due to the split brain nature of the product, more info here and here.
When Craig and I first created PowervRA and PowervRO in 2016 we only initially thought about using them for our own purposes, since we were on a project at the time which required heavy use of automation around vRA and vRO. When we decided to put them out into the community we never expected them to become as popular as they have done.
It was a fun experience for us, both in learning about collaborating, developing and releasing a PowerShell module, and the benefits it was bringing to our own jobs.
A few months ago we had an issue logged in PowervRA where it was not possible to make a connection to the vRA appliance after it had been locked down following the VMware hardening guide. Specifically this was because SSLv3/TLSv1 (weak ciphers) had been disabled.
By default, Windows PowerShell 5.1 has the following Security Protocols available, Ssl3 and Tls - hence the above failure.
It’s possible to workaround this by adding in the security protocol required, in this case TLS 1.
There have recently been a number of blog posts around modifying the All Services icon in vRA, and how to change it programmatically:
http://www.vmtocloud.com/how-to-change-the-vra-7-2-all-services-icon/ - curl https://virtualbrakeman.wordpress.com/2017/03/17/replacing-the-all-services-icon-in-vrealize-automation/ - Python http://read.virtualizeplanet.com/?p=1539 - .Net http://michaelpoore.com/2017/03/how-to-change-the-vra-7-2-all-services-icon-using-vro/ - vRO We had a new feature request open in PowervRA for a while to do the same thing, so I figured it would be a good time to go and add it, so that the same change to the icon could be done from PowerShell.
Back Story For a while Craig and I have had a number of requests regarding offering OS X and Linux support to PowervRA, particularly since in case you weren’t aware PowerShell is now available on those OSs and 3rd party modules such as PowerCLI are heading towards supporting that. We first looked at offering this support for PowervRA when the first Alpha release of PowerShell Core was shipped, however we were blocked by a couple of issues, particularly this one regarding certificate checking.
Update 29/09/2016:
The API documentation for importing a vRA Content Package contains a warning:
At this point, we don’t support any form of rollback strategies. A failed import may potentially leave the system in an inconsistent state. Hence, its highly recommend to run a precheck/dry-run before the import to validate the package. See HTTP POST /api/packages/validate for more details. This will help catch most of the errors upfront.
Consequently, in release 1.
For the PowerCLI book 2nd Edition I helped put together a chapter on vRealize Orchestrator. Most of the chapter was focused on running PowerShell scripts from vRO, which was something I’d had a fair bit of experience with in projects I had been on and also thought would be what most people reading would be interested in. At the end of the chapter I added a few functions using the vRO REST API to run things in vRO from PowerShell as a bit of an after-thought.
One of the things we did for the 1.2.2 release of PowervRA was to test all of the functions against a vRA 6.2.4 deployment. Now that we have created Pester tests for all of the functions, it is quite straightforward for us to test against different vRA versions.
While we had initially targeted vRA 7+ because of the better API support, we know that currently the majority of installations out there are 6.
Learning Pester has been on my list to get done this year and while working on PowervRA I finally had a real project that could make significant use of it. Being able to automate the testing of each PowerShell function means that we can quickly test the impact of any changes to a function. Also, it means that we can test the whole module full of functions against new (and potentially old) versions of vRA.
One of the reasons behind creating PowervRA was as a consultant I often have the need to quickly spin up vRA Tenants and / or components within those Tenants to facilitate development or testing work of other things I am automating. PowervRA contains three functions, which when joined together would make a basic vRA Tenant available for use: New-vRATenant, New-vRATenantDirectory and Add-vRAPrincipalToTenantRole.
The following code example demonstrates how to use these in conjunction with each other to make a vRA Tenant (make sure to first of all have generated an API token with Connect-vRAServer with an account that has permission to create a vRA Tenant):