Ladies and Gentlemen following me and my blog, let me say that last week was one of those great weeks here at VMware! They say things coming in 3s well last week that is so very true for me.
- I am now a member of the CTO Ambassador program which brings me closer to my personal goals to become a field CTO some day!
- I found out that my membership for vExpert was extended so thanks to all of you who continue to keep following me and this blog.
- Finally and the part I feel is the coolest, I will be getting some of my own developed scripts integrated into an upcoming release of vRA.
So now you might be asking… but Gary you’re an automation guy, what could you have possibly created that could be included? Well what if you had an automated script to deploy the agents needed for Software Components in vRA 7? Don’t we already have a prepare_vra_template available? Didn’t you just post an automated way to use that at provisioning time?
Well yes we have the prepare_vra_template.sh and yes I did just post how to utilize that with the event broker. That said when was the last time you ran a shell script on windows? (Yes I know there’s cygwin and other utilities but it’s not the same) Enter my contribution to you my followers, to my customers, to my peers, and most importantly to the vRA product. I have created a prepare_vra_template.ps1 that will automate all of the steps needed for Application Authoring on Windows provisioning for vRA 7.
So what exactly does it do? If you review the link below, the script walks through every one of those step to prepare your Windows VM for application authoring.
While developing this I felt it required flexibility based on how you might want to execute the script. Using this mentality I have made sure that it can but utilized in one of three ways:
- Command line (ex. ./prepare_vra_template.ps1 applianceName iaasName password ) this is actually the methodology you will see me use in my next post which automates the deployment of the agent from vRA
- User configuration (ex. edit the 3 variables in the user config portion of the script)
- Manual interaction (ex. the script if the values aren’t set by either of the two options above will prompt you for the 3 variables)
While the script may not be 100% bullet proof yet and may still have some gaps (only supports Windows 2012 R2 today), it still is a start that will make all of our lives easier.
If you would like to see a video walk through of the script
Download the script from here or here
UPDATED FOR 7.0.1 please use this link to download
Now I’ll walk through the script a bit so you understand the different pieces I included.
First block of code accepts the parameters in case they are passed via commandline
param( [string]$vRAurl="", [string]$IaaS="", [string]$Password="" )
Second block of code worth note is the user configuration. Notice all of these settings are commented out with the # but you can hard code these if you would like to your particular settings.
# ---------------------------------------- # USER CONFIGURATION - EDIT AS NEEDED # ---------------------------------------- # If this is unattended then these will be set by the parameters # Otherwise you can preset these for run time or simply answer the prompts # $vRAurl = "virtualAppliance.FQDN" # $IaaS = "windowsIaaS.FQDN" # $Password = "Password" # incomplete this section will build what the script prompts for later # ---------------------------------------- # END OF USER CONFIGURATION # ----------------------------------------
If neither of these are set you will get the following prompts
14 comments
Skip to comment form
Hi Gary –
We have a distributed setup of vRA 7, and in that case what FQDN should we be pointing to for the manager server. Should we use the VIP FQDN or the primary(active) manager server host FQDN. For the vRA FQDN, I have to use point it to one of the appliances directly because using the VIP was erroring out.
Thanks,
Yes unfortunately there is still a limitation with the agents using a VIP for either the VA or the IaaS server. You will need to have a pointing to a single instances. As for the IaaS server should point to which ever you defined as your model manager when you deployed the windows distributed components.
I create 2 blueprint (Ubuntu 14.04 , Win Server 2012)
and the 2 template prepared with Gugent as the guide explained here
I have an Issue with Windows Server 2012 , when I check the GuestAgent.log it received the Custom Properties with no error but nothing happened to VM.
In Ubuntu 14.04 working like charm IP and Hostname changed without any problem
Is there any Help ?
Is this windows 2012 and 2012R2?
Hi Gary,
Any reason, i did not get too much into the script but modified the following to accommodate for desktop/VDI templates.
if ( $os -like “*2012 R2*” -or “*windows 10*” )
elseif ( $os -like “*2008 R2*” -or “*windows 8*”)
Also, you have set the .NET check for 3.5 and fails if 3.5 is not installed. Couldn’t you do the following to check if any supported version is installed.
(Get-ChildItem -Path $Env:windirMicrosoft.NETFramework | Where-Object {$_.PSIsContainer -eq $true } | Where-Object {$_.Name -match ‘vd.d’} | Sort-Object -Property Name -Descending | Select-Object -First 1).Name
http://stackoverflow.com/questions/3487265/powershell-script-to-return-versions-of-net-framework-on-a-machine
Ebadullah, First things first, you may want to review the supported OS customizations options with vRA
*Supports Guest Agent Customization
√ Supports Software Agent
Guest Operating System vCAC 6.1.x vRA 6.2.x vRA 7.0.x vRA 7.1.x
Windows XP N N N N
Windows Vista N N N N
Windows 7 C* C* C* C*
Windows 8 C* C* C* C*
Windows 8.1 C* C* C* C*
Windows 10 N S* C* C*
Windows Server 2003 N N N N
Windows Server 2003 R2 N N N N
Windows Server 2008 N N N N
Windows Server 2008 R2 C* C* C*√ C*√
Windows Server2012 C* C* C* C*
Windows Server 2012 R2 C* C* C*√ C*√
Windows Server 2012 R2 SP1 N N N C*√
You’ll notice that the Windows 10 and 8 don’t support the software agents (that may not be important for you use case). Also yes you could alter the script in order to do .NET and different OS versions in the pre-reqs.
Hi Gary,
You are absolutely right regarding the OSes supporting the software agents. Nevertheless,
I was able to modify OS checks in your script and the software agent was deployed successfully on Win7x64 SP1 Pro and Win10x64 Pro.
Software component deployment went successfully afterwards as well.
I am not sure why VMware decided to exclude client OSes from the software component support list, but this is another discussion.
Hi Gary,
Maybe I am misreading something or misunderstanding what you are saying but the compatibility list states:
(meaning Windows 8, 8.1, and 10 are fully tested and certified as guest OSes as well as supported for Guest Agent Customization in the vRA 7.0.x similarly to Server OSes but not for vCAC 6.0.x)
What I was suggesting was to enhance your script to automate the process on these OSes rather than following the building the template process manually.
C Has been fully tested by Quality Assurance (QA) and indicates Certified.
S Supported, but not certified
N Not supported due to test results, has not been fully tested, or is not an available configuration
Guest Operating Systems
The following guest operating systems are supported on virtual and physical machines for 32- and 64-bit
where applicable.
*Supports Guest Agent Customization
Guest Operating System vCAC 6.0.x vCAC 6.1.x vRA 6.2.x vRA 7.0.x
Windows XP C* N N N
Windows Vista N N N N
Windows 7 C* C* C* C*
Windows 8 C* C* C* C*
Windows 8.1 N C* C* C*
Windows 10 N N S* C*
Windows Server 2003 N N N N
Windows Server 2003 R2 N N N N
Windows Server 2008 N N N N
Windows Server 2008 R2 C* C* C* C*
Windows Server2012 C* C* C* C*
Windows Server 2012 R2 S* C* C* C*
Ebadullah, The list I included was from the official support page via VMware. These operating systems can be deployed with vRA 6.x and above. They can utilize the guest customization agent (ie the gugent). They can’t all utilize the software components agent which has separate functionality to deploy software and provide lifecycle characteristics to those. No workstation based OS (windows 7, 8, or 10) are supported for that functionality.
To your point you can alter the script to include other OSs but I would also remove the sections that utilize the $bootstrapfile.
Does that clarify things?
Ok. Thanks for clarifying Gary. I just misunderstood what part of it you were referring to. Yes you are absolutely right on the Software Component (Application Services) for the Desktop OSes.
Guess, the $bootstrapfile too can be made part of the script to bypass if a “Desktop” OS is detected. And/Or a warning displayed for “unsupported” capability.
Yes you could either skip it, throw a warning, or comment out any reference to it. There are only a few places you would comment or alter it.
How is this script the same/different than the “prepare_vra_template.ps1” script available at https:///software/index.html ?
Author
I wrote both this script and used it for my AAA deployment with updates for vRA 7.1/7.2 days
Gary:
For vRA 7.3 we should be using the script available from the appliance?