Tag Archives: workflow

Creating new vRA Workloads in a specific AD OU

This week, I’ve had several customers individually approach me with this question – how can they specify the OU which a Windows VM should land in when it’s created via vRA?

This is a great question and a very important operational task to accomplish – OU membership determines so much vital configuration for a Windows machine.

It seems like most of these customers have a tendency to assume they are going to create the VM first, and relocate it to a new OU later. But there’s a much more streamlined way to do it. By binding a workflow to the IaaS BuildingMachine lifecycle stage, you can pre-stage the computer object in AD before it’s even provisioned. That way, when it first adds to the domain it will already be present in the correct OU. This also has the added benefit of ensuring all group policies are inherited right away, rather than requiring additional reboots.

I’ve put together a quick example here that should help you see how to do just this.

To use the example workflow attached above, you must already have your vRO instance registered with vRA and the extensibility customizations installed. We also assume that you have correctly configured the Active Directory plugin, and that the example vRA blueprint you will deploy has a vSphere Customization Specification attached which adds the VM to your AD domain.

First, import the workflow into a vRO folder of your choosing.

Then, browse to it in the workflow tree and select it. On the General tab, you can see there are two Attributes that must be updated for your own envirionment. Enter the AD Domain Name as the value for domainName and select the parent OU you want new OUs to be created in  for ou1. You can see in my example, the domain is lab.virtualwin.org and the Parent OU is Lab Machines.

Configure_Workflow
(Click for larger image)

Next, use the Assign a state change workflow to a blueprint and its virtual machines workflow to attach the new workflow to the BuildingMachine stage of a test blueprint. This workflow is located under root > Library > vCloud Automation Center > Infrastructure Administration > Extensibility in the Workflow tree.

To do this, right-click the workflow and select Start Workflow.

Start_Workflow

Choose BuildingMachine as the stub to enable and choose your IaaS host. Remember that we are assuming your IaaS Plugin is already configured. If you don’t see any hosts in this list, you still need to do that! Click Next.

Select_Stub_and_vRA_Host

Now,  select the blueprint(s) you wish to add this workflow to. In this example the selected blueprint is “Add to OU Test” and click Next.

Select_Blueprints

On the last screen, you will be prompted to select the workflow and some final options. Choose the new workflow you just imported (in this example, it is Create OU and Stage Machine). Be sure to choose Yes for Add vCO workflow inputs as blueprint properties and then click Submit.

Add_vRO_Workflow_Inputs

The workflow will complete. Now, switch to your vRealize Automation console and edit the blueprint which you just attached the workflow to. Select the Properties tab. You will be presented with a list of properties, some of which need to be adjusted. The total list of properties you see may vary from environment to environment. Here, we need to delete the following 4 properties:

  • ExternalWFStubs.BuildingMachine.vCACHost
  • ExternalWFStubs.BuildingMachine.vCACVm
  • ExternalWFStubs.BuildingMachine.vCenterVm
  • ExternalWFStubs.BuildingMachine.virtualMachineEntity

And also edit the one named ExternalWFStubs.BuildingMachine.ouName so that Prompt User is checked.

Blueprint_Custom_Properties_Before

When you’re done, the properties should look more like this:

Blueprint_Custom_Properties_After

Now, let’s make that variable a little more friendly. Open the Property Dictionary from the menu on the left. Click on New Property Definition and fill in the data as follows:

  • Name: ExternalWFStubs.BuildingMachine.ouName
  • Display Name: Create New OU to host new VM
  • Control Type: Textbox
  • Required: Yes

Property_Dictionary

That’s it! Now, if you navigate to your vRA Catalog and request the blueprint you’ve been working on, you should see something similar to this.

Request_New_Item

Click Submit and wait for provisioning to complete. When you’re done, you will see the new machine in your Items tab as usual:

Deployed_Items

But if you check out your Active Directory, you should also see that the new OU you selected was created, and the new machine was created inside it!

AD_Properties

Now, this example workflow is a very quick demonstration of concept. It doesn’t have any error handling (and suffice it to say, should NOT be used in any production environments and is provided without support or warranty of any kind) – but it should show you how a seemingly complex  task like this can be accomplished relatively easily. The logic in the workflow could easily be amended to remove the OU creation step. ASD and vRO Dynamic Types could be leveraged to provide the user a list of OUs to choose from, rather than a free-form textbox. The sky’s the limit when it comes to vRA extensibility!

Today’s spicy orchestration experience was brought to you by the Habanero Mojito at Havana, Walnut Creek. Jon_Kate_Havana

I hope this post has been useful.

Creating new vRA Workloads in a specific AD OU

Deploying vRealize Automation Workloads from Apple Watch

Like many people (although not as many as would have liked, I suppose,) I got my shiny new Apple Watch yesterday.

Once it was set up and on my wrist, the first thing I thought of was naturally “How can I use this with vRA?”

Naturally.

It didn’t take long to figure this one out. I don’t know how valuable it will be in the real world, but you have to admit – it sure is cool, particularly for showing the amazing flexibility of vRealize Automation.

Basically, we started with this. A simple button on the Apple Watch that starts a Workflow  which is then handed off to my iPhone.

Apple_Watch_Workflow_Red

Apple_Watch_Workflow_Screenshot

Workflow_Running_on_Apple_Watch
(Edit: I literally just this second learned how to screenshot on the Watch, so I have included both images. Just because)

The iPhone then connects via SSH to a Linux host running CloudClient and runs a deployment script I wrote

Workflow_Details_on_iPhone

The script is quite basic and is as follows:

#!/bin/sh
#
# Autodeploy a vRA item CentOS-vCO Test
echo "---------------------------------------------" >> vRA-Deploy.log
echo "Deployment started at" `date` >> vRA-Deploy.log
/root/cloudclient-3.2.0-2594179/bin/cloudclient.sh vra catalog request submit --id '"CentOS-vCO Test"' --groupid '"Ops Managers"' --reason '"Deployed via Apple Watch"' --export /tmp/request.txt >> vRA-Deploy.log
echo "Deployment handed off to vRA at" `date` >> vRA-Deploy.log
echo "---------------------------------------------" >> vRA-Deploy.log

This uses the auto-login configuration of CloudClient to connect to my vRealize Automation instance and deploy a simple CentOS blueprint from my catalog.

Cloud_Client_Log
(Click image for a larger version)

The details of the deployment come up in the vRA-Deploy.log file…

vRealize_Automation_Apple_Watch_Request_Successful

Deployed_Workload_in_vSphere

And voila! I’ve just provisioned a VM from my watch. The future is now, people.

Edit: 4/26/2015 – I just realized that the step of handing off the workflow from the Watch to the iPhone was unnecessary. The Watch can execute the SSH commands directly without the added handoff. I’ve updated the screenshots and the text accordingly. Cool!