Lately, I have been getting a lot of questions about how to use the vCAC Gugent to run scripts within the guest OS of your deployed VM. While if you are deploying simple VMs using vCAC this use case might not sound obvious, it has a lot of uses to it in the real world. Before I go through how to get your vCAC Gugent or now called vRA Gugent (Guest Agent) to run scripts, let’s take few examples of why you want to do this:

– Imagine the use case where you want to assign an IP Address in a Guest OS that is not supported by VMware Customization tool. You can actually assign an IP Addess to it by running after deployment  script using the Guagent to change the IP Address of that machine. Actually while I had this post in mind for a while, it end up getting to my top priority today as a colleague was asking me about this use case scenario.

– Imagine the use case where you want to run some security scanning scripts after the OS was fully deployed. This is will be any easy way of doing it.

– Imaging the use case where you want to initialize a client or agent for application deployment/management tool (Ex: Puppet, Chef, Altiris, TSM Client, …)

– It can be even be used as a cheaper dirty way of deploying applications or services.

Now that you see why running scripts within the guest OS using the Gugent is valuable, let’s see how to achieve that:

1- Make sure the Gugent is properly installed within your template and that its connecting properly after the VM being deployed. If you have not done this yet, you can refer to my earlier post showing just that: vCAC guest agent installation

2- Write your script and save it in a folder where the gugent can access it. Make sure to test your script manually before trying to call it using the Gugent.

3- Setup the following custom properties as needed on your blueprint template

• VirtualMachine.Admin.UseGuestAgent – this should be set to “true” (without quotes) to tell the agent that you will be making calls to it
• VirtualMachine.Customize.WaitComplete – set this to “true” (without quotes) to have vCAC wait for the scripts to finish before moving on down the rest of the life cycle of deploying your blueprint
  VirtualMachine.Software0.Name – enter a friendly name for your script that you want to run. If you want to run more than one script, create new properties with sequential numbers (ex: VirtualMachine.Software0.Name, VirtualMachine.Software1.Name, etc).
• VirtualMachine.Software0.ScriptPath – enter the location and file name of the script that you want to run. If you want to run more than one script, create new properties with sequential numbers (ex: VirtualMachine.Software0.ScriptPath, VirtualMachine.Software1.ScriptPath, etc)

Below is few several popular configuration scenarios:

Simple configuration of running a script in Windows using the Gugent:

• VirtualMachine.Admin.UseGuestAgent: True
• VirtualMachine.Customize.WaitComplete: True
  VirtualMachine.Software0.Name: <Script friendly name>  <== in my example Mytestscript
  
• VirtualMachine.Software0.ScriptPath: <your script full path> <== In my example c:\Mytestscript.bat

Simple configuration of running a script in linux using the Gugent:

• VirtualMachine.Admin.UseGuestAgent: True
• VirtualMachine.Customize.WaitComplete: True
  VirtualMachine.Software0.Name: <Script friendly name>  <== in my example Mytestscript
  
• VirtualMachine.Software0.ScriptPath: <your script full path> <== In my example /scripts/mytestcript.sh

 

Running multiple scripts in Windows using the Gugent:

There might be a case where you need to run more than one script, you can do that by increasing the number after the word Software  each time you need to run additional scripts. While the below example is using Windows, you can achieve the same thing for Linux.

• VirtualMachine.Admin.UseGuestAgent: True
• VirtualMachine.Customize.WaitComplete: True
• VirtualMachine.Software0.Name: <Script 1 friendly name>  <== in my example Mytestscript1
  
• VirtualMachine.Software0.ScriptPath: <your script 1 full path> <== In my example c:\Mytestscript1.bat
• VirtualMachine.Software1.Name: <Script 2 friendly name>  <== in my example Mytestscript2
  
• VirtualMachine.Software1.ScriptPath: <your script 2 full path> <== In my example c:\Mytestscript2.bat

Passing Custom Properties value to the script you execute using vCAC Gugent:

This is something that come handy quite often. Imagine the scenario where you want to assign an IP address to Guest OS that is not supported by VMware out of the box Customization (Ex: Debian), and you have came up with a script to setup IP Addresses, now you will need vCAC to pass the IP Address from a custom property to your script? The way you can pass customer properties to your script is by putting the customer property between a curly bracket {<Custom Property>} after your script path. In this example, I am trying to pass an IP Address to my SetIP script where I know the custom properties for IP Address  is VirtualMachine.NetworkN.Address, where N is the network device number.  Let’s see how this will look like:

• VirtualMachine.Admin.UseGuestAgent: True
• VirtualMachine.Customize.WaitComplete: True
• VirtualMachine.Software0.Name: <Script 1 friendly name>  <== in my example SetIP
  
• VirtualMachine.Software0.ScriptPath: <your script 1 full path followed by {<Custom Property>} <== In my example c:\SetIP.bat {VirtualMachine.Network0.Address}

 Using the Gugent to call Power Shell scripts:

Yeah, Power Shell does not work when you call its script the same way you call a batch file in Windows, and you will have to change the command a bit to get it working. Here is an example on how to run a Power Shell script using the Gugent.

• VirtualMachine.Admin.UseGuestAgent: True
• VirtualMachine.Customize.WaitComplete: True
• VirtualMachine.Software0.Name: <Script 1 friendly name>  <== in my example Test
  
• VirtualMachine.Software0.ScriptPath: PowerShell -ExecutionPolicy Bypass  <your script 1 full path followed by {<Custom Property>} <== In my example:  PowerShell -ExecutionPolicy Bypass “\\vtvcaciaas.vt.com\scripts\testps.ps1 {hostname}”

I am sure many of you have noticed that I have called the Power Shell script from a UNC/share folder rather than calling it from a local path. I could actually have called it from the local machine, but just wanted to demonstrate that you can run scripts through the Gugent from UNC/share folder paths. I actually love to do so, as that save me from having to modify the template every time I want to modify the script.

 Gugent behaviors:

– The Gugent only get invoked the first time you deploy the VM after customization specs has completed if using custom specs or after just the VM deployment is completed if no customization specs is used.

– When the Gugent get invoked it check back with vCAC for any scripts or tasks to run, after it execute all of it tasks, it actually delete it self. Nope, it is not meant for day 2 operations.

– The Gugent copy all of the deployed VM Custom Properties to an XML file located at: c:\VRMGuestAgent\site\workitem.xml, which in order can be used by scripts run by the Guest agent or other wise.

At last, I hope you find this post useful, and sorry if I have bored you by the amount of scenarios/examples I have shared in here, but it seems many people out in the field are looking for particular scenario or another, so I though to share the most common one, and hope everyone can find something they like.

Please leave your feedback in the comment area and let me know what you think or if I missed something you like to add.