VRO

If you use the in-built vRealize Orchestrator instance shipped with the vRealize Automation appliance then you might run into this issue when working with the REST client:

Connection pool shut down (Workflow:Get-IdentityToken / Scripting (item3)#14)

The vRA appliance version I have (6.2 - note to self, need to update lab!) includes the plugin version 1.0.4 for REST. According to the release notes, this was fixed in 1.0.5 - typical!

@vaficionado) – if that list of names doesn’t fill you with confidence for vRA.Next, then I suggest you follow them on twitter and trust me that it’s a crack team!

So, my highlights:

1. Completely automated deployment…almost. The deployment of appliances and installation of IaaS components and pre-requisites will be wizard driven, the Window Servers will need to exist and have an agent installed, and the MSSQL server will also need to be installed. Anyone who’s done a distributed vRA install will know that this is a massive improvement over the current state of affairs.
2. The vRealize Automation appliances will be clustered automatically for core services such as identity, cafe (portal), vPostgres and embedded vRealize Orchestrator (Embedded vRO is now recommended for production).
3. A new identity service. No more vSphere SSO or PSC – VMware Identity Management (vIDM) is a new, highly scalable and performing federated identity platform. Any SAML identity source, and more than 3m users supported per source.
4. An initial setup wizard that creates your first tenant, configuring things like fabric groups, business groups and vSphere endpoints automatically. It will even import your existing vSphere templates as clone blueprints.
5. The old CDK is gone! Instead you can use any event within vRA that is pushed through the RabbitMQ message bus to trigger extensibility through workflow subscriptions.
6. vRealize Orchestrator has a new HTML5 Control Center which is your single admin point for plugin configuration as well as adding metrics and monitoring for all workflows being executed.
7. There’s no need for unique tenant URLs – the new vIDM platform allows a single logon interface for all tenants. (Though you can keep your URLs if you want!)
8. vIDM can also be used to control authentication from IP source, e.g. to restrict logon to a specific subnet regardless of whether the credentials are valid or not. This has some cool ramifications for having the web layer in a DMZ, for example.
9. Functionality is slowly being migrated from the old IaaS/DynamicOps layer to the appliance – this is fantastic news. The migrated portions (such as vSphere Endpoint configuration) are now accessible through the vRA API, as well as gaining the speed and stability that the appliances provide.
10. The new blueprint designer is awesome. Added to that what was AppD is now called App Services and allows you to take a base blueprint (e.g. a CentOS VM) and drag and drop software components that you’ve scripted on top (e.g. Apache, then PHP). You can also drag and drop XaaS (vRO workflows) onto the blueprint, as well as existing blueprints to create nested blueprints.
11. Much fuller integration between NSX and vRA. There’s a whole raft of improvements in the integration between vRA and NSX – e.g. you can drag a new routed network onto a blueprint and it will automatically create a new Logical Switch and Distributed Logical Router to attach the Logical Switch to. Similarly load balancing applications is a drag and drop operation, as is applying existing security groups.
12. All blueprints can be imported and exported in YAML, which opens up exciting possibilities for storing versioned blueprints and retrieving programmatically.
13. There are over 60 lifecycle events out of the box on which you can trigger Orchestrator workflows, but you can create custom filters based on properties and events to extend functionality – the only limitation is what you can imagine!

There are still several months of development to go between now and the GA of vRA 7 and the development seems to be moving at a great pace. Between beta 1 and beta 2 there was a huge amount of change, and even the version demoed today had new features and UI.

Recently, I’ve had a bit of a SOAP baptism of fire - the project I am working on makes hundreds of SOAP calls to multiple SOAP APIs on multiple hosts. During this time I’ve encountered some common and rare problems and troubleshooting them seems to be a bit of a black art, if the number of results in Google is any measure.

To demonstrate some of these troubleshooting methods I will use a global weather SOAP service, http://www.webservicex.com/globalweather.asmx?WSDL . I’ve added the web service to vRO using the “Add a SOAP host” workflow, and then used the “Generate a new workflow from a SOAP operation” workflow to create a new workflow: GetWeather. This simple workflow runs successfully:

When you are using a VMware orchestration platform with an official VMware plugin to manage a VMware product, you don’t really expect to have to fix the out-of-the-box workflows. However, during some testing of some workflows with a client the other day we ran into a couple of issues with the vCloud Director plugin workflows.

Software versions used

• vCloud Director 5.5.1 (appliance for development) and 5.5.2 (production deployment)
• vRealize Orchestrator Appliance 5.5.2.1
• vCloud Director plugin 5.5.1.2

CPU allocations are incorrect for both “Add a VDC”

When you provide the CPU allocation model properties for the Allocation Pool model the first problem is decrypting the naming - it doesn’t match the names in the vCloud Director interface!

[Update Dec 2016: An updated article for vRO 7.x is available here ]

I’m developing some very large, very complicated workflows for vRealize Orchestrator (vRO/vCO), and as it’s a Java based application it will probably come as no surprise to many that the performance of the client drops off sharply as the client’s RAM usage creeps up.

When working on some of the larger workflows, or after long sessions and heavy clipboard use, the client would become (even more) sluggish and in some cases would freeze entirely. This is particularly annoying because the vRO client has a habit of forcing itself on top of other applications - for instance Task Manager.

A requirement that often arises in large, complex orchestration projects is the need to encrypt and decrypt information. One such requirement recently specified triple DES password based encryption as the standard, which led me through a lot of Google searches to CryptoJS .

CryptoJS is a growing collection of standard and secure cryptographic algorithms implemented in JavaScript using best practices and patterns. They are fast, and they have a consistent and simple interface.

It’s a fairly common requirement when creating a new user to assign a randomly generated password, so during a recent engagement I wrote a little password generator to do that. I wanted to be able to chose whether special characters were used, and the length of the password - typically if the password doesn’t used special characters I would increase the length significantly!

Characters should be randomly picked from:

• a-z
• A-Z
• 0-9
• (optional) ASCII special characters

Inputs

• passwordLength - the length of the password to be generated (number)
• excludePunctuation - exclude the use of special characters if TRUE (boolean)

One of the use cases I’ve been working on with a customer is based on the vRO/vCO multi-node plug-in and involves the master vRO/vCO node calling proxy workflows based on a parameter - in this case the target site. As you can see from this very simple diagram, a Cloud Management System (CMS) calls a workflow on the Master node, which then executes a proxy workflow on the correct site. The trick is getting the Master Orchestrator node to pick the right proxy workflow.

To quote the release notes for the latest version of vCO/vRO Multi-node Plugin:

The VMware vCenter Orchestrator Multi-Node Plug-In allows organizations to manage environments with multiple vCenter Orchestrator server instances.

As organizations increase their level of automation, they often find the need to deploy multiple Orchestrator instances. With the VMware vCenter Orchestrator Multi-Node Plug-In, administrators have a more efficient way to manage multiple Orchestrator instances from a central point. The plug-in allows administrators to log in to a master Orchestrator server to view the inventories and workflows of remote Orchestrator servers, and to trigger workflows remotely.

To add a Windows Server 2012 R2 PowerShell host using Basic Authentication only, follow these steps.

Ensure that the Windows Firewall service is running (it doesn’t matter if the firewall is enabled or disabled, it should always be running! That’s a general rule, not just for this).

On the PowerShell host open a command prompt (*NOT* PowerShell console) as administrator and run the quickconfig command - you can re-run it if it’s already been run - but make sure it has.