New VMware Product Availabilities – Now available to download


VMware have just made a number of new product versions (mostly maintenance releases on few different products, including that of the much hyped VSAN 6.2) so a quick post to summarise the content that was released last night (15.03.2016)

  • VMware VSAN 6.2 – VMware VSAN 6.2 was officially announced in early February with a number of cool new features such as Erasure coding but unless you were a techie trying to download the software, you may have not known that it was not available for download despite being announced. That was until yesterday and the product is now available to download for every customer.


  • VMware vRealize Automation 7.0.1 now released and available for download
    • Release notes here
    • Product binaries here
    • Documentation here


  • VMware vRealize Orchestrator 7.0.1 is released and available to download
    • Release notes here
    • Product binaries here
    • Documentation here


  • vRealize Business for Cloud (Old ITBMS offering) is also released and available for grabs now
    • Release notes here
    • Product binaries here
    • Documentation here


  • vRealize Log Insight 3.3.1 is released and available to download
    • Release notes here
    • Product binaries here
    • Documentation here


  • vCloud Suite 7.0 is also released and available to download (here) – This includes all of the above new versions of products plus the exiting versions for vSphere Replication 6.1 + vSphere Data Protection 6.1.2 + vROPS 6.2.0a + vRealize Infrastructure Navigator 5.8.5

VMware vRealize Automation Part 10 – IaaS Extensibility – Using vRO for Blueprint Customization

Now the fun part of this series of articles begins where we look at truly leveraging the extensibility capabilities.

First of all, its important to understand what this word “extensibility” means in the context of vRA.


Machine Extensibility usually means the ability to customise the default IaaS workflows available within vRA through 2 key methods

  1. Old way: Using commandline tools (cloudutil) and vCAC Designer
  2. New (recommended) way:  Using the built in vRO workflows

This customisation lets you achieve various tasks during various stages of a machine life cycle that you cannot achieve using the default, built in IaaS workflows available within the vRA database. You do this by injecting custom logic to the built in IaaS workflows, to be executed at various stages of the machine lifecycle. Lets take a look at the details of the components involved in little more detail.

vRA database has 10, built in IaaS workflows that define the logic of how and what happens during an IaaS machine life cycle. These workflows are fully customisable. Out of these 10, 4 are for menu extensibility while the other 6 are state change workflows, , known as workflow stubs which define the actions that take place when a vRA machine reaches its various stages of its lifecycle. Given below is a list of those 10 default workflows

1 - workflows

The 6 state change workflows (a.k.a. workflow stubs) directly correspond to the 6 stages a machine can go through, which are as follows

  • State=BuildingMachine, corresponding workflow name = WFStubBuildingMachine 
  • State=RegisterMachine, corresponding workflow name = WFStubMachineRegistered 
  • State=MachineProvisioned, corresponding workflow name = WFStubMachineProvisioned 
  • State=Expired, corresponding workflow name = WFStubMachineExpired 
  • State=UnprovisionMachine, corresponding workflow name = WFStubUnprovisionMachine 
  • State=Disposing, corresponding workflow name = WFStubMachineDisposing 

You can customise these workflow stubs so that they can call out a vRO workflow for bi-directional integration with external systems. Usually, the vRO workflow is triggered before the IaaS master workflow enters a specific stage. Given below are the key states of the master workflow, with the customisable states highlighted in yellow.

2. States

Note that the difference between the machine building and machine provisioning is such that during the BuldinMachine state, VM’s created or the physical server is being built but OS Is not deployed where as the MachineProvisioned state, the OS is already deployed and may be going through customisation / sysprep or any other post deployment tasks. I have not seen these states and what each state mean being clearly documented by VMware anywhere unfortunately. Closest I’ve seen is this article at Dailyhypervisor from Sid Smith who was an ex Dynamic Ops employee. I’m quoting the below from his article which explains when the customisation work actually kicks in for 2 of the most common sub states found within the provisioning master workflow state.

  • Provisioning state – Order of execution of sub states
    • Building Machine – WFStubBuildingMachine workflow can be used to customise. Executes pre-building machine state
    • Customise Machine – Things like cpu & memory & disks are adjusted. No need to customise as the default workflow can address most requirements
    • Customize OS – Customisation spec applied – Again, not need to customise the default workflow which is good enough
    • Customize Guest – Guest agent performs guest level tasks such as disk partitioning, scripts…etc.
    • Machine Provisioned – WFStubMachineProvisioned workflow can be used to customise. Executes during pre-machine provisioned state.

