As Hannibal from the A-Team used to say, “I love it when a plan comes together!”
Well thanks to the work over the past few months it’s all starting to come together. First I created the installer workflows that made it easy to build out a install wizard, then I updated the combination of prepare_vra_template.ps1 scripts to support 7.0-7.1 for Windows guest, and now I’m releasing the quick and easy way to get your software components provisioned with 2 fundamental steps.
- Run install wizard in vRO
- Check the box in vRA on your blueprint
That’s all you need to do to be up and running with software components! As usual I’ve recorded and provided the video to you below.
*NOTE as my friend Adam Osterholt let me know, if you didn’t configure vRA using the initial configuration wizard then there is 1 additional step you will need. You need to connect vRO and vCenter (obviously if we can’t connect to vCenter we can’t execute commands to the guest OS)
As always I’m also giving a quick guide so first download and import this package into vRO.
You will see in the VMware->SDE-SET-vRealize Automation->vRA Agent Install->Installer folder there is an install and configure. Run this workflow as it’s your simple wizard.
This wizard will populate the properties needed, create the property groups, and create the event subscription for you.
Choose the vRA Host and Event Topic
Event topic will be under your vRA host->Tenant->Administration->Event Topics->
This must be set to Machine Provisioning
Yes I tried to automate this but it’s dependent on your vRA host, sorry!
Next fill in the fields for
- FQDN of your vRA Appliance
- FQDN of your Windows (IaaS) host
- Password for the service user needed for windows bootstrap agent (Darwin user)
- Choose your version (we use this to determine where we download the bits from for all the components)
Set the guest details
- Linux root user (default is root)
- Password for the Linux admin user
- Administrator for windows
- Password for the windows admin
That’s it for vRO
Now go to vRA, go to Design->Blueprints and select the blueprint that you have software components on
Choose the machine in the canvas, got to Properties tab and Add a property group
Select the property group for your OS
Submit your request
Watch the vRO execution if you wish
Review the Execution information
Now that should be a success. Again my goal here was to get you from multiple steps down to only a couple and I hope this give you the immediate value I’m seeing with other customers. As always feedback is welcome and please come see me at VMworld!
I can’t seem to import the package. I get an IOException error that says it is not a valid package file, dunes-meta-inf is missing. Any suggestions?
Give this package a try and let me know your results
I’m having a few issues when running your packaged “Installer”.
1st: Logs displaying the following error:
Error in (Workflow:Create property group / Create Property Group (item14)#54) 403 Forbidden
Also, Log is stating that “Your Property Groups Already Exist” but I can assure you they do not.
2nd: Neither the vRA Agent Install Windows “Resources” or “Configuration” elements were populated with the “prepare_vra_template_ps Script “Content”.
The Events Subscription however does get created properly. I had mentioned in another post (in one of your related articles), that the vRA Instance as well as Guest Machines do not have access to the Internet.. Not sure if this could be contributing but figured I’d mention this.
I misled you somewhat with one of the issues I reported above. After revisiting both the “vRA Agent Install Windows” as well as the “vRA Agent Install Config” Guest script Resource and Configuration elements, I happened to notice that the “prepare_vra_template.ps1” script content was indeed created/copied correctly.
In my defense however, and at first glance when browsing via the Viewer tab in vCO, the text is not “wrapped” for easy reading. (Having said this, not sure if this would present issues during actual deployment…but…figured it was worth mentioning..??)
I’d still like to know however why both Property Groups do not get dynamically created during the install??
The wrapped text actually isn’t an issue, it’s actually just a reference the actual code that is run is stored in the Guest Script Manager so you won’t have any issues with the actual PS1. Now the issue with property groups is that it’s clearly finding something with those names under existence. Are you perhaps choosing a different tenant during the install process? vsphere.local is my default but it might not be the tenant you’re using in your environment?
After a bit of testing, I was able to isolate the problem a little further. Looks as though the “Create property group” workflow only works in my environment when I select the “vsphere.local” vRA instance..??
I discovered this after having performed a series of tests using that workflow component only and selecting all the vRA instances available in my environment.
Unfortunately this limitation presents another problem for us, if indeed the goal is to promote this functionality using Tenants (other than the default vsphere.local).
For the record, the vRO Account I am using is not even a member of the vsphere.local environment..? This vRO Account however has all the necessary vRO Admin as well as vRA Tenant and IaaS roles and privileges possible in other (Tenant) environments.
A few more questions as well for you, Gary.
1. Does the Windows Agent Install script file (Guest Script Configuration Resource) actually get copied over to the Windows Guest Machines and then run locally or are they simply invoked remotely via the “Run script in VM guest” vCO workflows..?? (Apologize in advance..I’m somewhat of a nubie and just getting my feet wet here.. :-))
2. Why and where is there actual dependency on the vRA Software Components functionality..i.e. software agent bootstrap..?
3. Can we not automate the installation, for example, of just the Gugent Agent during provisioning? Is there such a Workflow available now?
One more update to above… :-o)
Turns out all of my problems were attributed to a messed up vsphere.local User Account that was generated using the Initial (Content) Setup Workflow process (using the configurationadmin account). Yikes… 🙂 Problem was mainly due to the Tenant Account’s password which, for some odd reason, was no longer valid..?? Unfortunately, there appears to be absolutely no way (using the Portal at least) to reset a vsphere.local user account password…None that I could find anyway..
Once I created a new tenant the old fashioned way, I was able to successfully execute your vRA Agent Installer workflow without issues.
If you would be so kind to respond however to the other questions I raised, that would be great..
Sadly there isn’t a way in the gui to change user passwords that are created for the local tenant. The best method is create a new one and entitle that user to the same items then delete the original user 🙁