Best way to run longer complex powershell scripts at provision time?

[craigso]

As the title states, I'm looking for the best way to run longer complex powershell scripts at the compute.post.provision step. Currently running Aria Automation 8.18.1.

Up until this point I've been running basic one or two liners using the built in 'Run program in guest' action to configure things like local passwords and automation accounts using powershell. This has been successful. I now have the need to run a script which is about 200-300 lines of code. Cobbling this into the 'run program in guest' is probably not ideal and would seemingly add some complexity.

My latest attempt was to add a 6 line script with conditional logic into a variable and include this into the arguments.

var arguments = "/k C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe Invoke-Command -scriptblock { start-transcript -path c:\\windows\\temp\\AgentInstall.log; write-host 'Starting install process...';" + ps_environment_prep_script + "; stop-transcript }"

This was close to working, but line breaks get wiped out, which mean you have to edit the actual script to add semicolons to turn it into a one-liner. This is easier to do on 5 lines, but not practical on 300 lines.

Research has shown there might be a way to run powershell with Invoke-VMScript. I've also attempted this, but ran into issues. The execution failed with '12/12/2024 18:41:35 Invoke-VMScript SSPI is not supported on Unix OS.' Which is odd considering it's being pointed at a Windows 2022 box. Either way the process seems like it would experience the same issues since you have to pass the script text as a variable.

Surely there is a better way?

[Brettjojnson]

I'm not sure what all options you have explored, but I have had good sucess with using cloudbase-init.  

Windows guest initialization with Cloudbase-Init in vCenter - VMware Cloud Management

Then, you can put as much code as you want in the cloud-init script block of the template itself:

      cloudConfig: |
        #ps1_sysnative
        #Comment
        Enter Script Bock here

[LuluTchab]

I also suggest having a look at CloudBaseInit.

In our case, to have the most flexibility, scripts executed on the VM are hosted on an internal GitHub repository. So, basically, in the CloudTemplate, the `#cloudconfig` part just do the following:

1. Configure network on the VM
2. Download "base" script file on GitHub (different script if Windows or Linux) using GitHub token to authenticate (token is retrieved from a Secret in ServiceBroker)
3. Exec the "base" script on the VM (Bash or PowerShell) with some arguments (ie: ImageMapping name, GitHub token, ...)

Then, the "base" script itself identifies more precisely the OS (Windows version, Linux distribution) and downloads another script on GitHub which is specific to the OS, and then just execute it. While executing, the scripts periodically "exposes" its status by writing/updating a JSON file with the information.

And finally, we are using a "computer.post.provision" Subscription to periodically (every min) get the content of the JSON file written on the VM (we use "Invoke-VMScript" to do this) and depending on the content, the workflow succeed or failed. 

This solution allows us to update very quickly what is configured/installed on a VM in the post provision process because no need to update CloudTemplates, just push another version of the script on GitHub and it works.

[craigso]

Thanks for the feedback everyone!

A few questions about CloudBaseInit:

1. When running the powershell scripts, do you have to set the powershell execution policy on the base image, or does cloudbaseinit execute scripts in a way where the execution policy is bypassed?
2. Do you uninstall cloudbaseinit after you're done with the image configuration?

[LuluTchab]

The answers:

1. Because we are also creating the vSphere template used to deploy VMs, we install PowerShell 7.x and also set the execution policy to "unrestricted" for everything. Could be dirty but does the job 
2. CloudBaseInit is not uninstalled, we just deactivate the service 

[craigso]

Another question for you, is there way to do some sort of conditional statement for the the cloudConfig property? Our cloud template for VM provisioning will do multiple OS types. I'd like to do something similar, a config for linux and one for windows. Or at a minimum specifying a different script in the git repo depending on the os type. 

I explored passing the cloud config from a vRO action based on OS type. Running into issues with escape characters in the string. Figured I'd ask your doing it. Thanks!

[LuluTchab]

Another answer. In fact we did the choice to have one different CloudTemplate for each Windows/Linux version so it's easier to see directly the OS type of a deployed VM based on its CloudTemplate. The only things that are "dynamic" in the cloudConfig are:

• Network information (IP, gatewey, ...) automatically inserted in the commands that configures that
• Some vRA secrets written in files locally to the VM that are used (and then deleted) by the script that is downloaded from GitHub

[Pawel Koc]

Have you looked at this package?
https://community.broadcom.com/vmware-code/viewdocument/guest-script-manager-vro-8x-vers?CommunityKey=d743a854-b7b6-437f-9698-4dd8983b11cf&tab=librarydocuments

------------------------------
-------------------------
www.blanketvm.com
-------------------------
VCP-VCF, VCP-DCV, VCP-CMA, VCAP-DCV, VCAP-CMA, vROPS|vSAN|VCF Deployment Specialist
-------------------------
------------------------------

[craigso]

I looked into the vRO package after you posted. I'm a little concerned about maintainability long term. But I have no doubt that could do the trick!

I've been going down the path of a similar cloudbaseinit solution with Puppet. But I'm liking the approaches mentioned here so far. I will likely demo the cloudinit solution and see if I can get something going there.

[Carl Linkletter]

If you are going to go with an async process like cloudinit, then, getting back to your original question, why not just call an async workflow in Aria Orchestrator?  At least then, if it fails, you could request back to vRA to destroy the deployment that failed so that the user doesn't use it.

[Logan Skrzypczak]

I agree with Carl here, but Cloud-init is also heavily leveraged by certain customers and works well depending on the scope of executions and work you are doing in the guest operating system.

With regard to Invoke Script, you will most likely deal with Double Hop kerberos issues at some point if you are using an Orchestrator workflow to run a powershell workflow from a PowerShell host to another server in your environment. Spas goes over some of this content in some old blogs, not sure how relevant they are now but Double hops still exist: https://community.broadcom.com/vmware-cloud-foundation/discussion/run-powershell-scripts-remotely-using-orchestrator-solving-the-kerberos-double-hop-issue / 

Keep in mind we had some issues with guest operations in 8.18.1 as well: 

• Workflows that use the Guest operations code fails: https://knowledge.broadcom.com/external/article/385294 ensure you have installed Patch 1 before trying the guest script packages.