Ok, now that we have a little understanding of what the default workflows are and what’s meant by stub workflows, next step is to look at how to customise some of these stub workflows.

As mentioned earlier, the old school way of doing his would have meant we would have had to use a command line tool called cloudutil and a separate installable program called vCAC Designer (downloadable from the vRA server IaaS component page). This is quite a cumbersome process and involve lot of understanding of things inside the IaaS model manager. If you fancy having a go, all the instructions are available here.

What I prefer and will use in the example below is the use of the vRO workflows that are included as a part of the vRA plugin for vRO, to achieve this customization instead (you simply run the workflows on vRO and it will automatically customise the default vRA workflow stubs within the model manager database). The vRO team has kindly made the above tedious task a lot simpler by making a number of vRO workflows that you can use to customise the stub workflows within vRA IaaS model manager DB. Once the stub workflows are customised, you can run another workflow called, “Assign a state change workflow to a Blueprint and its virtual machines” and effectively bind any vRO workflow to a blueprint so that this workflow can be automatically called during any of those customisable machine states. For example, you can create a vRO workflow to create the description of a computer account and use the state change workflow to assign that to a machine provisioning blueprint so that every time a machine is provisioned from that blueprint (assuming that you select the MachineProvisioned state to trigger the workflow), vRA will call the vRO workflow to change the description of the computer account on the AD. Any input parameters to the vRO workflow will be added automatically as custom properties to the blueprint which needs to be manually filled out with values before the blueprint can be published to the users (in the above example of setting the computer account description, you’d have to specify the description string on the blueprint’s custom properties)

The whole process of using vRO state change workflow with vRA at a high level goes something like this

  1. Install the vRA plugin to vRO – We’ve already covered this in step 9.3.3 under the heading vRO configuration, mentioned in the previous article here.
  2. Register the vRA server and the IaaS component of the vRA server with vRO – We’ve already covered this in step 10.4.1 & 10.4.2 under the heading vRO configuration, mentioned in the previous article here
  3. Install vCO customization – You do this by running the “Install vCO customization” workflow found within “Library->vCloud Automation Center->Infrastructure Administration->Extensibility->Installation” folder within vRO – We’ve already covered this in step 10.4.3 under the heading vRO configuration, mentioned in the previous article here   3. vCO customization
    1. Note that once this workflow has been run successfully, if you look at the vRA Model manager database using the vCAC designer, you’ll see the default Workflows have been modified (now appear with an increased version number) as shown below IaaS 8
  4. Assign a state change workflow to a blueprint (effectively bind a vRO workflow to a blueprint and specify which state of the machine lifecycle should trigger the call out to that vRO workflow) – We will look at this in detail below
  5. Fill out any input parameter values using the custom properties of the blueprint – We will look at this in detail below

This is quite powerful and let you associate any vRO workflow with a blueprint to be called out for numerous extensibility tasks, to be triggered at any of the following machine states

  • State=BuildingMachine, using the corresponding workflow name = WFStubBuildingMachine 
  • State=RegisterMachine, using the corresponding workflow name = WFStubMachineRegistered 
  • State=MachineProvisioned, using the corresponding workflow name = WFStubMachineProvisioned 
  • State=Expired, using the corresponding workflow name = WFStubMachineExpired 
  • State=UnprovisionMachine, using the corresponding workflow name = WFStubUnprovisionMachine 
  • State=Disposing, using the corresponding workflow name = WFStubMachineDisposing 

