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.

I like the new Swagger UI for the vRO API, it makes it really easy to use: While using it to figure out some stuff around importing a package, I hit an issue with the tagImportMode parameter: Depending on which option selected, the following additions to the URL were listed in the documentation as follows: https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Do%20not%20import%20tags.** https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20and%20overwrite%20existing%20values.** https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20but%20preserve%20existing%20values.** However, none of these choices seemed to work, just resulted in 400 (Bad request).

I was using the Panini iPhone app to track our Euro 2016 sticker collection until it helpfully lost all of the data I had input. So I went back to an Excel workbook I had created for previous tournament collections and thought it would be worth sharing it. On the data sheet track via a colour which stickers you have got, then you can easily see which ones you still need.

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.

vRO 7.0.1 in Design mode contains a new toolbar button in Packages; Import package from folder: Previously it was possible to export a vRO package to either a zip file or directly to a folder, but only import back from a zip file. Exported to a folder test, we get the following: Now in a clean vRO server, I currently do not have those workflows: If I select the Import Package from folder button, I can browse to the folder contained the previously exported to a folder package:

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.