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.
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.
The vRO Action requestCatalogItem in the com.vmware.library.vcaccafe.request folder can be used to programmatically request an item from a vRA Catalog.
One of the inputs is a properties object which permits you to dynamically make changes to settings configured within the Catalog Item you are deploying from. So say for instance the Catalog Item maps to a Blueprint configured with 1 vCPU, you could change this at request time to be 2 vCPU - which for instance might lead you to needing to maintain fewer Catalog Items.
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):
A colleague asked me the other day about how it might be possible to find out which vRO workflow was mapped to an Advanced Service Blueprint (or XaaS Blueprint) in vRA. If you look in the vRA GUI after a Service Blueprint has been created you can’t see which vRO workflow is mapped.
During the creation of the Service Blueprint there is a Workflow tab to select the vRO Workflow:
While putting together the PowerCLI book 2nd Edition we initially included in the proposed Table of Contents a chapter on vRealize Automation. However, it was fairly apparent that at that time (early 2015) there wasn’t a lot which could be done to fill out the chapter with good content. Firstly, most of the relevant content would be included in the vRO chapter, i.e. use vRA to call a vRO workflow to run PowerShell scripts.
Part of the wizard to setup vRA 7 includes a step towards the end to create a vRO workflow that will create initial content within a vRA Tenant. To run the workflow, login to the default vRA tenant as the configurationadmin account created as part of the initial setup:
There are various inputs required depending on such things as if you wish to use the default Tenant or create an additional one: