vRealize Orchestrator Index ‘0’ specified is out of bounds

Posted: August 30, 2017 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

I was trying use vRealize Orchestrator (vRO) 7.2 with vSphere 6.5 GA and U1 the other day and was receiving the following error when I selected vRO Servers under Inventory in the vSphere Web Client:

Read the rest of this entry »

---

Deploying vRealize Orchestrator 6.0.3

Posted: September 28, 2015 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

Today I had to deploy an instance for vRealize Orchestrator (vRO) 6.0.3 in my lab and ran into some snags that  I thought I’d document here.  I’ve always used the vRO/vCO configuration page to add vCenters and this functionality looks to have been removed.  I believe that using this method would add vCenter instances to vRO as well as registering the vRO extension with the vCenters.  Now you must use a vRO workflow to add vCenter and run a separate workflow to add the vRO extension to vCenter.  There is also a workflow that can be ran to import SSL certificates and vCenter licenses.  I found that the order in which you run these workflows matters as well.  It took a bit of trial and error to get everything working.  I may try to create a new workflow that combines each of the needed workflows into one to make the process more streamlined.

The following versions were used:

• Platform Services Controller: 6.0 U1 acting as a subordinate CA.
• vCenter: 6.0 U1
• vRealize Orchestrator: 6.0.3

vRO OVA deployment

There are no real surprises when deploying the vRO OVA, but I wanted to point out that now you’re able to specify initial root and vcoadmin passwords.  Previously you had to change them after you logged in for the first time.  This should help if you’re  wanting to automate the deployment of the appliance.  There are blog posts out there explaining how to do this.   You also don’t have to remember/lookup the provided default passwords.

vRO Appliance Configuration

Once the vRO VM is online, you’ll want to perform some initial configuration.  It may be possible to automated as well.  My vRO VM is vro6c.vmware.local so I’ll open a browser to https://vro6c.vmware.local:5480 and log in with the password I specified during the OVA deployment.

Go to System > Time Zone and specify the correct time zone for your environment:

Next I set the domain search path by going to Network > Address:

Lastly, I configure the appliance to use my local time source:

 vRO vCenter Extension

Before we continue I want to point out that if you go into vCenter and select the vRealize Orchestrator icon, you’ll see the following:

This is because there is no vRO extension registered with vCenter.  Let’s checkout the managed object browser (MOB) to verify.  My MOB is accessible at https://vc6d.vmware.local/mob.  Once I login and select content > Extension Manager > (more…) I see the following:

Notice that here is no “com.vmware.vco”?  This is why there is no vRO information in the vSphere web client.  We’ll rectify this shortly.

vRO Configuration

To access the main vRO landing page I’m going to go to http://vro6c.vmware.local (notice that it’s not HTTPS).  If you specify HTTPS, the connection will fail.

In the past you would click the Orchestrator Configuration link to configure vRO, but now you need to configure vRO by running workflows from within the vRO client so let’s launch the client.

Select Start Orchestrator Client and click the client.jnlp download.

First we need to register our vCenter instance by running the following workflow:

Library > vCenter > Configuration > Add a vCenter Server instance

Once successful you should be able to view the vCenter instance:

At this point if you checked the vCenter’s MOB, the vRO extension would still not be registered.

Registering vRO’s extension with vCenter

Let’s finally register the vRO extension by running the following workflow:

Library > vCenter > Configuration > Register vCenter Orchestrator as a vCenter Server extension

This part was tricky because the second field only ask for the address of the orchestrator server.  At first I only  entered the IP address of the vCO server and while the workflow did succeed, it did not actually register the vRO extension.  Also, if you don’t enter the correct port, the extension will register but won’t be visible in the web client.  This was tripping me up for a while.  I’d run it and it would succeed, but no extension.  I looked at the MOB of an older vCO instance I have and it had the address of the vCO server registered as https://vco.vmware.local:8281 and once I tried that it worked.  Port 8281 is the vRO application port.  After a run you will see:

[2015-09-28 11:21:17.851] [I] Registered this extension with host vc6d.vmware.local

As I mentioned, just because the workflow completed successfully, it doesn’t mean it actually worked.  We can run the following workflow to verify that it succeeded:

Library > vCenter > Configuration > List the vCenter Orchestrator extensions of vCenter Server

If your registration was successful, you’ll see output similar to:

[2015-09-28 11:24:01.488] [I] Extension key: com.vmware.vco
[2015-09-28 11:24:01.489] [I] vco-192.168.3.119@vmware.com: https://192.168.3.119:8281

Now if I access the vCenter MOB again at https://vc6d.vmware.local/mob and select content > Extension Manager > (more…), I see the following:

If I select the com.vmware.vco extension and then client, I see:

Yay.  Unfortunately, the vSphere web client won’t show the vRO information yet.  The vSphere web client service needs to be restarted in order to get the vRO info to show up.  We can do this by logging into the vCenter machine and running:

service vsphere-client restart

In my lab I’m using the vCenter appliance.  For windows you can restart the service in the control panel.

I’ve noticed that sometimes it may take a few minutes before the vRO instance to show up in the web client.  You may see the following error before then:

Error occurred while processing request. Check vSphere WebClient logs for details.

I saw the error for about 15 minutes.  Once whatever causes the error to go away, you should see the following in the web client:

vRO SSO Configuration

The last thing I want to demonstrate is a workflow for changing vRO’s authentication mechanism to SSO, importing the necessary certs and vCenter licenses.  I’m going to configure vRO to use SSO authentication against my vSphere 6.0 U1 platform services controller (PSC).  This can be done by running the following workflow:

Library > Configuration > vSphere > vSphere configuration

As you can see below, this workflow imports the needed certificates, licenses and configures vRO use my PSC’s SSO.  You have to add the vCenter server instance before running this workflow.  The component manager URL will be your PSC (vc6d-psc.vmware.local for me) with the /cm path:

If we log into the vRO configuration app, we can see that the configuration was successful.

Even though we’ve changed the authentication method, we still need restart the vRO server before the changes will take effect.

Once the server has been restarted you should be able to log into the vRO client using a user that is in your vRO admin group.

---

leaseSettingsSection = currentVapp.getLeaseSettingsSection()

System.log("Updating runtime lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.deploymentLeaseInSeconds)
System.log("Updating storage lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.storageLeaseInSeconds)

newDeploymentLeaseInSeconds = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.deploymentLeaseSeconds
newStorageLeaseInSeconds    = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.storageLeaseSeconds

leaseSettingsSection.deploymentLeaseInSeconds = newDeploymentLeaseInSeconds
leaseSettingsSection.storageLeaseInSeconds    = newStorageLeaseInSeconds

var task = currentVapp.updateSection(leaseSettingsSection)