Lets take a practical example and see how we can assign a state change workflow to a blueprint (in other words, how to bind a vRO workflow to a machine blueprint such that when the machine state changes to a chosen state, that vRO workflow is executed) – Step 4 & 5 mentioned above. As mentioned earlier, lets assume that you have a requirement to add a description to the computer’s AD account, each time a vSphere VM is provisioned from a blueprint and joint to the domain. Given below are the steps involved

  1. Create a normal vRO workflow to change the computer account name
    1. Within the vRO client, create a simple workflow to change the description of an AD computer account. – Note that you cannot do this with the built in workflows or action elements and you need to create your own workflow with a scripted task.
      1. The workflow will have 2 input parameters as follows
        1. Input Parameter – description (type: string) – Computer account description
        2. Input Parameter – vCACVM (type: vCAC:VirtualMachine) – vRA VM object
        3. Attribute – ComputerAD (type: AD:ComputerAD) – Computer AD account 1.1.1
      2. The scripting part would look like the below   1.1.2
      3. If its easier, I’ve uploaded the whole workflow which you can just download using below link and import in to your vRO library without having to manually created the workflow from the scratch.  ChanakaE-Set Compputer Account Description in AD.workflow (make sure to change the extension from .txt to .workflow once downloaded, before importing to vRO)
    2. Run this workflow manually against a computer account to ensure the vRO workflow is working as expected.
  2. Use the built in workflow “Assign a state change workflow to a blueprint and its virtual machines” to bind the above workflow to a vRA blueprint
    1. Note the pre-reqs below
      1. I’m assuming that you have a VM / physical machine blueprint that creates a Windows VM / Server that is joint to the domain as a part of the provisioning.
      2. If you don’t have one, simply login as tenant administrator to the vRA portal and create, publish and entitle a new vSphere VM type blueprint to create one. Given below is a screenshot of the build information for you to get an idea. 2.2
    2. Run the built in vRO workflow “Assign a state change workflow to a blueprint and its virtual machines” found within the “Library->vCloud Automation Center->Infrastructure Administration->Extensibility” folder within vRO
      1. Start the workflow and select,
        1. The appropriate vRA workflow stub to enable (What you select here will decide when the vRO workflow will get executed based on the various states of the machine). We are selecting the MachineProvisioned stub as that means the workflow will get executed during the machine provisioned state, after the guest level customizations are completed (i.e. AD account for the machine has been created as a part of the customization).
        2. Also select the vRA host where the blueprint’s are located.
        3. Click Next
      2. Now browse to the blueprint you want to bind the vRO workflow & click Next 2.2.2
      3. Now select the vRO workflow to bind to the blueprint
        1. Click on the Workflow template link and type the name of the vRO workflow in the filter box
        2. Select Yes checkbox to the option “Add vCO workflow inputs as a blueprint properties” – This is the step you add the vRO workflows’ input parameters to the blueprint via custom properties.
        3. Now click submit and ensure its run successfully within the vRO client.
        4. Verify that its successfully modified the blueprint by navigating to the vRA portal (as the tenant administrator) and looking at the custom properties for the blueprint. Note that you’ll see the following custom properties automatically being added.
          1. vRO workflow ID for the workflow you’ve bound to the blueprint.
          2. The 2 input parameters required by the blueprint.
    3. Set up the AD computer account description on the blueprint properties.
      1. You can pre-specify the computer account description on the blueprint or force the user provide a description. Im going to use the latter approach.
      2. Login to the vRA portal as tenant-administrator and go the custom properties page of the blueprint.
      3. Edit the  “ExternalWFStubs.MachineProvisioned.description” property and select the checkbox “Prompt User”. 2.3.3
      4. Click the green tick to complete and OK to commit the changes to the blueprint.
    4. That’s it. You’ve now customised the vRA model manager workflow stubs to invoke vRO workflows at various stages of a machine lifecycle and have also used that customisation capability to execute a specific workflow during a machine provisioning from a blueprint.
  3. Verify the customization by provisioning a machine using the blueprint.
    1. Lets now verify our customisation is working by provisioning a VM from the blueprint.
    2. Login to the vRA portal as a business group user (in this case, its bg-user@froot.domain if you’ve correctly been following all of the vRA deployment articles I’ve published in the correct sequence) who has the correct entitlement to this blueprint.   3.2
    3. Request a machine to be provisioned using this blueprint. You’ll note that the computer account description also need to be provided.   3.3
    4. Wait for the VM to be provisioned and the request to be complete on the vRA portal.
    5. Once complete, login to the Active Directory and verify that the customised description has been added to computer account.    3.5
    6. You can further verify that the workflow has been run automatically by looking at the execution history for the workflow on the vRO client. 3.6

