Hey folks! just wondering if anyone has some advice or path forward. I am trying to accomplish 3rd party application package/patch management in our environment.
I notice Chocolatey uses set-execution policy to bypass on a lot of its functionality. My environment has strict policies in place to use only trusted signed scripts. We cannot disable execution policy and any scripts will fail to set the policy as well.
Does anyone know of a way around this. i.e. maybe once chocolatey is installed it functions outside of powershell scripts and is purely command line based? if deploying chocolatey is the only issue I can solve that. Just wanted to see if there are any recommendations of anything that functions outside of this powershell execution policy method.
Thank you!
Powershell set execution policy problem.
Re: Powershell set execution policy problem.
Eww... Hmmm
Chocolatey is based in PowerShell and any package you may choose to install or update could result in PowerShell installer scripts being launched on a PC.
I also believe that if you are able to create an Automate script that executes PowerShell, that you wont receive an error. It's been so long with dealing with this issue I may have forgotten the details, but I think Automate packages it's own PowerShell executable and uses that when any scripted PowerShell is placed in the execute script function.
This means although you may have a policy set to prevent unsigned execution, Automate may be bypassing that policy with its scripting functions.
One way to test that theory is to place a small unsigned script n the text field of the Execute PowerShell function inside Automate scripting. Run it where a policy is known to be active and see if you get a proper return or if it ails out with cert error.
I would be curious to know the outcome of this.
Chocolatey is based in PowerShell and any package you may choose to install or update could result in PowerShell installer scripts being launched on a PC.
I also believe that if you are able to create an Automate script that executes PowerShell, that you wont receive an error. It's been so long with dealing with this issue I may have forgotten the details, but I think Automate packages it's own PowerShell executable and uses that when any scripted PowerShell is placed in the execute script function.
This means although you may have a policy set to prevent unsigned execution, Automate may be bypassing that policy with its scripting functions.
One way to test that theory is to place a small unsigned script n the text field of the Execute PowerShell function inside Automate scripting. Run it where a policy is known to be active and see if you get a proper return or if it ails out with cert error.
I would be curious to know the outcome of this.