We have a script that runs after a certificate update that re-deploys some VMware OVA appliances with the new certificate inside them (Part of a VMware Horizon View setup)
We noticed recently that we needed an extra OVA as part of the deployment and added it in, but now the time to deploy the OVA’s in the script is longer than the 5 min timeout, so it’s failing each time and the end of the script which needs to run after the VM’s are deployed isn’t running either,
So is there any option to extend or disable the timeout please?
Thanks for getting back to me, and thank you so much for considering to add the option to change the time out.
There is a process to be ran before the OVA’s are deployed and after they are all successfully deployed - I’ve not seen a way to have interactions like this on multiple scripts within the Certify deployment tasks?
The deployment is written by VMware, so not much I can do to optimise here, I’m just calling their script with a config for each of the OVA’s to deploy.
I guess the whole script could be run async, nothing actually returns to Certify, but we would lose the notification for a failed certificate update (due to the script failing) in Certify, but could look at implementing our own in the script. I take it we’d need to just change the script Certify runs to be a wrapper to call the real script as I don’t see an option to run the scripts async in the Certify GUI?
Another option would be to async the OVA deployments and run all 3 simultaneously, it should work, but feels like it would be adding some complications/risk of failure for the extra code. The downtime for the update is only around 2 minutes per OVA being deployed and they host different connections, running them in serial was simpler and felt more reliable (and not having to deal with PowerShell async ! )
Food for thought if allowing a configuration on the 5 min timeout for ps scripts isn’t recommended due to lack of testing/support.
No problem. The configurable timeout option is being worked on right now and will be included in the next release (which should be soon). I think long term though our attitude to supporting long running scripts will be if it works for you then it’s ok, and if it doesn’t work (for some reason other than timeout) then, well it’s your script
You’re correct we don’t have an async configuration option in the app, so we just wait for the script to return before proceeding, this is why we need a timeout otherwise we could wait forever.
With scripting there is almost always a way to achieve what you want but it may not be as elegant as you’d like, for instance as a workaround you could write state information to a text file and read that from your subsequent scripts.