There you have it. A simple customisation of the vRA model manager database logic through the execution of vRO workflows makes the extensibility more fun by allowing us to call various different vRO workflows to be executed during various different lifecycle stages of a machine, through the integration of vRA with vRO.

Hope this was useful…!!









VMware vRealize Automation Part 5 – vRO Deployment & Configuration & Integration

Next: vRA Part 6 – System / Infrastructure & Fabric Administrators –>

vRealize Orchestrator (was known as vCenter Orchestrator before) is an integral part of a vRA deployment as most of the vRA extensibility features relies on vRO being available and correctly integrated to vRA appliance & IaaS components. vRO in tern, connects to a number of other 3rd party systems through plugins, such as Microsoft Active Directory, Microsoft SQL, VMware vSphere, NSX….etc., where you can create a range of vRO workflows to carry out / automate tasks within these 3rd party systems. Due to the integration between vRA and vRO, these vRO workflows can be published within the vRA catalog and be made available via the built in self service portal (for example, you can publish a blueprint for resetting the passwords for an AD user through a workflow created on vRO).

I personally haven’t seen much documentation or clear guidelines with sufficient details on how to set up vRA with vRO for this level of extensibility which was one of the main reasons why I decided to publish this series of posts (which, hopefully will be addressed by VMware in the future).

So, now its the time to deploy the vRO and have it fully configured in preparation for the integration with vRA in due course. This article therefore looks at the deployment and the initial configuration of vRO component. (This should be considered a must have part of your vRA deployment)

vRO is available in many different forms

  • Available as a standalone appliance to be downloaded free of charge for vSphere customers
  • Automatically deployed if you install Windows version of vCenter (vRO Windows services are disabled by default though) – Note that this is now deprecated with the vRO 6.0.1 and hence SHOULD NOT be used going forward.
  • Available built in to the vRA itself (used for PaaS functions only, NOT used for IaaS functions for which you must register an external vRO)

In the interest of performance, and separation (and with the added ability of clustering should you need that in future), I prefer to deploy the standalone appliance (which is also the VMware’s recommended approach) so this article will rely on that. However, note that the post deployment configuration is still the same between the standalone appliance and the default version installed with vCenter.

The latest version of vRO released as of today, is the version 6.0.1, which was released in March 2015, in line with the announcement of vSphere 6.0. The release notes for the new version can be found here. It is compatible with vCenter server 4.1 and above.

Few highlights are below,

  • The stability of the vCenter Server plug-in has been improved by resolving major issues based on customer feedback (this was a real issue with earlier versions)
  • vRealize Orchestrator 6.0.1 supports the vSphere Web Client integration and context execution of vRealize Orchestrator workflows as part of vSphere Web Client 6.0
  • Switch Case introduced to handling conditional and branching operations within an automated workflow (If a value matches a switch case, specific workflow branch is executed)
  • Global error handling introduced
  • vRO control center beta introduced (Centralized admin interface for runtime execution, workflow monitoring & correlation with system resources, unified log access and configuration)

I will not be covering details about the Orchestrator itself, but only how to deploy & configure it within this post. If you need information about the vRO itself, including its architecture…etc. please refer to the official documentation found here.

