The original Project Onyx (also here) was a VMware Fling which intercepted calls between the C# vSphere client and vCenter and could translate things you did in the GUI client to code in your choice of languages; SOAP, C#, PowerCLI, and JavaScript. This was really useful if say a thing you needed to do was not yet covered by a PowerCLI cmdlet, or you wanted to try and make it faster by using Get-View, or you didn’t know how to code it in JavaScript for vRO.
There is an excellent post over at Automate-IT.today which details how to create a vRA IaaS Blueprint from vRO. Once you have used the workflow from that site to create a Blueprint it still needs to be published before it can be used as a vRA Catalog Item, added to a Service etc.
Note that even updating Christiaan Roeleveld’s code to set the property IsPublished to true, doesn’t actually publish the Blueprint.
After creating a Blueprint in vRA it is necessary to publish the Blueprint into the Catalog so that it can be consumed by the appropriate set of users. This creates a link between the two different items since the Catalog Item is part of the vRA appliance and the Blueprint can be found in the Windows appliance.
Here’s the Blueprint details from the Inventory tab of vRO, with the virtualMachineTemplateID, a.
As of vRealize Automation version 6.2.1 there are a few different approaches to automating elements of the product itself, as opposed to using it for the automation tasks it is designed to help you with. This is along the lines of configuring elements within vRA, some of which I have covered previously within this blog post series. That series focused on using the vRA plugin for vRealize Orchestrator. However, the plugin doesn’t cover everything that you might need to automate within the product.
When working with vRealize Orchestrator and Active Directory it has been possible for a long time to use the built in Active Directory plugin for many tasks. One of the drawbacks with the various iterations of the 1.0.x version of the plugin however, was the lack of support for multiple domains and multiple domain controllers. This was naturally quite restrictive in environments with more than a single domain which is pretty common for many reasons since as distributed management, mergers & takeovers and poor planning ;-)
While working in vRealize Orchestrator with an external SOAP based system I was having issues with line breaks being removed from text sent across as part of a reasonably large SOAP request containing multiple items.
Say we have the following text strings and want to pass them into the SOAP request with line breaks in-between each one:
[code language=“javascript”]
text1 = ‘This is text1’; text2 = ‘This is text2’; text3 = ‘This is text3’;
After setting up a fresh deployment of the vRO 5.5.2.1 appliance and configuring it to use an external SQL database I noticed that many of the default plugins appeared to be missing in the Workflow library folder:
(there should be a lot more than listed here)
Logging into the vRO configuration page showed the below list of plugins (and more going off the screen) appeared to exist and be installed correctly.
Requirement:
Present a vCO / vRO form which contains two password entry fields using SecureStrings and a field which displays whether the two entered passwords match.
Using an if statement to test whether two SecureStrings are equal will fail even if the text entered is identical. As mentioned in this communities post, in a workflow it is possible to take the SecureStrings into a scriptable task and output them as Strings.
I needed to look into the possibilities around granting delegated access to vCO workflows and ways to consume them without necessarily using the standard vCO client. The general idea was to have one group of people authoring workflows and another group consume some of them.
vCO has the ability to delegate permissions to workflows and folders of workflows using users and groups; ideally you would have already setup vCO to use your AD for authentication so enabling this delegation via AD users and groups.
Bit of an obscure one this, but I hit it recently and wasted some time on it so I thought it might be useful for someone, somewhere, someday.
If you need to call a PowerShell script via a command line style prompt (maybe in a scheduled task or an external system like vCenter Orchestrator) there are a number of different options.
I was troubleshooting a problem where an existing system was failing with a command along the lines of this: