I’m working on a project that requires direct interaction with the vRO API from a third party system. Maybe I’m getting less effective at using Google in my old age, but I had a heck of a time finding good solid code for authenticating to the API using anything, including PowerShell.

Typically I’d use Invoke-vRARestMethod from PowerVRA for this, but unfortunately I had some additional requirements that mandate me using a bearer token.

As a point of reference, you can view all of of the available APIs for vRealize Automation by navigating to this url: https://{your-vra-url}/automation-ui/api-docs/. We’ll be working with the “Orchestrator” API

The function below will return a bearer token, which you can use in future API calls to vRA.

Param’s:
Line 3: vra_server – the fqdn of your vRA 8 instance
Line 4: password – password associated with your vRA 8 account used to authenticate. As mentioned, please be smart here. Plantext passwords are bad.
Line 5: username – Unlike vRA 7, vRA 8 needs you to split your username and domain apart. For example, in vRA 7 you’d authenticate using the username jon.smith@rainpole.com, where in vRA 8 you authenticate using just the username jon.smith
Line 6: domain – This is where the domain goes (Example: rainpole.com)

Lines 14-24: We’re setting the body up to be included in the rest request. There’s some special formatting required so we’re using the replace method to modify the string.

Line 27: Build a simple variable with the URI used for authentication. More can be found on this in the API documentation mentioned above.

Lines 29-35: Make the API call, build the bearer token (essentially add the word “Bearer ” to the beginning of the authentication token), and return it.

Short and sweet. I’ll be adding some more snippets and problems in the future.

It’s the network team’s fault…

The Scenario

Imagine you have an environment that has hundreds of VLANs. When you build a new cluster, there’s a real possibility that one host out of many is mis-configured on just a single port group or VLAN. It’s a pretty simple issue, but it’s like finding a needle in a haystack. Because of that, it’s incredibly difficult to troubleshoot, so I wrote a script to run through every ESXi host, and test connectivity on each port group.

If you haven’t used RVTools before, I’d definitely suggest taking a look. In case you’re one of the few that has not used it, it’s a quick tool to generate a point-in-time report of the inventory/configuration/health of a vSphere environment. While it’s one of the best tools out there for a quick and dirty report of an environment, the challenge I often face is that it outputs too much data. The other challenge I’ve faced is that it’s incredibly difficult to combine and analyze data from multiple outputs.

I’ve been working on a project that uses the -runasync parameter on the move-vm cmdlet. The obvious problem with running jobs asynchronously is that you lose the ability to determine the status of whatever task as soon as you submit it.