Orchestrator Appliance Deployment

  1. Download the vRO appliance from My VMware portal as an ova and deploy on to the Management Cluster (NOT the compute / production cluster. Refer to the proposed architecture diagram in the previous post of this series here)
  2. During the deployment, you’d need to provide the information required and click next (ensure SSH is enabled) O3
  3. Once the appliance is deployed and powered on, SSH on to the appliance as root and change the root password expiry date.
    1. The password for the root account of the Orchestrator Appliance expires after 365 days. You can increase the expiry time for an account by logging in to the Orchestrator Appliance as root, and running passwd -x number_of_days name_of_account. o3.1
  4. Configure the appliance
    1. Go to the https://<vRO FQDN>:5480 and login using root.
    2. Change the Time Zone & Setup NTP (Admin->Time Settings)
    3. Update the Proxy settings should it be required and verify all other networking settings.

That’s it. the basic vRO appliance is now deployed and ready to be configured for vRO functionality which we’ll look at next.


vRO Configuration

  1. Login to the vRO appliance Configuration page 
    1. https://<vRO FQDN>:8283/vco-config (username: vmware)
  2. Bind the IP & DNS
    1. Click on Network on the left and select the IP address from the drop down menu to bind the vRO to the correct IP address.vRO2
  3. Import vCenter SSL Certificate
    1. Under Network, click on SSL Trust Manager tab and type import the vCenter server SSL certificate using the URL “https://<FQDN of the vCenter Server>” vRO3
    2. Note that this vCenter server should be the one managing the compute / production ESXi cluster, NOT the one managing the Management cluster.
  4. Setup Authentication Type
    1. Best practise recommendation is to configure the authentication source to be the vCenter SSO as this allows the user of vRO through vSphere web client. Note that the built in OpenLDAP is NOT recommended for production deployments.
    2. Import SSO server SSL certificate using the SSL Trust Manager
      1. Host: https://<FQDN of the SSO server>:7444 vRO4.2.1
    3. Setup vCenter SSO for authentication
      1. SSO Registration
        1. Select the Authentication mode as SSO Authentication within the Authentication section.
        2. Host: https://<FQDN of the SSO server>:7444
        3. Admin user name: Administrator@vsphere.local   vRO4.3.3
      2. SSO Configuration (Setup vRO admin group)
        1. Specify the SSO group that gets rights to the vRO server admin role here
        2. Select the SSO domain (I’m selecting the Active Directory attached to the SSO server)
        3. Select the dedicated Active Directory group (I’ve got a dedicated AD group created called “VMware vRO Administrators” which I’m going to add here.)   vRO
        4. Make sure the following accounts are members of this group on the AD
          1. vRA service account (<domain>\svc_vRA)
          2. vRO service account (<domain>\svc_vRO)
          3. Any domain user account requiring access to vRO workflows through vRO client.
        5. Note: One thing I’ve noticed here is that when changing this SSO Admin group (SSO or AD) always unregister the orchestrator and re-register with SSO. In the old version of vCO, it really didn’t like it when you just change this vRO admin group
  5. Assign vCenter license (default vRO license is only valid for 90 days)
    1. Under Licenses, select vCenter Server license
    2. Provide the vCenter address (<FQDN of the vCenter Server>) and an administrative user name to the vCenter (I’d create a new vRO service account, such as  <domain name>\svc_vRO, and assign vSphere administrative privileges to it and use it here as that’s neat and follow the RBAC guidelines) vRO5.2
    3. restart the vRO server service using the startup options
  6. Assign an external Microsoft SQL database
    1. The vRO 6.0.1 built in database is sufficient for small to medium scale deployments only and we will be using a separate SQL server as per VMware best practise.
    2. External database is also a pre-requisite for future clustering of the vRO.
    3. Prepare the SQL database
      1. Note: I’m going to use an external SQL 2008R2 server instance here.
      2. Verify that the protocol and port access is setup correctly on the SQL server vRO6.3.2
      3. Create an empty database on the SQL server (vRO601) vRO6.3.3.1
      4. Create a SQL user account (svc_vRO) and map this to the vRO601 database with dbo permission
        1. Note: With using the vRO Linux based appliance, I’ve had weird errors here and trying to get both Windows authenticationand SQL authentication work here. To cut a long story short, I only managed to get it to work after adding a Windows domain account (froot\svc_vRO) and a SQL account (svc_vRO), both with the same name added as DBO to the database. (makes no sense). This account will only be used by vRO to connect to its database. Ensure that SQL password expiry is ticked off when creating the sql account to avoid future problems. vRO6.3.4
    4. Import the SQL server SSL certificate to vRO using Trust Manager (Only applicable if the DB server uses SSL certs. Mine doesn’t so I will skip this)
    5. Setup the SQL server database connectivity
      1. Provide the SQL database connectivity information required and click apply changes vRO6.5.1
      2. Once prompted, create the database tables using the link provided. Once completed successfully, the status will be displayed. Click Apply Changes vRO6.5.2
  7. Assign a SSL Certificate to vRO
    1. Either create a self signed server certificate or import a certificate database (using an existing CA) vRO7.1.1
    2. Export the certificate DB for DR                                        vRO7.1.2
  8. Configure Orchestrator Plugins (Using vRO configuration interface)
    1. Configuration of Active Directory, SSH & vCenter Server plugins (all come installed by default in vRO) are now done through pre-defined workflows available within vCO rather than through the configuration interface
    2. Type the vRO admin username and password within the plugin section (When the Orchestrator server starts, the system uses these credentials to set up the plug-ins. The system checks the enabled plug-ins and performs any necessary internal installations such as package import, policy run, script launch, and so on) – I’m using the vRO domain service account (<domain>\svc_vRO) which is also a member of the vRO administrators group I’ve mapped under Authentication.
  9. Install new Orchestrator plugins
    1. Various addition vRO plugins can be downloaded from the vRO official web page (here) and installed on to the vRO via the configuration page so that vRO workflows can be created to integrate and manipulate external systems.
    2. Use the Install Application tab within the General section of the vRO configurator to install plugins that have a .vmoapp extension.
    3. There are a number of additional plugins available here but I will be installing the followings, for the purpose of this article
      1. Install the plugin VMware vCenter Orchestrator Plugin for NSX 1.0.1 – Required for vRO workflow creation for NSX in order to orchestrate some NSX tasks
        1. Compatibility: Based on the VMware product Interoperability Matrix as of now, for vRO 6.0.1, NSX version 6.1, 6.1.1 & 6.1.2 are the only versions of NSX supported and that requires the vRO NSX plugin version 1.0.1. But the (official site for vRO team) site’s plugin list only contains the NSX 1.0.0 plugin and not version 1.0.1. So be sure to download the correct version via the link I’ve provided above.
        2. Note: This plugin is required for vRO workflow creation for NSX in order to orchestrate some NSX tasks. The current workflows included within this package are limited however and the installation of the NSX-v Dynamic Types plugin V2 (below) will add additional NSX related workflows. Once these workflows are available, they can be leveraged by vRA.
        3. Install the NSX plugin (using o11nplugin-nsx-1.0.1.vmoapp file) vRO9.2.1.2
        4. Accept license & Apply changes                                            vRO9.2.1.3
        5. Restart vRO server to take effect (note that the plugin status may not change to “installed” immediately after the vCO service restart. This can take some time)   vRO9.2.1.4
        6. Login to the vRO client and verify the NSX workflows are now available within Library->NSX folder vRO9.2.1.5
      2. Install the plugin NSX-v Dynamic Types plug-in V2
        1. Note: A handy NSX Dynamic Types plugin to use with vRA Advanced Service Designer. This plug-in can be customized and extended using the plug-in generator V2 package.
        2.  Install instructions are all available in the link above (summary below)
          1. Rename the downloaded package com.vmware.coe.plugin.dynamictypes.nsx.v2.package
          2. Import the package (Using vRO client, NOT the configuration page)
          3. Verify that the package and the additional NSX workflows now appear within the vRO client. vRO 9.2.3
          4. More steps are required to be carried out to complete this which will be done under step 10 below
      3. Install the plugin VMware vRealize Orchestrator vRA Plug-in 6.2.0
        1. Note: This is required for integration with vRA 6.2.
        2. Install the vRA 6.2.x plugin using the o11nplugin-vcac-6.2.0-2287231.vmoapp on the vRO configuration page vRO9.3.1
        3. Verify the installation and restart the vCO service (note that the plugin status may not change to “installed” immediately after the vCO service restart. This can take some time)                                                                                                                                                            vRO9.3.2
        4. Note: Login to the vRO client and ensure all default workflows are visible within the client. (I’ve had repeated issues whereby, after the vRA 6.2 plugin has been installed, all default plugins and their workflows disappeared within vCO. If this happens, within the vRO configuration page, go to Troubleshooting section and click “Reset current version” under “Reinstall the plug-ins when the server starts and reboot the vRO appliance) – This can potentially save you lots of time….!!
  10. Configure Orchestrator Plugins (using vRO workflows) – We will configure the key plugins here and leave some to be configured later
    1. Configure vCenter plugin
      1. Note: The way to integrate vCenter server may differ depending on whether you have vCenter 5.5 or 6.0 as well as whether its a windows install or the vCSA. In my case, its vCenter 5.5 on good old Windows so the below steps are based on that configuration.
      2. Login to the vRO client (you can download the client installable from https://<vRO FQDN>:8281 or launch the client directly from there)  and run the workflow Library-> vCenter->Configuration->Add a vCenter server instance   10.1.2
      3. Now, select whether you are happy to use a shared session for vRO to connect to vCenter server. If you using a shared session (meaning, you’ve answered “No”), provide the credentials that the vRO uses to connect to the vCenter with (shared credentials for all users). I’m using the vRO service account (svc_vRO) which I’ve made an Administrators on the vCenter instance. This is usually good enough as I can see all vRO driven activities on the vCenter logs / events clearly thanks to the service account name.  Also, since the ultimate goal is to call these workflows via vRA portal, and when I specify blueprints based on these workflows, I’m already controlling who has access to access those blueprints, so the shared credentials between vRO and vCenter is the best option. If however you decides to not use shared credentials, you need ensure each user who access vCO workflows though vRA catalog, will have sufficient permission on vCenter to execute that specific workload and I don’t think that is a good way to go about it, architecturally.     10.1.3
      4. Once the workflow has been successfully run, you’ll see the message on the screen as follows. 10.1.4
    2. Register vCenter Orchestrator as a vCenter Server Extension
      1. Note: This important so that vRO workflows will automatically be available within the vSphere Web Client to execute.
      2. Login to vRO client and rung the workflow: Library -> vCenter -> Configuration -> Register vCenter Orchestrator as a vCenter Server Extension
      3. Select the vCenter server (managing compute & edge cluster that the above workflow was run against) here. 10.2.2
      4. Verify it ran successfully
      5. Verify on the Managed Object Browser for that vCenter that the vRO extension is listed correctly. Instructions are as follows
        1. In a Web browser navigate to the managed object browser of your vCenter Server instance. https://<vcenter_server_ip?/mob
        2. Log in with vCenter Server credentials.
        3. Under Properties, click content.
        4. On the Data Object Type: ServiceContent page, under Properties, click ExtensionManager.
        5. On the Managed Object Type page, under Properties, click the Orchestrator extension string.extensionList[“com.vmware.vco”]. The extension has a server property which contains an array of type ExtensionServerInfo. The array should contain an instance of the ExtensionServerInfo type with a url property which contains the URL of the registered Orchestrator server.
        6. On the Data Object Type: Extension page, under Properties, click server. You can see information about the Orchestrator server registered as an extension, such as serverThumbprint and url. The serverThumbprint property is the SHA-1 thumbprint of the Orchestrator server certificate, which is a unique identifier of the Orchestrator server. The url property is the service URL of the Orchestrator server. There is one record per IP address. If the Orchestrator server has two IP addresses, both of them are displayed as service URLs.
    3. Configure the Active Directory Plugin
      1. Login to the vRO client and run the workflow: Library->Microsoft->Configuration->Configure Active Directory Server
      2. Provide the answers including the AD dc name (I’d providing the root of the domain address which is automatically directed to any of the DCs in the domain rather than pointing at a single DC.                                      AD 10.3.1
      3.      Now select the authentication method to the AD as a shared session. If a shared session is not used, the user who runs the vRO workflow is expected to have sufficient rights in the AD to run the particular workflow which WILL NOT be practical once the vRO is integrated with vRA and users start requesting machine provisioning from blueprints which in turn, calls for vRO workflows. AD-1
    4. Configure VMware vRealize Orchestrator vRA Plug-in 6.2.0 – This step is key….!!
      1. Add vRA Host
        1. Import the vRA server SSL certificate
          1. Run the workflow “Import a certification from URL” under library->configuration->SSL Trust Manager
          2. Provide the vRA appliance details in the URL & Submit. Verify Its run correctly. vRA
        2. Add the vRA host
          1. Run “Add a CAC host” workflow under vCAC->Configuration and select the vRA server FQDN and the URL (with https://) vRA
          2. Use the shared session option using the Administrator@vsphere.local account to connect to the vRA server vRA
          3. Verify its run successfully at the end.
      2. Add the vRA IaaS host
        1. Setup Infrastructure Administrators Group on the default tenant
          1. Login to the vRA UI using https://<vRA Appliance FQDN>/shell-ui-app using the Administrator@vsphere.local account IaaS 0
          2. Go to the Administratprs tab within the vSphere.local tenant (default) and add an appropriate AD group for vRA Infrastructure Administrators (I have a group created here called <domain>\VMware vCAC Inf Admins and a user account named <domain>\inf-admin as a member of that group) IaaS 0 1
        2. Run “Add a vCAC IAAS host” workflow
          1. Run the workflow “Add a vCAC IAAS host” under vCAC->Configuration and select the vRA server (already added to vRO) IaaS 1
          2. Host name is are auto populated. Change this to be the name of your IaaS windows server (as shown below) and Click next.                        IaaS 2
          3. My preference is to use the shared session option here. The shared user account used to connect to the IaaS windows server needs to be a administrative account that has local administrative rights to the IaaS server where the model manager database is installed. As such, I’m going to use the vRA service account (domain service account that was created and used to install the IaaS services with during an earlier step here which had admin rights to the IaaS server).  DO NOT type the domain name here. Just type the account name as the domain is provided in the next step.      IaaS 3
          4. Change the domain name to the appropriate domain name and submit.   IaaS 2.5
          5. Verify it runs successfully.
      3. Install vRO Stub Workflow Customization
        1. Note: This workflow will modify the default Workflow Stubs used by vRA so that vRO workflows can be called during normal vRA driven machine provisioning & disposing to achieve e significant level of customisability.
        2. Run the vCloud Automation Center->Infrastructure Administration->Extensibility->Installation->Install VCO Customisation  IaaS 4
        3. Verify that the defaults Stub Workflows are now modified using vRA Designer
          1. Download the vRA Designer from using the URL https://<vRA appliance FQDN>:5480 and under vRA Settings tabIaaS 5
          2. Install the vRA Designer (model manager runs on the IaaS server. In my case, its the first IaaS server deployed. Ensure you use the FQDN for the server name here)                              IaaS 6
          3. Launch the vCAC Designer application installed above               IaaS 7
          4. Click on Load button at the top to load the internal vRA workflow configuration to see the updated version numbers of the built in workflows IaaS 8
      4. Due to this customization, it provides the ability to call vRO workflows during provisioning process using vRA IaaS Blueprints. To assign these vRO workflows to each Blueprint (to be invoked during provisioning stage), we’ll need to later run the Library->vCAC->Inf Administration->Extensibility->Assign state change workflow and select the required Blueprint. – We will be using this extensibility feature later on, but so far we’ve just had all the preparation work completed.

There you have it. vRO 6.0.1 is now deployed, its integrated with AD, vCenter and vRA and the vRA’s default provisioning stub workflows have also been modified so that we can call vRO workflows during vRA IaaS machine provisioning process and use custom properties to populate the input parameters being required by those vRO workflows.

Now that we have all the pre-requisites for a fairly complete vRA deployment, we’ll next look at the initial vRA setup and all the different user accounts involved.



 Next: vRA Part 6 – System / Infrastructure & Fabric Administrators –>